Privacy
No personal data is being recorded in your page addresses
analytics.pii-in-paths
Why this matters
Analytics records the address of every page somebody views, and if an address contains an email address, a token or something typed into a form, that goes into Analytics too — and into anything connected to it. Google's terms prohibit sending personal data to Analytics, so this is a policy problem as well as a privacy one, and it is almost always accidental: a form that submits by GET, or a reset link that keeps its token when the page is measured.
Who fixes it
A developer
Roughly how long
half a day
Care needed
Test before and after
How to fix it
Find them first: in Analytics, open Reports, then Engagement, then Pages and screens, and filter the page path for '@' or for the parameter named in this finding. The usual cause is a form that submits with GET rather than POST, which puts everything somebody typed into the address bar — changing the form's method fixes it at source and is a one-line change. Where the address genuinely has to carry a token, exclude the parameter in Analytics under Admin, Data streams, Configure tag settings, and use 'Redact data' for email addresses. Do the redaction as well as the fix, not instead of it: redaction stops the next one being recorded and does nothing about what is already there, which needs Google's data deletion request.
How we score it
Failing this check takes up to 22 points off your privacy score. It is a fact about your site rather than a measurement, so it reads the same on every scan until you change something.
Does your site pass this one?
This check runs on every scan, along with the other 121. Free, no account, and you see the evidence for each result.
Check my siteOther privacy checks
- Cookies the site sets are explained somewhere on itAnyone whose site stores cookies has to tell visitors what is stored, who by and how long it lasts, in language an ordinary person can follow. It is a standing obligation rather than a one-off, and it applies to cookies that needed permission and to the ones that did not. A site with tracking on it and nothing anywhere explaining that tracking is the clearest version of getting this wrong, and it is also the easiest to put right.
- Every company your site shares visitors with is one you know aboutA cookie stored against another company's domain means that company saw the visit — the address of the page, the browser, the address it came from — and can recognise the same person on any other site it is embedded in. Under UK data protection law the site owner is responsible for that sharing and has to tell people it happens, whether or not the cookie itself needed consent. Most owners are unaware of half the list, because the companies arrive attached to a plugin or an embedded video rather than by decision.
- Nothing is stored on a visitor's device before they agree to itUK law treats putting anything on a visitor's device — a cookie, or a record kept in the browser's own storage — as something that needs permission first, unless it is genuinely required to deliver what the visitor asked for. Analytics does not count as required, however anonymous it is, and the Information Commissioner's Office has said so repeatedly. This is one of the few things a website audit finds where the risk is a regulator rather than a lost sale.
- Tracking cookies do not outstay the consent behind themA tracking cookie carries the permission it was set under, and permission does not last forever. Regulators across Europe have converged on around thirteen months as the point at which a site should ask again, on the reasoning that somebody who agreed to be measured last year has not agreed to be measured indefinitely. Several popular analytics tools still default to a two-year lifetime, so this is usually a setting nobody chose rather than a decision. Browsers now cap what they will store at a little over a year regardless, which hides the difference between a long setting and an absurd one.