Email addresses (PII) leaking into GA4

Symptom and cause

Symptom

Customer email addresses sitting in GA4 page URLs and event parameters, splitting your page reports and breaking Google's PII policy.

Cause

Forms passing email or phone into the URL on submit; success pages carrying PII in query strings; other tags on the same page reading the same URL.

Where it's caught

Page reports with @ in the URL; query parameters like ?email=; Data redaction switched off on a property created before the feature, or no query parameters listed.

How an email address ends up in a GA4 page URL

GA4 records the full address of every page it sees, query string included, in a parameter called page_location. If the URL carries an email address, so does GA4. Nothing warns you. The standard Pages and screens report shows the page title or the path without the query string by default, so a search for @ there can come back clean while page_location is full of addresses.

Five routes put it there. I check them in this order.

A form with no method. An HTML form without method="post" submits with GET, the browser's default, and GET appends every field to the URL after a ?. A newsletter box built that way sends the visitor to /[email protected], and the tag on the thank-you page reads the whole thing. Forms that normally submit by JavaScript do it too when the handler does not load, or fails before it cancels the browser's own submit.

A redirect that hands the address on. The form posts correctly, then the server redirects to a confirmation page with ?email= so the page can say "we sent a link to [email protected]". Account, booking and password-reset flows do this.

Email links. Email platforms can put the subscriber's address into a link through a merge field, to pre-fill a form or identify the click. Every visitor from that campaign lands with their address in the URL. UTM values built from a name or an address do the same, and Google names campaign parameters as a risk.

Page titles and site search. A title like "Order confirmed for Jane Smith", or an address typed into the search box, reaches GA4 as page_title or search_term.

Your own tags. A form event that pushes the typed address into the dataLayer, or a user_id set to the customer's email, sends it on purpose. Register that parameter as a custom dimension (F-601) and it sits in reports for anyone with access.

Why it matters. Google's policy says no data may be passed to Google that Google could use or recognise as personally identifiable information, and email addresses are on its list. It also splits your own reporting: every address makes a unique URL, so one thank-you page shows up as hundreds of rows. Other tags that read the page URL, such as ad pixels and chat widgets, will usually have received the same address; the fourth diagnostic step shows which. GA4 settings do nothing about those.

What Data redaction does. It is a setting on the web data stream that strips matching text in the browser, before the hit is sent. Email redaction removes anything that looks like an address, best effort, from every event parameter. Query parameter redaction removes the parameter names you list. New properties have email redaction on by default; older properties have to switch it on. It cleans new data only, and only what goes to GA4.

Removing what is stored. A data deletion request replaces matching values with "(data deleted)" and leaves the event counted. It only reaches data more than 12 days old and takes up to 63 days. You cannot delete page_location on its own: Google only offers Delete all parameters on all events for it, so a text filter such as @ does the narrowing (fix step 5).

One thing looks like this fault and is not: an @ that is not a customer. A link_url of mailto:[email protected] is your own published address, and a path like /@yourbrand is a handle. The tell is whose address it is. A customer's email in a URL is F-603.

Page location (masked)	Route	Views	Status
/thank-you?email=[address]	newsletter form, GET	a few hundred	leaking
/account/reset?e=[address]	password reset email link	a few dozen	leaking
/search?q=[address]	typed into site search	a handful	leaking
Redact data: email	off, older property	n/a	never switched on

a newsletter form with no method. The browser chose GET.

How to catch it

1. (Anyone with report access) Start here. In Explore, build a free-form exploration with Page location as rows and Views as values, over the longest range your data retention allows. Filter Page location contains @, then run it again with %40 (the URL-encoded @) and with email=. Pages and screens drops the query string unless you switch its dimension to Page path + query string. If the table folds rows into (other), shorten the range. Any row with a customer's address is the fault. Note the paths: they tell you the route.
2. (Anyone with report access) Repeat the search on Page title, Search term, Link URL and every custom dimension. Then on Page referrer: an address there and never in Page location usually means one of your own pages carries it in its URL without sending GA4 a page view itself, such as an untagged confirmation page or a redirect hop.
3. (Anyone with report access) Find the route for each leaking path. A /thank-you or /confirm path points at a form or a redirect. Add Session source / medium: if every row comes from your email platform, the link is the source. A /search path is your site search box.
4. (Whoever owns the site) Reproduce it. Submit each suspect form with a test address and watch the address bar. If the address appears after submit, read the form's HTML for a method attribute; none means GET. Then open the browser's network tab, search all requests for the test address and its %40 form, and list every vendor that received it.
5. (GA4 Editor) Open Admin → Data collection and modification → Data streams → your website → Redact data. Check whether email redaction is on and which query parameters are listed. Paste one real leaking URL into Test data redaction and press Preview redacted data. If the address survives, the setting does not cover that route.
6. (Whoever owns GTM) In GTM Preview, submit a test form and read the dataLayer and every GA4 event parameter. Look for the typed address in form events, in user_id and in any custom parameter. A tag that sends it on purpose is a tag to rewrite, not one to redact.

What putting it right involves

1. (Whoever owns the site) Close the source. Give every form method="post". Stop redirects passing the address on: keep it in the server session, or pass a random token and look the address up. Ask whoever runs your email platform to identify subscribers by ID, not by address, in links. Take names and addresses out of page titles. Do this first: every later step only limits the damage. Four owners touch this fix (site, email platform, GTM, GA4), and leaks usually survive because nobody holds the whole list.
2. (GA4 Editor or above) Switch on Data redaction for the web stream: email redaction, plus the query parameter names your site actually uses (email, e, phone, name, whatever the diagnostic found). Test each leaking URL in Test data redaction before you save. Redaction is best effort, works on new data only, and does not cover Measurement Protocol or Data Import.
3. (Whoever owns GTM) Clean the URL for every tag, not just GA4. Strip the named parameters from page_location in a variable the Google tag reads, clean page_referrer the same way, and give other vendors' tags the same cleaned URL where they allow it. A server-side container can remove fields before they reach any vendor, but it is a second line, not the fix.
4. (Whoever owns GTM) Rewrite tags that send PII on purpose. Remove the address from dataLayer pushes and form events. Google says a user ID must not contain anything a third party could use to identify the person, so user_id is your own customer number, never an email. If you want email for matching, GA4's user-provided data collection hashes it (F-402). It is in open beta, needs the visitor's consent, and is not offered to Health-category properties.
5. (GA4 Editor or above) Delete what is stored: Admin → Data collection and modification → Data deletion requests. page_location is collected automatically, and Google only lets you delete those with Delete all parameters on all events. The text filter is what stops that wiping the property: it limits the deletion to values containing the text you give, such as @. Run a second request for %40 if the diagnostic found encoded addresses (a property can have 12 active at once). Use the 7-day preview to check that only the leaking values go: an @ filter also catches your own mailto: links and @handles in that range. Expect some campaign data in that range to go too, so later sessions may show as Direct; for a policy breach that is the right trade. Data from the last 12 days cannot be deleted yet: repeat once it is old enough.
6. (Whoever owns the tracking documentation) Record what leaked, where, for which dates, the deletion request and the date the source was fixed (F-501). Rerun the first diagnostic check after a week. Zero new rows closes the case.