Also called: PII in analytics, personal data leak, PII leak GA4
The classic case is a password-reset or checkout URL carrying ?email=user@example.com. GA4 records the full page path, so the address lands in your reports and in Google's systems. Google's terms prohibit sending PII, and a property found in breach can be deleted.
Search boxes are the second common source: users paste their own email or order number into a site search, the query is captured as an event parameter, and it flows straight into analytics.
Detection is pattern-based and cheap — scan collected URLs, page titles, and dataLayer keys for email and phone shapes. Remediation is either redacting the parameter before the tag reads it, or removing it from the URL entirely.
PII in an analytics property is simultaneously a GDPR incident, a breach of Google's terms of service, and unfixable retroactively — you cannot delete a value out of historical GA4 data once it has been collected.
Check the Pages and screens report for query parameters containing @ or digit sequences that look like phone numbers, and review your event parameters for free-text fields. Automated container audits scan the same surfaces continuously rather than at review time.
The affected data cannot be selectively removed — Google's remedy is deletion of the property or the data range. Fix the source first, then decide whether the contaminated range needs to be discarded.
For Google Analytics purposes, do not send it at all. Google prohibits sending identifiers to Analytics regardless of hashing. Hashed identifiers belong in the advertising features designed for them, such as enhanced conversions and the Conversions API.
TagEasy's free auditor checks any URL for Consent Mode v2 signals, PII in tracking, duplicate pixels, and 10 other tracking-quality faults. No signup.
