WebmasterID logoWebmasterID
Website observability

One observability fabric: traffic, bots, attribution, and AI visibility

WebmasterID is website observability for the AI-search era. The dashboard, the Event Explorer, and the MCP endpoint read the same deterministic event store. Privacy-first by architecture, operator-focused by design.

The pillars

Six surfaces, one event store

The observability fabric is built from six small surfaces. Each one reads the same data; the difference is the shape of the read.

Traffic

First-party event recording for human visits. Pageviews, sessions, sources, campaigns, countries — the canonical analytics shape, recorded without surveillance.

Bot intelligence

Deterministic categorisation of AI crawlers, search-engine crawlers, automation, and humans. Uncategorised stays uncategorised — never invented.

Attribution

Directional source attribution with per-row confidence labels. AI assistants, search engines, social, direct, unknown.

AI visibility

Per-bot crawl coverage and per-assistant referral coverage. The two AI signals joined on the AI Visibility view.

Event Explorer

Investigation surface for ad-hoc questions and tracker-install debugging. Filter, browse, drill into safe metadata, export.

MCP / AI-assisted

Workspace-scoped MCP endpoint so Claude (and other MCP clients) can read every observability surface above. Read-only and audit-logged.

Use cases

What website observability is for

Each use case below maps to a question an operator already asks. The fabric is built to answer them without forcing a tool switch.

Tracker install validation

After install, confirm events are flowing and classified correctly. The Event Explorer is the one-screen answer.

Weekly observability review

Traffic trends, AI crawler coverage, AI assistant referrals, attribution shifts — all in one workspace view. Per-site or rolled up.

Incident-style investigation

When something looks wrong, walk from the rollup down to the underlying events. The audit log records the operator's path.

AI-search-era editorial planning

Per-page coverage of AI crawlers and AI-assistant referrals informs which articles deserve a refresh.

Agency client reporting

Filter by client workspace, export, drop into the report. The filter set is the report definition; the audit log records the export.

AI-assisted reading

Ask Claude through MCP to summarise the week. The data is reproducible because Claude fetched it through MCP, not from a screenshot.

How WebmasterID helps

A small, deterministic stack — read three ways

One event store, three read surfaces. Each is independently useful; together they cover the day-to-day shape of running a modern website.

  1. 1. Tracker + ingest. A small browser tracker emits page-view events. The ingest API classifies each request server-side and writes a normalised event.
  2. 2. Dashboard. Curated rollups for the day-to-day operator view: traffic, AI visibility, attribution, bot intelligence.
  3. 3. Event Explorer. Investigation surface. Filter, browse, drill in, export.
  4. 4. MCP endpoint. Workspace-scoped MCP server so Claude can read the same surfaces on the operator's behalf. Read-only and audit-logged.
Privacy & trust

Observability without surveillance

The fabric is large; the underlying event store is small on purpose. Operators get end-to-end observability without paying with their visitors' privacy.

  • No cookies, no fingerprinting

    The tracker stays narrow. The observability fabric reads what the tracker recorded — and the tracker is small.

  • No raw IPs

    IPv4 last octet zeroed at the edge; IPv6 truncated to /48. Raw IPs never reach storage.

  • No cross-site identifiers

    The product has no concept of a single user across sites. The observability fabric is per workspace.

  • Audit log on every export and MCP read

    Operators see what was read, when, and by which API key. Compliance gets a real answer.

Questions? info@helperg.com. See also /privacy-first-analytics and /architecture.

FAQ

Website observability, answered

What does 'website observability' mean here?
It is the end-to-end fabric WebmasterID builds for owned websites: traffic, bots, attribution, AI visibility, and an Event Explorer for investigation. Each surface is a small, deterministic part; together they let an operator answer questions about real traffic without stitching multiple tools.
How is this different from generic analytics?
Generic analytics is mostly a curated dashboard for humans. WebmasterID is an observability stack: the dashboard is one surface, the Event Explorer is another, the MCP endpoint is a third. All three read from the same deterministic event store. The shape supports investigation, not just reading.
Is observability data shared with model providers?
No. Workspace data stays in the workspace. WebmasterID does not train shared models on it, does not sell it, and does not relay it to model providers. When Claude reads through MCP, the read is workspace-scoped and audit-logged.
How does the privacy posture survive an observability fabric?
By keeping the underlying event recording small. The tracker does not set cookies, does not fingerprint, does not store raw IPs. The observability fabric works on top of a deliberately narrow event store — privacy-first by architecture, not by toggle.
Can the observability fabric span many sites?
Yes. The workspace model rolls observability up across every site in the workspace. The Agency plan unlocks multi-workspace so an agency can run an observability fabric per client without leaking data across them.
Where does WebmasterID Agent fit in?
WebmasterID Agent is the optional companion that reads the observability data and prepares prioritised recommendations and AI-assisted prompts. The Agent never deploys on its own — operator approval is required for every change.