PII examples: what counts as personal information in analytics
PII is information that identifies a person, on its own or when it's put together with other details. Some of it is obvious. A lot of it turns up in analytics by accident, in a URL, a form field or a user ID. Here are the examples, the grey areas, and how to keep it out.
This is general information, not legal advice. The rules differ by country and state, so check with a lawyer about your own situation.
TL;DR
- PII is information that identifies a person, on its own or when it's put together with other details.
- A lot of it turns up in analytics by accident, in a URL, a form field or a user ID.
- Keep it out of your analytics at the source.
In standard mode Stickybeak sets three first-party cookies on your own domain, for the visitor, the session and the session count, and shares nothing with anyone. It is in early access.
Get early accessDirect identifiers: PII on its own
These point at one person without any help. If one is in your analytics, treat it as PII.
- Full name
- Email address, including work addresses like
jess@theirshop.com - Phone number
- Home or postal address
- Government IDs: passport, driver licence, tax file number, social security number
- Payment card or bank account numbers
- Photos or video where a person can be recognised
- Biometric data, such as fingerprints or face scans
- Account usernames that are real names or contain them
Indirect identifiers: PII when combined
None of these names anyone alone, but a few together can single a person out. A postcode, a birth date and a gender are enough to identify many people.
- Date of birth or age
- Postcode or suburb
- Job title plus employer
- Gender, ethnicity or other personal characteristics
- Order numbers and customer numbers that your own systems can match to a person
- Precise location, such as a device's GPS position
The test is whether someone could reasonably work out who the person is, using the data you hold and anything it could be matched against.
Grey areas in web analytics
These are the ones people ask about, because they show up in analytics every day. Whether they count depends on the law and on how you use them. "Often" below means many privacy laws treat them as personal information, not that every law does. If you're wondering what an owner can actually see about a visitor, our guide on whether a website owner can see who visits covers it.
| Data | Treated as personal information? | What to do |
|---|---|---|
| IP address | Often. Personal data under the GDPR, and under several US state laws when it can be linked to a person or household. | Don't store it longer than you need. Don't join it to a name or email. |
| Cookie ID | Often. It's a persistent identifier for one browser. | Keep it random, with no name or email inside it. |
| Device or advertising ID | Often. It follows one device across sites and apps. | Only collect what you actually use. |
| User ID | Yes, if you can look it up and find a person. | Use an internal ID that means nothing outside your systems. |
| URL with an email or name in the query string | Yes. The email or name is the PII, and the URL carries it into logs and reports. | Keep both out of URLs. See below. |
| Browser, screen size, country | Not on its own, though it can help identify someone in a small group. | Stick to country or region, not exact location. |
| Page views and clicks with no identifier | Not by themselves. | Watch what you attach to them. |
"PII" is the common US term. The GDPR and similar laws use "personal data", which is broader. If you have visitors in Europe, assume the broader definition applies. Our guide on Google Analytics and the GDPR covers cookies, consent and what to keep out of your reports.
How PII gets into analytics by accident
Nobody sets out to log customers' emails. It usually happens in one of four ways.
- Query strings. A password reset link, an email campaign or a sign-up redirect adds
?email=jess@theirshop.comto a page. Analytics records the full URL, so it records the email. The same goes for?name=,?phone=and account numbers. - Forms that submit with GET. A form set to GET puts everything typed into it in the address. A contact or sign-up form should never use it. A search box can use GET for non-sensitive searches, but people type names, emails and other personal details into search boxes, so strip search terms from the address before they reach analytics, or don't collect them.
- Page titles and paths.
/account/jess-smithor a title like "Welcome back, Jess" carries a name into every report that lists pages. - User IDs and custom events. Event properties like
user_email, or an ID that is really an email address, put PII in by choice.
method="get"
theirshop.com/signup?name=Jess+Smith&email=jess%40theirshop.com
In the address, so in every report that lists pages.
method="post"
theirshop.com/signup
In the request body, out of the address and out of your analytics.
How to keep PII out of your analytics
- Keep personal details out of URLs. Use POST for forms. Put tokens or random IDs in links, not emails or names. If you must link with an email, use a one-time token that your server swaps for the person.
- Check your own links. Search your email templates, redirects and sign-in flows for
?email=,?name=and?phone=. This is the most common leak. - Strip it before it's sent. If a URL has to carry something personal, remove those parameters before your analytics script runs, or set your tool to ignore them.
- Use meaningless IDs. A random string that only your database can decode is far safer than an email or a sequential customer number. Hashing an email doesn't make it anonymous, because anyone can hash a guess and compare.
- Keep campaign tags about the channel.
utm_source=newsletterdescribes where a click came from, not who clicked. Never put a recipient's name or email in a UTM tag. Our free UTM builder encodes special characters, but the values are still up to you. - Collect less. If a detail in your reports doesn't change a decision, stop collecting it.
- Audit now and then. Scan your top pages and landing pages for anything with an at-sign or a long number in it.
email=jess@theirshop.comRemoved names a personutm_source=newsletterKept describes the channelutm_medium=emailKept describes the channelutm_campaign=spring-saleKept describes the channel
theirshop.com/welcome?utm_source=newsletter&utm_medium=email&utm_campaign=spring-sale
What this means for Stickybeak
Stickybeak is live analytics for every site you own, and it's in early access. Here is what we can say about how it handles visitors, and no more:
- It sets one first-party cookie for the visitor and one for the session, on your own domain. Nobody is counted twice, and nothing is shared with anyone.
- On a site hosted on Cloudflare, the script loads from your own domain. Sites hosted elsewhere can load it from Stickybeak instead, which works fine but is easier for blockers to spot.
- Bots are labelled and kept out of visitor counts.
- Each order keeps its trail: the entry page, the referrer, every UTM tag and the pages read before buying. That trail is only as clean as the URLs it reads from, which is why the habits above matter.
We aren't claiming that Stickybeak is cookieless, certified or compliant with any particular law. Whether your use of any analytics tool is lawful depends on where your visitors are and what you do with the data, so read the privacy rules that apply to you.
Questions
Is an IP address PII?
Often, yes. Under the GDPR an IP address can be personal data, and many US state laws treat it as personal information when it can be linked to a person or household. Whether it counts for you depends on the law that applies and on what else you hold alongside it. If you can avoid storing full IP addresses, do.
Is an email address in a URL PII?
Yes. An email address identifies a person directly, and once it is in a URL it can end up in server logs, browser history, referrer headers and your analytics. Keep email addresses out of query strings.
Is a user ID PII?
On its own it may look harmless, but if you can look it up in your own database and find a name or email, it is still personal data. Use an internal ID that means nothing outside your systems, and avoid putting it in URLs.
Is a cookie ID PII?
It can be. A cookie ID is a persistent identifier tied to one browser. Many privacy laws treat identifiers like that as personal data when they single out a person or device, even with no name attached.
What is the difference between PII and personal data?
PII is the term most used in the US. Personal data is the broader term used in the GDPR and similar laws, and it covers anything relating to an identifiable person. Plenty of things that are not PII in the narrow US sense are still personal data in Europe.