In this guide
- Common leaks are e-mail addresses in URLs, form values in events and third-party scripts that read the page.
- You can find them with a crawl and a network check, and block them with server-side filtering.
- Have a response plan: who removes the data, who notifies, who fixes the cause.
Tracking leaks rarely come from attackers. They come from a thank-you page URL that contains an e-mail address, a form tag that sends everything typed, or a vendor script that scrapes more than anyone expected. They cause two problems: your analytics fills with personal data it should not hold, and the data can reach third parties without a lawful basis. This page covers where leaks come from, how to find them and how to prevent them, including how a server container helps. It is general guidance, not legal advice. See also personally identifiable information and GDPR and server-side tracking.
Where leaks come from
| Source | Example | Result |
|---|---|---|
| URLs | /[email protected] | Page URL with an e-mail is sent to GA4, Meta and others |
| Form tracking | A tag that sends field values on submit | Names, e-mail and messages in analytics |
| Over-eager tags | A heat-map or session recorder capturing input fields | Typed data stored by a vendor |
| Click text | A click tag that captures the full text of a button or link with a name | Personal data in event parameters |
| Referrers | Internal tools or webmail in the referrer | Private addresses in reports |
Orders from your store, back to the ad that earned them
Your store sends the order once. Open Tracked passes it on to each ad platform, cleaned and deduplicated.
Find leaks
Crawl your site
Look for URLs with email=, phone=, name= or tokens in the query string.
Watch the network
In developer tools, check what each page sends to each vendor, especially on forms and checkout.
Search your analytics
Look for @ in page URLs and event parameters.
Review tags
Open each tag that reads form or click data and see what it sends.
Check vendor settings
Turn off any collection you do not use.
Prevent them
Clean URLs
Never put personal data in a URL. Use POST or an ID that means nothing outside your system.
Narrow tags
Send named fields only, not "all form values".
03Server-side filtering
In a server container, use Allow or Exclude transformations to strip fields before a vendor receives them. See transformations.
Anonymizer
Open Tracked's Anonymizer (all plans) can zero or remove the visitor's IP before it reaches your container.
Consent checks
Tags should not send personal data without the right consent.
Ask Ari instead of digging through reports
Ari reads your tracking and ad data and answers in plain words.
If a leak happens
- Stop the flow: fix the URL, the tag or the setting.
- Find where the data went: analytics, ad platforms, logs.
- Delete it where you can: most analytics tools have a deletion feature.
- Tell the right people: your data protection contact, and where the law requires it, the regulator and the people affected.
- Write down what happened and what you changed.
A realistic example
An online clinic finds, during a routine check, that its booking confirmation page URL contains the patient's e-mail address, and that this URL is sent to its analytics and to an ad platform on every booking. The team removes the e-mail from the URL, adds an Exclude transformation in its server container so any page URL containing an address is cleaned before it reaches a vendor, asks the analytics and ad vendors to delete the affected data and writes a short note of what happened and what changed. The cause was a developer's shortcut years earlier. The lesson is that leaks are usually old, small and invisible until someone looks, so look on a schedule.
3 things to remember
Scroll and the points stack up.
Common leaks are e-mail addresses in URLs, form values in events and third-party scripts that read the page.
You can find them with a crawl and a network check, and block them with server-side filtering.
Have a response plan: who removes the data, who notifies, who fixes the cause.
Frequently asked questions
What is a tracking data leak?
Personal data reaching analytics or a vendor by accident, such as an e-mail address in a URL or a form value in an event.
How can I find leaks?
Crawl for personal data in URLs, watch network requests on forms and search analytics for e-mail patterns.
Can a server container prevent leaks?
It can filter fields before they reach a vendor, but only if you set the rules. Fix the source too.
What should I do if I find one?
Stop it, remove the data, tell the right people and document the fix.
Does hashing prevent leakage?
No. Hashed identifiers are still personal data. Send only what you need.
Do I need spreadsheets to read my results?
No. Once tracking is live, the Open Tracked analytics shows spend, revenue, ROAS and profit, and you can ask Ari, the built-in AI assistant, questions about your own numbers in plain words. Ari's allowance depends on your analytics plan.
Is Open Tracked different from Open Track or Open Space Track?
No. Open Tracked is the official name of our server-side tracking platform, and the website is opentracked.io. Many people search for it as Open Track, OpenTrack or Open Space Track. All of them lead to the same product: server-side Google Tag Manager hosting, first-party analytics and a CRM pipeline.
Fix your tracking at the source
Open Tracked hosts your server-side Tag Manager, keeps first-party cookies alive and shows what each ad is really worth.
The Open Tracked team
We build Open Tracked: server-side tracking hosting, analytics and the tools around them, for stores that spend on ads. Questions about this guide, or an idea for the next one?
Comments
Loading comments...
Guides · 6 min read
