Privacy practices for operators

What WebmasterID collects

• Per page-view: site_id, URL, pathname, referrer (when provided), the five canonical UTM parameters, document title, browser language string, screen width, event name, timestamp, and a small allow-listed attribute set.
• Server-side: the request's source IP is anonymised before storage (IPv4 last octet zeroed, IPv6 truncated to /48). Raw IPs are NEVER written to the database.
• Bot UAs are detected at ingest and routed to a separate bot_visits table — kept distinct from human metrics.

What WebmasterID never collects

• No tracking cookies.
• No localStorage tracking, no persistent visitor IDs.
• No fingerprinting (canvas, audio, fonts, device entropy).
• No session replay, no DOM/input recordings.
• No raw IPs in the database.
• No advertising audience exports.
• No gclid, no fbclid. Strict utm_*-only attribution.

Bots vs humans

WebmasterID separates bot traffic from human traffic at ingest. The bot path is purely an analytics-quality + security visibility signal. The same content is served to bots and humans. This is NOT cloaking. The dashboard's /bot-intelligence surface visualises the eight bot categories separately from human events.

What to disclose in your own privacy notice

If your site uses WebmasterID, your own privacy and cookie notices should mention:

• What is collected. Page-view records, UTM campaign parameters, basic browser metadata (language, screen width), and tagged interaction events (CTAs, forms, signup, purchase).
• What is not collected. No tracking cookies, no fingerprinting, no persistent visitor IDs, no raw IPs.
• Where data is processed. WebmasterID stores analytics in PostgreSQL on Supabase; the ingest API and dashboard run as Vercel serverless functions. Both providers may host data in the EU or the US depending on the project region.
• Retention. The current default retention window is 90 days for events and bot visits.
• How to exercise rights. Provide a contact mechanism for visitors to request access / deletion / restriction etc. Because WebmasterID processes data on your behalf, requests for a specific site should normally be directed to YOU as the controller; we assist with fulfilment.
• Lawful basis. In the EU/UK and similar jurisdictions, analytics typically requires consent (legitimate interest is contestable for analytics). State your basis clearly.

Consent-first loading pattern

For jurisdictions where analytics requires consent, gate the WebmasterID tracker on the visitor's consent state. The simplest pattern:

• On first load, render the consent banner without the tracker.
• When the visitor opts in to analytics, dynamically inject the <script> tag (or set a flag your script loader reads).
• When the visitor selects "necessary only", do NOT load the tracker at all.
• Persist consent in localStorage or a cookie that stores ONLY the consent state — never use it as a visitor identifier.

What you should never put in operator-controlled fields

These end up in your dashboard, your reports, and any export. Treat them as public.

• CTA ids — no PII, no internal user IDs, no order IDs, no session tokens, no consent state, no keyword stuffing. See /docs/cta-tracking § Never put in a CTA id.
• UTM parameters — same rules. Visible in browser history, in referrer headers downstream, in bookmarks, in shared screenshots. See /docs/campaign-links § Never put in a UTM parameter.
• Form ids — the tracker only stores the form id, never field values, but the id itself is visible in the dashboard. Use semantic identifiers, not values.

Related WebmasterID legal docs

• /privacy-policy — full Privacy Policy for WebmasterID itself.
• /cookie-policy — what cookies WebmasterID does (and doesn't) set.
• /data-processing — formal Data Processing posture.

Operators remain responsible for their own compliance with applicable privacy laws. WebmasterID is an early-stage product; this guidance reflects the current implementation and is not legal advice.