Sending personally identifiable information to Google is against the rules, and it happens by accident constantly – an email in a URL, a name in a form field, a phone number in a page path. GTM is where you catch it before it leaves. Here is how to block PII.

Why this matters more than it seems

Google's measurement products explicitly prohibit sending PII like emails, names, and phone numbers, and a property found doing it risks data deletion or worse. Beyond Google's rules, leaking PII into analytics is a privacy and legal liability. The goal is to strip or hash identifiers before any tag transmits them.

Find where PII leaks in

PII rarely enters on purpose; it slips in through predictable channels:

  • Query parameters, such as an email passed in a URL after a form submit.
  • Page paths that embed a user identifier or order email.
  • Form-field variables captured a little too broadly.
  • Referrer URLs from another site that carried PII in them.

Redact it with a transformation

The reliable fix is a function that scrubs known PII patterns out of a value before it is sent. An email redactor is the classic example:

function redactPII(value) {
  return value
    .replace(/[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}/gi, '[email]')
    .replace(/\+?\d[\d\s().-]{7,}\d/g, '[phone]');
}
// Run page_location and page_referrer through redactPII
// before they reach any tag.

Apply it to the fields most likely to carry PII, especially page_location and page_referrer, so the cleaned value is what every downstream tag sees.

Do it server-side for a real guarantee

Client-side redaction helps, but a determined leak can still slip past it. Server-side GTM is the stronger control, because every hit passes through your tagging server, giving you one chokepoint to inspect and scrub data before it is forwarded to any vendor. If you already run server-side, enforce redaction there so nothing reaches Google or Meta uncleaned.

Verify with real bad data

Test the way leaks actually happen. Submit a form with a real-looking email, then check in Preview and DebugView that the value arriving at your tags is redacted, not raw. Re-test whenever the site adds new forms or URL patterns, since a new page is exactly where the next accidental leak appears.

Hash instead of drop when you need the match

Sometimes you genuinely need an identifier to reach a platform, for enhanced conversions or a conversion API, and there dropping it defeats the purpose. The answer is not to send raw PII but to hash it first, normalizing the value and applying SHA-256 so the platform can match on the hash without ever receiving the plain email. Dropping is for PII that should never leave; hashing is for identifiers a platform is explicitly designed to accept in hashed form. Know which case you are in.

Audit what you already send

Before adding new controls, look at what is leaking today. Walk your live tags and the parameters they send, checking page paths, query strings, and any custom fields for real user data, because the leak is usually something already in production, not a hypothetical. Make redaction a standing rule for new tags too, documented so the next person does not reintroduce the problem the first time they add a form.

PII reaches Google by accident far more often than on purpose, through URLs, paths, and fields nobody meant to expose, and GTM is the place to catch it. Know where it leaks, redact the known patterns, enforce it server-side for a real guarantee, and test with realistic data. Do that and the accidental leak that could have cost you your data stops at the door instead of landing in your reports.

Want a stronger data analyst role or a raise? Grab the FREE Product Analyst Playbook and get the exact roadmap to your next offer.