What is the Google Analytics 4 Do Not Send PII Policy?

Using Google Analytics 4 comes with a critical rule you accept the moment you install the tracking code: you cannot send personally identifiable information (PII) to Google's servers. This isn’t just a line in the terms of service, it’s a strict policy with serious consequences if ignored, accidentally or otherwise. This article breaks down exactly what the GA4 Do Not Send PII policy means, how to identify common ways PII accidentally gets collected, and offers a practical checklist to keep your analytics clean and compliant.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

What Exactly Is "Personally Identifiable Information" (PII)?

Google defines PII as any information that could be used on its own to directly identify, contact, or locate an individual person. It's the kind of data that, if you saw it in a report, would let you say, "Oh, that's Jane Doe from New York." Think of it as data directly attached to a real person's identity.

This policy isn't just Google being overly cautious. It's tied directly to major privacy regulations like Europe's General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA), which impose massive fines for mishandling user data. By forbidding PII in its standard reports, Google protects both itself and you from significant legal risk.

Here are the most common examples of PII that you must never send to Google Analytics:

• Names: Full names (e.g., &name=Jane_Doe)
• Email Addresses: The most frequent offender (e.g., &email=jane.doe@example.com)
• Mailing Addresses: Physical addresses, street names, etc.
• Phone Numbers: Any direct phone line
• Precise Location Data: Specific GPS coordinates, beyond general country or city data
• Social Security Numbers or National IDs: Any government-issued identifier

It’s important to distinguish PII from non-PII, ID-like data points. Google encourages the use of identifiers that are pseudonymized, meaning they don't directly reveal a user's identity. These include:

• User-ID (a custom ID you assign to logged-in users, like user_id = 48291)
• Hashed or encrypted identifiers (e.g., a "hashed" email address)
• Mobile advertising IDs (like IDFA or an Android advertising ID)

The key difference is that a code like 48291 means nothing to someone at Google looking at analytics reports. John Smith's email address, however, very clearly identifies John Smith.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

How Does PII Sneak Into Google Analytics 4?

It sounds simple enough: don't collect names and emails. But in practice, PII finds its way into analytics data unintentionally. Most businesses don’t decide to break the rules, they just have a technical setup that accidentally captures and sends PII without their knowledge. Here are the biggest culprits.

URL Query Parameters

This is, by far, the most common source of PII leakage. Query parameters are the bits tacked onto the end of a URL after a question mark (? sign), used to pass information from one page to another or track campaign details.

Imagine a user fills out a "contact us" form, and upon submission, they are redirected to a thank-you page. A poorly configured setup might pass their form input directly into the URL, creating something like this:

https://www.yourwebsite.com/thank_you?name=John+Smith&email=john.smith@email.com

Google Analytics automatically records the full page URL, including all those parameters. Suddenly, you have John Smith's name and email sitting in your GA4 reports as part of the page_location dimension. This is a direct violation.

You most often see this after form submissions, in login redirect flows, or from links in email marketing campaigns that haven’t been properly configured.

Event Parameters and User Properties

GA4's event-based model is powerful, but it also creates new opportunities for mistakes. When you set up custom events, especially through Google Tag Manager (GTM), you might create a variable that pulls the value from a form field. If that form field is for an email address or name, you'll send PII.

For example, you might create a form_submission event and include an email_address event parameter that captures the user’s input. If you're using JavaScript variables in GTM that grab the value of an id="email" HTML element on the page, you're directly capturing and sending PII to GA4.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

Page Titles and Content

This is less common, but it can happen. If a page's <h1>, or <title>, tag is dynamically generated to include the user's name (e.g., "Welcome, Sarah Miller! Fulfill your order now.") after a login, that PII can be recorded in your page reports. GA records the page title by default, and this PII-laced greeting comes along for the ride.

Data Import Features

GA4 allows you to import external data, like CRM data, to enrich your analytics reports. If you upload a CSV file to join with your analytics hits and that file contains a column for user_email or customer_name, you’ve again violated the policy. All imported data must be stripped of PII before upload.

The Consequences of Sending PII to Google

Ignoring Google’s PII policy can have very real consequences, ranging from annoying to business-critical.

• Data Deletion by Google: If Google's automated systems or a manual review detects PII in your account, they have the right to delete all the data for the time period in which the PII was present. This can create massive, unrecoverable holes in your historical data.
• Account Suspension or Termination: For repeated or egregious violations, Google can suspend or completely terminate your Google Analytics property, and in some cases, your entire Google account. All historical data would be lost permanently.
• Legal and Financial Risk: Storing user PII in a system not designed to secure it can put you in violation of GDPR and other privacy laws. This could lead to fines and legal action, especially if your account experiences a data breach.
• Loss of User Trust: If users find out their personal information is being passed insecurely through your website's analytics, it can severely damage your brand's reputation.

A Practical Checklist to Find and Prevent PII in GA4

Staying compliant requires a proactive approach. Don't wait for Google to send you a warning email. Periodically use this checklist to audit your account and prevent PII from slipping through.

1. Audit Your URLs in the GA4 Interface

This is the first and fastest check you can perform.

• In GA4, go to Reports > Engagement > Pages and screens.
• Make the Page path and screen class dimension the primary dimension.
• In the search box just above the table, search for the "@" symbol. This will instantly show any pages where an email address was passed in the URL.
• Also try searching for ?fname=, ?lname=, ?email=, or ?phone= to uncover query parameters capturing PII.
• Expand the date range to look over several months to catch anything you might have missed.

2. Review Your Google Tag Manager Configuration

If you use GTM, this is where most mistakes happen. Go through your container and check for risks.

• Check Your Variables: Look at your list of user-defined variables. Are any of them "DOM Element" variables or "JavaScript Variables" that scrape the value of form fields like email, user_name, or phone_number? If so, find out where they are being used.
• Inspect Your Tags: Check your GA4 Event tags. Look at the "Event Parameters" and "User Properties" sections. Confirm that none of the variables you're passing in those fields contain PII.

3. Use Google's Intended User Tracking: The User-ID Feature

Google provides a compliant way to track individual users across sessions and devices: the User-ID feature. You are responsible for generating a unique, non-personally-identifiable ID for each of your logged-in users (e.g., user_id: "xyz-123"). You can then pass this User-ID to GA4.

This gives you a powerful way to understand user behavior at the individual level without ever sending a name or email address to Google. This is the correct, privacy-safe method for robust user analysis.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

4. Check and Clean Data Imports

If you use the Data Import feature, set a strict process for vetting files before upload. Double-check that all CSVs have been scrubbed of any columns containing PII. In your data preparation workflows, always remove columns like email, first_name, last_name, etc., before creating the final upload file.

5. Hash Your Data (For Advanced Users)

For sensitive identifiers you might need for integration with other platforms, you can use a cryptographic hashing algorithm (like SHA-256) before sending the data to GA. Hashing turns a string like "john.smith@email.com" into an irreversible, anonymous-looking string like e45e71e75e5f3ad3a824ebb61d713c772c9165b4528cde59f848772a1ce0a58a.

Google accepts hashed information because it cannot be reverse-engineered back into the original PII. This allows you to track users in a privacy-safe manner. However, this is a technical solution and should be implemented carefully by a developer.

Final Thoughts

Google's Do Not Send PII Policy isn't just a suggestion - it's a requirement for using Google Analytics responsibly. Understanding what PII is and where it comes from, primarily through misconfigured URLs and tagging, is essential for every marketer and business owner. Regularly auditing your URL data and GTM setup can save you from data loss, account suspension, and legal headaches.

Staying on top of compliance complexities is one of many manual burdens marketing and sales teams face. At Graphed , we automate the connection to all your key data sources, including Google Analytics, so you can stop manually pulling reports and get straight to insights. Instead of getting stuck in debugging data streams or building reports from scratch every week, you can simply ask questions in plain English, like "Compare my ad spend versus revenue this month," and get a live, interactive dashboard built for you in seconds.