What is PII in GA4 and why does it matter?
PII (Personally Identifiable Information) in GA4 refers to data that can identify a specific individual — email addresses, phone numbers, names, national insurance numbers, passport numbers, and similar attributes. Sending PII to GA4 violates Google's Terms of Service and GDPR Article 5(1)(c) (data minimisation). Google's ToS explicitly prohibit sending "data that Google could use or recognise as personally identifiable information." If Google detects PII in your GA4 data stream, they may send a notification requiring remediation — and in serious cases, may suspend the property. The most common PII sources in GA4: email addresses in URL query strings (e.g., /confirm?email=user@example.com), user names in page titles, and parameter values containing customer data passed carelessly from the dataLayer.
How PII ends up in GA4
Route 1 — URL query strings
The most common route. When a user completes a form, many platforms append their submitted data to the confirmation page URL:
GA4's page_location parameter captures the full URL including query string. This sends PII directly to Google's servers.
Also common:
- Email verification links:
/verify?token=GUID&email=user@example.com - Password reset links:
/reset?email=user@example.com - CRM redirect links with customer data:
/campaign?contact_id=12345&email=user@example.com
Route 2 — Page titles containing user data
Some CMS and app frameworks include user-specific data in page titles:
GA4's page_title parameter captures this and sends the name to Google.
Route 3 — Custom parameters from the dataLayer
When developers push dataLayer events for personalised features, they sometimes include PII:
Route 4 — Referrer URLs containing PII
Some email platforms construct click-through URLs that include the recipient's email in the URL path or query string. When users click these links, the full URL (with email) is captured as page_referrer or page_location.
GA4's built-in redaction settings
GA4 has built-in automatic redaction for recognised PII patterns in URLs:
Enable in GA4: Admin → Data Streams → Web stream → Configure tag settings → Show all → Redact data
Settings to enable:
Need to validate whether consent timing is distorting your GA4 data?
- Redact page URL and page title — strips recognised PII patterns (email addresses, phone-like patterns) from
page_locationandpage_titlebefore sending to GA4 servers - URL query parameter redaction — strips URL query parameters (useful if your confirmation pages always append user data as query strings)
Limitation: Automatic redaction only catches recognised patterns (email formats, phone number patterns). It cannot redact PII embedded in arbitrary parameter values or dataLayer custom events. Use it as a safety net, not as a primary control.
GTM patterns for PII prevention
Pattern 1 — Strip query parameters at the GTM tag level
In your GA4 Configuration tag in GTM, use a custom JavaScript variable to strip sensitive query parameters from the page URL before it's sent as page_location:
In the GA4 Configuration tag → Fields to Set → page_location → set to the "Clean Page URL" variable.
Pattern 2 — Block PII-containing events at GTM level
Create a GTM blocking trigger that prevents the GA4 event tag from firing if the event contains known PII parameters:
Create a custom variable that checks the dataLayer for PII:
Use "Contains PII" as a blocking condition on GA4 event tags — if the variable returns true, the tag does not fire.
Pattern 3 — Server-side GTM redaction
If you're using server-side GTM, implement redaction at the sGTM client level before forwarding to GA4:
Server-side redaction is the most robust control because it processes all hits centrally before any data reaches Google's servers.
Detecting existing PII in your GA4 property
Check 1 — Page location report for email patterns
GA4 Reports → Engagement → Pages and Screens → Search the page path table for @ (@ symbol is nearly always PII in a URL).
If you find pages with @ in the path, investigate those URL patterns and add redaction.
Check 2 — BigQuery query for email patterns in page_location
If this returns results, you have PII in your GA4 data. Delete the affected data using GA4's data deletion request tool (Admin → Data Deletion Requests) and implement prevention measures immediately.
FAQ: GA4 Data Redaction and PII Prevention
Can ga4 data redaction and pii prevention be caused by consent timing instead of a tag bug?
Should I test this only in GA4 reports?
What is the fastest way to prevent this from happening again?
Related guides for GA4 Data Redaction and PII Prevention
How to Test Consent Mode V2 in 5 Minutes: A DevTools Walkthrough (2026)
Open Chrome DevTools → Network tab → filter for collect → reject all on the cookie banner → confirm GA4 hits still fire with gcs=G100 (denied) and ad_user_data=denied. Then accept all → confirm gcs=G111 (granted). If hits don't fire at all in either state, Consent Mode is misconfigured. If gcs is missing entirely…
GCS Parameter Decoded: What G100, G110, G111 Mean in GA4 Hits
The gcs parameter in GA4 network requests encodes the user's consent state for two of the four Consent Mode signals. Format: G1xy where G1 is constant, x is ad_storage (0=denied, 1=granted), y is analytics_storage (0=denied, 1=granted)…
Validate GA4 Data Redaction and PII Prevention before it becomes a compliance and reporting problem
Run a free audit to check consent timing, browser behavior, and downstream GA4 impact in one workflow.