PII Leaks in GTM: How to Find and Fix Them Before Google Does.

Sending Personally Identifiable Information (PII) to Google Analytics is a violation of Google's Terms of Service — and it can lead to your GA4 property being permanently deleted with no recovery option. This isn't a theoretical risk: Google actively scans for PII patterns in analytics data, and we've seen properties suspended without warning.

The problem is that PII leaks are almost never intentional. They happen because of URL structures that include email addresses, form tracking that accidentally captures personal data, or backend developers pushing user objects to the data layer without understanding what GA4 collects. This guide explains exactly where PII hides, how to detect it, and how to build systematic prevention into your implementation.

What Counts as PII

Google's PII Definition

Google defines PII as any data that could be used to directly identify, contact, or precisely locate a specific individual. This includes:

• Email addresses — The most common PII leak in analytics implementations.
• Phone numbers — Often captured via click-to-call tracking or form fields.
• Full names — First + last name combinations, especially from form submissions.
• Physical addresses — Street addresses, postal codes in some jurisdictions.
• Social security / national ID numbers — Extremely sensitive; any exposure is a serious incident.
• Credit card numbers — Should never appear in analytics under any circumstances.
• Login credentials — Usernames that are email addresses, passwords in error messages.

Note that hashed email addresses are generally acceptable (and are even recommended for features like Enhanced Conversions). The issue is with unhashed, plaintext PII appearing in your analytics data.

Where PII Hides in Your Implementation

URL Parameters

This is the most common source of PII leaks. GA4 automatically collects the full page URL with every page_view event. If your URLs contain PII in query parameters, it goes straight to Google:

// These URLs send PII to GA4 automatically:
example.com/login?email=john@example.com
example.com/password-reset?user=jane.doe@company.com
example.com/profile?name=John+Smith&phone=555-123-4567
example.com/order-confirmation?email=customer@email.com&order=12345

Common culprits include login redirect URLs, password reset links, form submission confirmation pages, and email marketing links that pass user identifiers.

Form Submissions and Click Tracking

If you're using Custom HTML tags or Auto-Event Variables to capture form field values, you may be sending PII without realizing it. For example, tracking a "form_submit" event that captures the form field values will include whatever the user typed — including their email, name, and phone number.

DataLayer Pushes from Backend

Backend developers often push user objects to the data layer that include full user profiles. If these objects contain email, name, or phone fields, and your GTM tags are reading from the data layer, PII ends up in GA4:

// BAD: This pushes PII to the data layer
dataLayer.push({
  user_email: 'john@example.com',  // PII!
  user_name: 'John Smith',          // PII!
  user_phone: '+1-555-123-4567',    // PII!
  user_type: 'premium'              // This is fine
});

// GOOD: Use hashed or anonymized identifiers
dataLayer.push({
  user_id: 'abc123def456',           // Opaque ID
  user_type: 'premium',
  hashed_email: 'sha256hash...'      // Hashed (for Enhanced Conversions)
});

User-ID and Custom Dimensions

Using an email address as the GA4 User-ID is a direct PII violation. The User-ID must be an opaque, non-reversible identifier — not an email, phone number, or any other PII. Similarly, custom dimensions should never contain plaintext PII values.

Page Titles and Site Search

Some CMS platforms include user information in page titles (e.g., "Welcome, John Smith - Dashboard"). GA4 collects page titles automatically. Site search terms are also collected by Enhanced Measurement — if users search for email addresses or personal information, that data goes to GA4.

Prevention Strategies

1. URL Sanitization via Custom JavaScript Variable:

   Create a Custom JavaScript variable in GTM that strips PII patterns from URLs before they're sent to GA4. Use regex to detect and redact email patterns, phone numbers, and other PII from the page location and page referrer values.

   // Example: Redact emails from URLs
   function() {
     var url = {{Page URL}};
     return url.replace(/([a-zA-Z0-9._-]+@[a-zA-Z0-9._-]+.[a-zA-Z0-9_-]+)/gi, '[REDACTED]');
   }

2. GA4 Data Redaction:

   GA4 has a built-in "Redact data" setting in Admin → Data Streams → Configure Tag Settings. Enable "Email redaction" to automatically redact email-like patterns from event parameters. However, do not rely on this alone — it doesn't catch all PII types.

3. Server-Side GTM Filtering:

   If you're using server-side GTM, add a transformation that strips PII patterns from all incoming event data before forwarding to GA4. This creates a centralized PII filter that protects against leaks regardless of what the client-side sends.

4. Backend Data Layer Guidelines:

   Create a data layer specification document for your development team that explicitly lists which fields are safe to push and which are prohibited. Review every new data layer push before it goes live.

5. Regular Audits:

   PII leaks often come from new feature deployments, not from the initial setup. A CMS update, a new form, or a marketing team adding query parameters to email links can introduce PII leaks at any time. Audit quarterly at minimum.

How to Check If You're Already Leaking PII

1. BigQuery Export: If you have BigQuery export enabled, run a query searching for email patterns in page_location, page_referrer, and event parameters. Use regex like r'[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}'.
2. GA4 Explorations: Create a free-form exploration with "Page location" as a dimension. Scan through the URLs for query parameters containing email addresses or names.
3. GTM Custom HTML Audit: Review every Custom HTML tag in your container. These are unrestricted and can capture anything from the page DOM.
4. Network Tab Analysis: Use Chrome DevTools to monitor GA4 collection requests and inspect the payload for PII patterns.

Key Takeaways

• PII in GA4 violates Google's Terms of Service and can result in permanent property deletion.
• URL parameters are the most common source of PII leaks — GA4 automatically collects the full page URL with every page_view.
• Never use email addresses as User-IDs — use opaque, non-reversible identifiers.
• Enable GA4's built-in email redaction, but don't rely on it exclusively — implement URL sanitization in GTM as well.
• Audit for PII quarterly, especially after new feature deployments, CMS updates, or marketing campaigns that modify URL parameters.

Frequently Asked Questions

What is PII in GTM?

PII in GTM stands for Personally Identifiable Information — any data that could be used to directly identify, contact, or locate a specific individual. In a GTM context, PII refers to personal data that passes through tags, variables, or data layer pushes and potentially gets sent to third-party analytics or advertising platforms. Common examples include email addresses in URL parameters, full names captured from form fields, phone numbers in click-to-call tracking, and User-IDs set to email addresses. Google's Terms of Service explicitly prohibit sending PII to GA4, and violations can result in property suspension.

How do GTM PII leaks happen?

GTM PII leaks happen through several mechanisms, almost always unintentionally. The most common is URL parameters — GA4 collects the full page URL automatically, and if your site passes email addresses in query strings (login redirects, password resets, email marketing links), that data flows into analytics. Form tracking leaks occur when Custom HTML tags or Auto-Event Variables capture form field values verbatim, including whatever personal data the user typed. Data layer leaks happen when backend developers push user profile objects to the data layer without understanding that GTM reads and forwards those values to analytics platforms.

How do I find PII in my GTM container?

To find PII risks in your GTM container, audit these four areas: first, review every Custom HTML tag — these are unrestricted JavaScript blocks that can capture and send anything from the page, including form values. Second, check your Data Layer Variables and what fields they read — any variable reading a field that could contain personal data is a risk. Third, examine your trigger configurations for form submission triggers that capture field values. Fourth, look at your tag configurations for any event parameters that pass click text, form field content, or page titles. Use the GTM preview mode to observe exactly what data gets sent in tag payloads for pages that handle user data.

What PII can accidentally end up in GTM?

The most common types of PII that accidentally end up in GTM are: email addresses (most frequently, via URL parameters from login redirects, password resets, and email campaign links); full names (from form submission tracking or page titles in account dashboards); phone numbers (from click-to-call link tracking where the link text is the phone number); and user identifiers that are set to email addresses rather than opaque internal IDs. Less common but higher-severity leaks include national ID numbers on government service sites, financial account information on banking sites, and authentication tokens or session IDs that appear in URLs.

How do I prevent email addresses from leaking into GA4?

To prevent email addresses from leaking into GA4, implement three layers of protection. First, enable GA4's built-in email redaction under Admin → Data Streams → Configure Tag Settings → Redact data — this automatically strips email-like patterns from event parameters before they're stored. Second, create a Custom JavaScript variable in GTM that sanitizes the page URL by replacing email patterns with "[redacted]" before passing the value to any GA4 event tag — this catches URL-parameter leaks that the GA4 redaction setting may miss. Third, audit your data layer specification with your development team and explicitly prohibit pushing email addresses as data layer values; use opaque user IDs instead.

Does GTM automatically redact PII?

GTM itself does not automatically redact PII — it sends whatever data your tags and variables are configured to send. GA4 does have a built-in email redaction setting (under Data Streams → Configure Tag Settings) that automatically strips patterns matching an email address format from event parameters before storing them. However, this setting only applies to GA4 and only catches email-like patterns — it does not redact phone numbers, names, or other PII types, and it does not prevent other tags in your container (Meta Pixel, Google Ads, etc.) from receiving that data. Active prevention via URL sanitization variables and data layer policies is required.

What is data layer scrubbing in GTM?

Data layer scrubbing refers to the practice of intercepting data layer pushes and removing or replacing PII before GTM reads and forwards the data to analytics platforms. It can be implemented in two places: on the site itself, where the development team ensures that only anonymized data is pushed to the data layer in the first place (preventing PII from ever entering the data layer); or in server-side GTM, where incoming event data is transformed to strip PII patterns before being forwarded to downstream destinations like GA4. Client-side scrubbing at the data layer level is the most reliable approach because it addresses the leak at its source rather than relying on downstream filters.

What are the consequences of PII leaking into analytics?

The consequences of PII leaking into analytics fall into three categories. The most immediate is a Google Terms of Service violation: Google actively scans GA4 properties for PII patterns and can delete a property permanently without warning, destroying months or years of historical data with no recovery option. The second category is regulatory — sending personal data to Google without proper legal basis (under GDPR, CCPA, or other privacy regulations) exposes the organization to regulatory enforcement, fines, and required breach notifications to affected users. The third is reputational: if a data leak is discovered through a user complaint or audit, the organization's handling of personal data becomes a public trust issue.