Personal data you should never send to your analytics

A privacy-friendly analytics tool can still end up holding personal data, not because of how it counts visitors but because of what the website sends it. Most leaks come from two places: page addresses and event labels.

Where personal data hides

• Query strings: /[email protected], password-reset links with tokens, search results pages with what someone typed.
• Page paths: /users/ana-garcia, /orders/12345, /invoice/INV-2026-0042.
• Event labels: statsdot.track('Signup', email) or a form name that includes the customer's name.
• Campaign tags: a newsletter tool that puts the subscriber's address in utm_content.

An email address, a name, a customer or order number that you can look up: each of these makes the analytics data personal, because it can be tied to a person.

What Statsdot removes for you

• Query strings are dropped before a page is stored, so ?email=... never reaches the database.
• Order numbers in common shop paths are collapsed: /checkout/order-received/1234 is stored as /checkout/order-received.
• Only the referring host is kept, never the full address of the page someone came from.
• IP addresses and full browser strings are not stored.

What you need to watch

• Event labels are stored as you send them. Use labels for categories ("Yearly plan", "Footer button"), never for people.
• Paths with identifiers that do not follow a common shop pattern are stored as they are. If your URLs contain user names or account numbers, use a page goal on a generic path, or send an event instead of relying on the page path.
• UTM tags are stored in lower case as sent. Check that your email tool does not put subscriber data in them.

A quick check

Open the Pages and Events panels for the last 30 days and scan for anything that looks like a name, an email address or a long number. If you find some, fix the source and delete the site's affected data, or ask us to.