Keeping PII out of GA4 (Google can delete your data if you don't)

Google's terms prohibit sending personally identifiable information to Google Analytics, and the enforcement is not theoretical — Google can and does delete data, or entire properties, when PII is detected. The uncomfortable part is that most PII in GA4 was never sent deliberately. It arrives in page URLs, in form field values swept up by automatic event tracking, and in parameters someone added for a good reason without thinking about where they land.

What counts as PII here

Google's definition is broader than many teams assume. Treat all of the following as prohibited in GA4:

• Email addresses, in any field, including hashed ones — GA4 is not the place for hashed identifiers either.
• Phone numbers.
• Full names.
• Street addresses.
• Government identifiers, national insurance or social security numbers.
• Payment card numbers.
• Precise geolocation beyond what GA4 collects itself.

What is permitted: pseudonymous identifiers you control — a customer ID that means nothing outside your systems, sent as user_id. That is explicitly supported and is how cross-device stitching is meant to work.

The four ways PII actually gets in

1. URLs — by far the most common

A form that submits via GET, a password reset link, a booking confirmation, an unsubscribe link with the address in a query parameter:

/confirmation?email=jane.doe@example.com&order=10432
/account?user=jane.doe@example.com

The page URL is collected as page_location on every event, and it is sent to every analytics and advertising tag on the page. One such page leaks that address to Google, Meta, and everyone else simultaneously. This is why "PII in URL" is a hard failure on any tracking audit rather than a warning.

2. Automatic event collection

Enhanced measurement's form interaction events can capture field values or identifying attributes depending on how the form is built. Search tracking captures the query string — and site search boxes get used for email addresses more often than you would like.

3. Custom parameters added without review

Someone adds customer_email to a purchase event because it is useful for debugging, and it is never removed. Or a CRM identifier that happens to be an email address gets passed as a user property.

4. Enhanced Conversions bleeding into GA4

This one is subtle and increasingly common. Enhanced Conversions legitimately need email and phone for Google Ads. If those values are pushed into a shared dataLayer, every tag in your container can read them — including GA4. The Ads implementation is correct; the leak is a side effect.

How to find PII you already have

Search the URL dimensions. In GA4, look at page path and page location for the @ character, and for parameter names like email, phone, user, token. This finds the biggest category in minutes.

Check your search terms report. Site search queries containing @ are common and are collected as parameters.

Review every registered custom dimension. Ask, for each, whether its values could identify a person outside your systems.

Query BigQuery if you have the export. A pattern match across event parameters is the only exhaustive way to audit historical data — another argument for enabling the export.

Run an external audit. A page-level check catches PII exposed in URLs on public pages immediately, without account access.

Fixing it

Fix the source first

Change forms from GET to POST so values never reach the URL. Move identifiers out of query strings and into path segments that are opaque, or into POST bodies. This is the only permanent fix — everything else is mitigation.

Redact before collection

Where you cannot change the URL — a third-party system, a legacy flow — strip the values before the tag sends them. In GTM, override page_location and page_referrer with a cleaned value:

// Custom JavaScript variable returning a redacted location
function () {
  var url = new URL(window.location.href);
  ['email', 'phone', 'token', 'user'].forEach(function (p) {
    if (url.searchParams.has(p)) url.searchParams.set(p, 'redacted');
  });
  return url.toString();
}

Then also redact any pattern that looks like an email in the path, since parameters are not the only route.

Keep Enhanced Conversions data isolated

User-provided data for Ads should live in variables consumed only by the Ads conversion tag — not in a general-purpose dataLayer key that every tag can read.

Turn off collection you do not need

If form interaction events are capturing values you cannot control, disable that part of enhanced measurement and implement form tracking deliberately instead. Tracking form submissions properly gives you better data anyway.

What to do about historical data

Once collected, PII cannot be selectively removed from GA4's interface. Your options are narrow:

• Google's data deletion request in the property, which is coarse — it removes by date range and category rather than surgically.
• Wait out retention, and reduce your data retention window if it is set long.
• In extreme cases, a fresh property. Painful, and occasionally the right answer if contamination is deep and ongoing.

None of these are pleasant, which is why the source fix matters more than the cleanup.

FAQ

Is a hashed email address acceptable in GA4?

No. Google's policy prohibits sending PII including hashed forms to Analytics. Hashed identifiers are for advertising products like Enhanced Conversions and Customer Match — not for GA4.

Can I send a user ID to GA4?

Yes, provided it is a pseudonymous identifier that cannot identify a person outside your systems. An internal customer ID is fine; an email address is not, even as the value of a field called user_id.

What happens if Google finds PII in my property?

Google reserves the right to delete affected data and, in serious cases, the property. In practice most teams discover the issue themselves first — but the risk is real and the cleanup is coarse.

How do I stop email addresses appearing in my page URLs?

Change the form to POST, or move the identifier out of the query string entirely. Redaction in the tag is a mitigation for cases you do not control, not a substitute for fixing the source.

Does IP anonymisation solve the PII problem?

No. GA4 does not log full IP addresses in the first place, and that has nothing to do with emails, phone numbers, or names arriving in URLs and parameters.

The fastest way to find the most common leak: the free tracking audit flags PII in the audited URL, alongside twelve other checks, with no signup.