[← Tracking & consent](/category/data-collection)

# PII leaks in marketing tags: how to find them, and with what

[David Pombar](/about-me) · November 9, 2026 · 10 min read

A PII leak is a request, not a policy problem: an email in a query string, a form value in an event, a hashed ID sent before consent. You only find it by looking at what your tags actually send, and no single method sees every path. Choose the layers by where personal data can enter your stack and by how often that stack changes.

*Disclosure: I am the Chief Revenue Officer at Trackingplan, one of the tools in this category. I evaluate it with the same criteria as the others, and I say where it is not the best fit.*

**How I compared them.** Five detection methods and three commercial tools, judged on what each sees, when it finds a leak, how it controls false positives, its blind spot and its price model. The data comes from Google's and Chrome's documentation and from each vendor's public website and help center, read on 9 November 2026. I have not run a side-by-side test, so the weaknesses are structural, not benchmark results.

## Where personal data gets into marketing tags

Most leaks are accidents of implementation, not decisions. A developer pushes a whole user object into the data layer. A form posts back with the email in the URL, and every tag on the confirmation page copies `page_location`. A site search sends the query, and some visitors type their phone number into it.

Google's own [guidance on avoiding PII in Analytics](https://support.google.com/analytics/answer/6366371?hl=en) lists the places to review:

-   the URL path and its parameters, and page titles;
-   custom dimensions and event parameters;
-   campaign parameters (`utm_source`, `utm_campaign` and the rest);
-   site search terms;
-   values users type into forms and search boxes.

It also tells you to consult a lawyer when you are unsure whether a field counts as PII. Keep that in mind for the rest of this post. A tool can find a candidate leak; it can't decide what the law says about it.

The same list applies to every other vendor on the page. Ad pixels, session recording, chat widgets and personalization tools all read URLs and the data layer. No GA4 setting covers them.

### What GA4's data redaction does, and what it doesn't

GA4 has a built-in [data redaction](https://support.google.com/analytics/answer/13544947) feature. It redacts email addresses across event parameters, and the query parameters you list in fields such as `page_location`, `page_referrer` and `link_url`. Email redaction is on by default for new properties.

Its limits matter more than the feature:

-   it works only for web data streams;
-   emails are matched "on a best-effort basis", in Google's words;
-   it does not cover the Measurement Protocol or Data Import;
-   it protects GA4 only. The same email in the same URL still reaches every other tag that reads it.

Treat redaction as a safety net for one destination, not as evidence that the page is clean.

## Five ways to find a leak, by the question each answers

| Method | What it sees | When it finds a leak | False positives | Blind spot |
| --- | --- | --- | --- | --- |
| Browser network inspection | Every request in one session: URL, headers, body, initiator | While you investigate | Few: a person reads each request | Only the pages, states and devices you test |
| Vendor diagnostics | One vendor's tags and consent signals | During setup or a debugging session | Few, for that vendor | Every other vendor on the page |
| Scheduled synthetic tests | Requests on scripted pages and journeys, by region and consent state | On schedule, or before release | Controlled with test data and rules | Flows nobody scripted |
| Pattern detection | Values that look like emails, phones, card numbers or IDs | At collection, in logs, or in an audit | Many, without context and allowlists | Unusual identifiers no rule describes |
| Live-traffic monitoring | Requests real users trigger, in production | As traffic flows, after a change ships | Reduced by baselines and evidence | Flows no user visits; endpoints it isn't installed on |

Most teams need three of these. Manual inspection establishes the truth about one incident. One automated layer runs before release or in production, with pattern rules inside it.

## Start with the free checks

Before buying anything, two free tools answer most first questions.

**Chrome DevTools.** The [Network panel](https://developer.chrome.com/docs/devtools/network) records requests while it is open, filters them by text or regular expression, and shows what initiated each one. Filter by your email address or test phone number, then walk the risky paths:

-   sign-up, login and password reset;
-   form submissions, including validation errors;
-   internal search;
-   checkout and support flows;
-   the consent banner: accept, reject, partial choice, and no choice yet.

Read the destination domain, the full URL, the request body and the referrer, not only the event name. If the browser is clean but a server-side container forwards data later, you have checked half the path. The [guide to inspecting the data layer](/understanding-and-inspecting-the-browser-data-layer-for-enhanced-website-performance) covers the other place a leak often starts.

**Tag Assistant.** Google's [consent debugging guide](https://developers.google.com/tag-platform/security/guides/consent-debugging) checks four things:

-   the default consent state is set before any tag fires;
-   it updates after the visitor's choice;
-   which consent types each tag checks;
-   whether those types were granted when each tag fired.

If your defaults vary by region, Google says to repeat the test with different simulated locations. The [consent mode v2 guide](/consent-mode-v2) walks through that check step by step.

Both tools are precise and both are narrow. DevTools sees one session. Tag Assistant sees Google tags. Neither repeats itself after the next release.

## The commercial tools, by the job they do

Three tools in this category document PII detection on their public sites. Two run scheduled tests in a robot browser; one watches live traffic.

### ObservePoint: scheduled audits and journeys

-   **What it does:** its [PII detection](https://help.observepoint.com/en/articles/9647497-pii-detection) captures the network requests the browser sends during an audit or journey, and filters tag variables and URLs with regular expressions. With test credentials it can crawl logged-in pages, and journeys can show which technologies read form inputs on submission.
-   **Best for:** repeatable audits of a large web estate, with reports a privacy team can file.
-   **Not for:** finding leaks in flows nobody scripted, or in native apps without extra setup.
-   **Weaknesses:** anonymous audits only surface location and IP data, so the useful checks need authenticated audits and maintained journeys. ObservePoint itself warns that PII patterns can match unrelated values in tag variables, so the regex needs refining.
-   **Pricing (November 2026):** not public; custom, based on page-scan volume ([ObservePoint](https://www.observepoint.com/pricing/)).

### DataTrue: scheduled testing with synthetic data

-   **What it does:** DataTrue [says](https://datatrue.com/en/) it tests in real browsers with synthetic user data, in every consent state (accepted, rejected, Global Privacy Control, no choice) and every region you choose. It alerts when personal data, such as a card number, goes to a domain that isn't on your approved list. It can test an unpublished Google Tag Manager container or Adobe Tags library before release, and covers native iOS and Android apps.
-   **Best for:** pre-release testing of consent and sensitive-data rules across regions.
-   **Not for:** detecting a leak in real users' traffic between test runs.
-   **Weaknesses:** it runs on the schedule you set, so it only sees the paths it tests. Synthetic data proves your rules work on your test values; it doesn't show what real users type. Mobile app testing is limited to the Enterprise and Unlimited plans.
-   **Pricing (public, November 2026):** from $16,000 a year (Starter, 10,000 pages a month) to $90,000 (Unlimited); the privacy toolset is included in every plan ([DataTrue](https://datatrue.com/en/pricing/)).

### Trackingplan: monitoring live traffic

-   **What it does:** Trackingplan monitors the analytics and marketing data a site sends in production (tags, pixels, events, consent and campaign parameters) and alerts when something breaks. On its [privacy page](https://www.trackingplan.com/landings/privacy), it says it flags emails, names, IDs and addresses in parameters, page paths and referrers, checks the consent state on every hit, and flags pixels that fire before the banner is answered. Rules can be [custom regex patterns or vendor presets](https://www.trackingplan.com/privacy-hub), and it says personal data is removed on the user's device before it reaches Trackingplan. Coverage includes web, apps and server-side.
-   **Best for:** sites that change often, where a new tag, release or CMP update can introduce a leak between audits.
-   **Not for:** proving that a rare flow is clean. If no user visits it, nothing is checked.
-   **Weaknesses:** it sees only traffic that happens, on the endpoints where it is installed. Pattern rules still need tuning for false positives. PII and consent checks sit in the Compliance module, which isn't available on the Starter plan.
-   **Pricing (public, November 2026):** the Compliance module is a €249-a-month add-on to Growth (from €699 a month) and included in Enterprise (from €2,000 a month) ([Trackingplan](https://www.trackingplan.com/pricing)).

### The three side by side

|     | ObservePoint | DataTrue | Trackingplan |
| --- | --- | --- | --- |
| What it watches | Robot browser on audits and journeys | Robot browser with synthetic data | Real users' requests |
| When it finds a leak | On schedule | On schedule, and before publishing a container | Continuously in production |
| Consent states tested | Configured in audits and journeys | Accepted, rejected, GPC, no choice; by region | Checked on every real hit |
| Native apps | Through a [device proxy](https://help.observepoint.com/en/articles/9106718-observepoint-applications-mobile-app-validation), depending on contract | iOS and Android (Enterprise and Unlimited) | iOS and Android SDKs |
| PII rules | Regex on tag variables and URLs | Approved-domain list for sensitive data | Regex or vendor presets |
| Pricing (November 2026) | Not public | From $16,000/year | Compliance from €249/month on Growth |

For the broader comparison of these approaches beyond privacy, see [auditing analytics without manual test plans](/audit-analytics-without-manual-test-plans).

## Questions to ask before you buy

Ask each vendor the same questions, and ask to see the answer on your own site:

-   Which endpoints, apps and server-side routes does it see, and which does it miss?
-   Which consent states and regions does it test or check?
-   Where is personal data masked, and what sample is stored as evidence?
-   How do I write a custom rule, and how do I allowlist test values?
-   How long between a leak starting and the alert, and who receives it?
-   What drives the price, and is privacy detection included or an add-on?

A vendor that can't show its masking and evidence on a real finding is asking you to trust a second copy of your users' data.

## Pattern rules: how to keep the false positives down

Whichever tool runs the rules, an alert that fires on every product ID gets ignored by the second week. Five controls keep pattern detection useful:

1.  **A primary pattern:** an email-shaped value, a phone number, a card-like sequence.
2.  **Context:** the field or event name it appeared in. An email-shaped value in `user_email` is more likely to be real than one in `promo_code`.
3.  **An allowlist:** your synthetic test values and identifiers you know are not personal.
4.  **A severity level:** a raw email sent to an ad pixel is not the same as a weak match in a URL fragment.
5.  **A masked sample:** enough evidence to prove what happened, without storing a second copy of the data you are trying to protect.

## Choose by your situation

-   **You suspect one leak today.** DevTools first: follow the value from the page to every domain that receives it.
-   **You are launching a form, checkout or regional consent setup.** A scheduled synthetic test, with ObservePoint or DataTrue, gives you a repeatable check before and after release.
-   **Your site ships weekly and several teams publish tags.** Live-traffic monitoring, with Trackingplan or a comparable tool, catches the leak a release introduces before the next audit would.
-   **You need evidence for a privacy or legal review.** Combine a scheduled audit for documented runs with monitoring for what happens between them.

## What a useful finding has to say

"Email detected" creates work. A finding someone can act on says which field carried the value, which request and destination received it, which page, release or server route introduced it, the consent state and region, whether the value was raw or hashed, and who owns the fix. After the fix, run the same path and consent states again and keep both results.

## Three things to keep apart

**Hashing is not anonymization.** Under the GDPR, [Recital 26](https://gdpr-info.eu/recitals/no-26/) says pseudonymised data that could be attributed to a person with additional information is still information about an identifiable person. The UK ICO's [pseudonymisation guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/pseudonymisation/) names hashing as one of those techniques. A hashed email sent to a pixel needs the same consent as the email.

**A policy is not payload evidence.** A privacy policy, a DPA or a vendor questionnaire describes intended processing. Only the request shows what a tag actually sent.

**Detection is not compliance.** A tool finds candidate leaks. Minimization, consent enforcement, retention, contracts and legal judgment decide what you do about them.

## What to check this week

-   Run your sign-up and checkout flows with DevTools open, filtered by your test email, and list every domain that receives it.
-   Check that GA4 data redaction is on for your web streams, and remember that it protects GA4 only.
-   Repeat one high-risk flow with consent rejected and confirm that no ad pixel fires. The [GA4 audit checklist](/ga4-audit-checklist) has the rest of the collection checks.

![](/images/about-me/davidpombar_profile.jpg)

Written by [David Pombar](/about-me). Chief Revenue Officer and Swiss Army knife at Trackingplan. Lives in A Coruña, Galicia.