When email addresses and phone numbers end up in your URLs

Symptom

Scroll the page path report far enough and rows like these turn up.

/password/reset?email=smith%40example.com
/order/lookup?phone=07700-900123
/signup/done?u=jane@example.com&ref=newsletter

The report treats them like any other row. No warning, no badge. One visitor's email address is simply sitting there next to your other page paths, visible to everyone with access to the property.

Why this is not something to file away

Google's policy is that no data should be passed to Google that Google could use or recognise as personally identifiable information, and it names email addresses and personal mobile numbers as examples. So this is a policy violation before it is a data quality problem.

Google's help pages do not spell out what happens if you violate it, so we are not going to frighten you with account deletion. What we will say is that in our checklist PR-04 is one of the four critical items: no matter how well the other 29 score, this one failing caps the grade at C. It is capped because it is the most expensive problem to undo. Revenue collected wrongly can be fixed from next month; personal data that has left the building has left.

Where the leak is

Almost always the structure leaks, not a person.

1. Forms submitted with GET. A search, lookup or login form with method="get" puts whatever was typed straight into the query string, and that URL goes out with the page_view. This is the most common one by a distance.
2. Links in transactional email. Password resets and signup confirmations arrive carrying ?email= alongside the token.
3. Guest order lookups. A page that takes an order number and a phone number in the URL sends the whole thing.
4. Redirects from third parties. Booking and survey tools hand the visitor back on a URL that has their contact details attached.

How to check in GA4

1) Search twice. Open the 'Page path and query string' dimension and search for @. Then search again for %40. An email that arrived URL-encoded has its @ written as %40, and it slips straight past the first search. In practice that is where most of the misses are.

2) Look for phone numbers. Search the same dimension for the local mobile prefix, and for parameter names like tel or phone to catch formats you did not predict.

3) Scan the parameter names, not the values. If paths carrying email=, mail=, phone=, mobile=, name= or uid= exist, then today those slots merely happened to be empty. They are still slots.

Stop collecting it

Three options, and the order matters.

① Do not send it from the site (the real fix). Switch the form to POST, replace identifiers in email links with single-use tokens, and stop lookup pages from leaving what was typed in the address. This is the only option that also protects every other collector: server logs, referrers, and whatever else reads the URL.

② Strip it in the tag. In GTM, change the variable so the query parameter is removed before the GA4 tag sends page_location. This is what you can do today while a site change takes a week.

③ Let GA4 remove it. A web data stream has a setting that removes email patterns and query parameters you name before collection (Admin → Data collection and modification → Data streams → select the web stream → Events → Redact data). Per Google's documentation it evaluates events before they are collected, so it does nothing for past data, and it exists for web data streams only — app streams and the Measurement Protocol are not covered.

Turning on ③ and postponing ① is the dangerous combination. The personal data is still travelling in your site's URLs; it has merely stopped being visible in one place.

What already arrived

Admin → Data collection and modification → Data deletion request. Google's documentation says the first 7 days are a grace period in which the request can be cancelled, that processing takes between 7 and 63 days depending on volume, and that only data more than 12 days old can be deleted. Today's rows cannot be deleted today.

So the order is always stop the collection first, then request the deletion. The other way round, the same data keeps accumulating while the deletion is processed.

And what about the scanner

If you have read this far, it is the obvious question to ask us. AnalyticScan's PR-04 check reads up to 5,000 page-path-and-query-string rows from GA4 and counts how many of them match an email or phone pattern. The matched values — the actual addresses and numbers — are never stored, and never appear in the diagnosis. What remains is a count: "email pattern found in 47 of 5,000 rows".

One limitation, stated plainly: our phone pattern is built for Korean numbers (010, +82), so numbers in other formats will not be caught by it. Even with a count of zero, the three manual checks above are worth doing once.

In one line

A URL is a field you design, not a field your visitors fill in. Search for both @ and %40, and if either returns something, fixing the site so it stops sending is the first move. Removing it in GA4 comes second, and deleting what already arrived takes weeks.