Privacy by architecture, not by toggle.
WebmasterID is first-party analytics for sites that don't want — or can't have — surveillance-grade tracking. Every architectural choice is shaped by what the product does not need to know.
A short, honest list.
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.
The negative space matters.
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.
Opt-outs are respected unconditionally.
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.
text/plain by design.
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.
What customer-site responsibility looks like.
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.
Related pages
- Architecture
How the tracker, ingest API, Postgres store, and dashboard fit together end-to-end.
- Product philosophy
Why these choices were made and what kind of audience the product is for.
- Article: privacy-first analytics
What 'privacy-first' actually means in practice — and how WebmasterID enforces it.
- Cookie policy
Plain-English summary of cookies, similar technologies, and what WebmasterID does and does not use.