/

/

AI

AI

/

/

Is there personal data hiding in your analytics?

Is there personal data hiding in your analytics?

AI

AI

Is there personal data hiding in your analytics?

Is there personal data hiding in your analytics?

Rhobin

Rhobin

July 31, 2026

July 31, 2026

7 min read

7 min read

Usually yes, in small amounts. Email addresses, names and customer references arrive through URLs, site search and event parameters without anyone sending them on purpose, which breaks Google's own terms and makes the dataset unsafe to hand to an AI tool.

Usually yes, in small amounts. Email addresses, names and customer references arrive through URLs, site search and event parameters without anyone sending them on purpose, which breaks Google's own terms and makes the dataset unsafe to hand to an AI tool.

The symptom

A client asks a question that sounds simple. Is there personal data in the analytics you set up for us? Nobody has touched that property in five months. It works, the numbers look reasonable, and now you must answer for something nobody ever checked.

Ten minutes in a page path report is usually enough. An email address inside a URL, because the password reset link carried it. A phone number in a site search term, typed by a visitor who treated the search box as a contact form. An order reference in a thank-you path that maps back to a named customer.

None of it was sent on purpose. There is no tag called "send the customer's email address to Google". The website put the value in the address bar, the tag forwarded what it found, and it has been landing there ever since.

Why it happens

Three things have to go wrong for personal data to sit in a property for months, and in most setups all three have. Which one you have decides what the fix costs.

The website hands it over and the tag forwards it

Analytics tags are built to be generic. A page view collects the page location, which means the path and the query string, whatever is in them. Google's own guidance on avoiding personally identifiable information is blunt about the consequence: this data "is often inadvertently sent in these URLs and titles", and "both the URL path and parameters must be free of PII".

The sources are boring, which is why they survive. Reset links that prefill an email. Form plugins that append submitted values to a redirect URL. Booking flows that put a name in the path. And visitors, who Google notes "sometimes enter PII into search boxes and form fields". A tag firing with an email in the URL is a tag doing what it was configured to do, which is why this lasts longest in setups built by campaign marketers between campaigns.

Google's rules are stricter than most agencies assume

Two documents decide this and both are Google's. The Analytics Terms of Service, section 7, says you will not pass information "hashed or otherwise" that Google could recognise as personally identifiable, except where a specific feature permits it. The PII guidance names email addresses, personal mobile numbers and social security numbers, extends the rule to user ID, custom dimensions, campaign, site search and event dimensions, and rules out any location finer than one square mile.

Two details catch agencies out. Hashing is not a general exemption: it is permitted where a feature is designed for it, the way enhanced conversions hashes first-party data with SHA-256 before sending. A hash you invent and park in a custom dimension does not carry that status. And this is a contractual rule about the Analytics account, so it holds regardless of the privacy notice or what the visitor consented to.

The safety net is narrower than it looks

GA4 has a redaction feature, on by default for email on new properties, so plenty of agencies assume this is handled. Read Google's data redaction documentation and the shape changes. Web data streams only. Email addresses "on a best-effort basis", plus the query parameters you name yourself, so a phone number or a customer reference is out of scope unless someone thought of it. And it does not prevent collection through Measurement Protocol or Data Import, which is how server-side and offline data reaches many properties.

Cleanup is the expensive half. A data-deletion request takes 7 to 63 days, reaches only data older than 12 days, and cannot be undone. Deletion inside Analytics also covers what is inside Analytics, so anything already copied to a warehouse or a client report is a separate job.

How serious it is depends on the client

Under the GDPR, personal data is any information relating to an identifiable person, "in particular by reference to an identifier such as a name, an identification number, location data, an online identifier", so a client ID in a cookie can qualify on its own. Pseudonymising does not move it out of scope either. Then it depends on the value and what the page reveals. An order reference on a webshop is a low-stakes cleanup. A URL path on a clinic's site naming the treatment being booked touches the special categories in Article 9, a stricter regime with a shorter list of legal grounds. Same mistake, different conversation, and the call belongs to the client's counsel rather than their agency.

Then somebody points an AI tool at it

This is what turned a slow-burning compliance item into an urgent one. The BigQuery export sends raw, event-level data, event parameters and user_id included. That is the right foundation for reporting that does not fall over. It also means a free-text parameter nobody reviewed now sits in a table a model, an MCP tool or an enthusiastic junior can query in plain language.

A model has no concept of a column it should not read out loud. Ask which customers converted twice and it answers with whatever identifier it finds, into a chat window, a screenshot, a client deck. It has no concept of purpose limitation either, while the GDPR does: data collected for specified purposes is not to be further processed in a way incompatible with them. Wrong AI answers at least get attention, and we took those apart in why AI gives wrong answers about your marketing data. A dataset that is unsafe to read out loud gets none.

What good looks like

Nobody can promise you a dataset with nothing personal in it. Detection is pattern matching, Google calls its own version best-effort, and a new form plugin can reopen the hole next month. What you can have is a setup where this is caught before it is stored. In this order.

  1. Find it before the client asks. Read the page paths, query parameters, site search terms and free-text event parameters for one real month. That is a report, not a project, and it tells you whether you have a cleanup or a redesign.

  2. Stop it at the source where you can. A URL that never carries an email beats a rule that strips it afterwards. That is a conversation with the client's developers, and the only step that removes the risk rather than managing it.

  3. Filter where you control the data, not only in the browser. A server container runs in your own cloud project, and in Google's words "only you have access to the data in the server until you choose to send it elsewhere". Browser-side redaction is the layer Measurement Protocol walks past.

  4. Separate raw events from the tables people query. The tables reporting and AI tools read are built from the raw data, sensitive fields dropped and columns documented, so what a model can reach is what it is allowed to reach.

That last step is what Archon AI is for: modelled BigQuery datasets for agencies, personal data stripped out and each column defined, so an AI tool answers from a table designed to be read rather than from raw events nobody reviewed. The detail is on the Archon AI page.

FAQ

Does GA4 not strip this out automatically?

Partly, and less than the feature name suggests. Data redaction covers web data streams, catches email addresses on a best-effort basis, and covers only the query parameters you name. Phone numbers and customer references are out of scope, and it does not apply to Measurement Protocol or Data Import.

Is hashing the email address enough?

Not on its own. The Analytics terms say "hashed or otherwise", so a hash sits under the same clause. Hashing is permitted only where a feature is built for it, such as enhanced conversions, which uses SHA-256 before sending. A hash your own setup invents does not carry that permission.

Can we not just delete it and move on?

You can request deletion, but plan around it. Analytics takes 7 to 63 days, reaches only data older than 12 days, and cannot reverse it afterwards. It does not remove numeric parameters, and it reaches custom parameters only where they were registered as custom dimensions.

Who is responsible, the agency or the client?

Legally it is the client's call with their own counsel, since they decide what is collected and why. Commercially it lands on whoever built the tracking, which is usually the agency: the client signs a privacy notice, and the agency configured the thing that quietly contradicts it.

If you would rather know than assume, this is one of the first things we check when we map a client's setup. Request a free tracking audit and we will tell you what is in there.

ArchonLabs

Marketing intelligence agencies run for their clients.

© 2026 Archon LabsPrivacyTermsBehind your agency, not in front of it.