Privacy by architecture, not by toggle.

• Site ID

  The site_id (wm_…) attached to the install snippet.

• URL & pathname

  The page being viewed. Query strings are stored as the canonical URL.

• Referrer

  The referring URL, when the browser provides it.

• UTM parameters

  Five canonical fields: utm_source, utm_medium, utm_campaign, utm_content, utm_term.

• Language & screen width

  Coarse signals for content layout and audience analysis. No device entropy.

• Event name & timestamp

  What happened and when. Defaults to page_view for browser auto-tracking.

• Anonymized IP (server-side only)

  IPv4 last octet zeroed, IPv6 truncated to /48. Raw IPs never reach storage.

Limited additional event attributes (e.g. title) ride alongside the core fields when relevant. The full list is in the events table schema and is intentionally narrow.

• No third-party cookies

  We don't set cookies on customer sites.

• No localStorage tracking

  No persistent visitor identifier stored in the browser.

• No fingerprinting

  No canvas, audio, fonts, or device-entropy signals are read.

• No cross-site tracking

  WebmasterID has no concept of a single user across sites.

• No session replay

  No DOM mutations, mouse traces, or input recordings.

• No raw IPs in storage

  Only the anonymized form ever lands in the database.

When a browser signals Do Not Track or Global Privacy Control, WebmasterID's tracker exits early and sends nothing. This is checked client-side in the tracker and again server-side at the ingest API for defense-in-depth.

The browser tracker submits events as a plain string body via navigator.sendBeacon. The browser attaches Content-Type: text/plain;charset=UTF-8 — a CORS-safelisted MIME — so the request is "simple" and skips the CORS preflight entirely. The ingest API parses the body as JSON. This makes the analytics path quieter on the network, more reliable across browsers, and one less surface that needs to negotiate cookies or credentials.

The full architecture is documented at /architecture.

WebmasterID is built to minimise the privacy surface so installation is straightforward, but operators remain responsible for their jurisdiction-specific obligations — including, where applicable, disclosing analytics in their own privacy notice. See our data-processing page for a high-level controller/processor overview.

What does 'privacy-first analytics' actually mean in WebmasterID?

It means privacy by architecture, not by toggle. The tracker does not set cookies. It does not fingerprint. Raw IPs never reach storage (IPv4 last octet zeroed at the edge; IPv6 truncated to /48). DNT and GPC are respected unconditionally. The product has no concept of a single visitor across sites.

Do you set any cookies on customer sites?

No. The browser tracker never sets cookies, and it never reads localStorage in a way that creates a persistent visitor identifier. The analytics path is intentionally invisible to the visitor's cookie store.

What about fingerprinting signals?

We do not collect them. Canvas, audio, fonts, and device-entropy signals are not read by the tracker. The signal we collect is the page being viewed plus the URL, referrer, UTM, language, and coarse screen width — nothing more.

How are IP addresses handled?

Anonymised server-side at the ingestion edge. IPv4 addresses have their last octet zeroed; IPv6 addresses are truncated to /48. Only the anonymised form ever lands in the events table — raw IPs never reach storage.

Do you respect Do Not Track and Global Privacy Control?

Yes, unconditionally. When a browser signals DNT or GPC, the tracker exits early and sends nothing. This is enforced client-side in the tracker and again server-side at the ingest API for defence-in-depth.

Do you sell or share my analytics data?

No. Workspace data stays in the workspace. We do not sell it, license it, or share it with third parties. We do not train shared models on it. The Claude/MCP integration is read-only, workspace-scoped, and audit-logged.

Privacy questions? Write to info@helperg.com.