tpTrackingplan answers
PII, personally identifiable information, is any data that identifies a person, either on its own or combined with other data. A full name, an email address, a phone number, a Social Security number, or a home address each identifies someone directly. A zip code, a date of birth, or a job title does not, until you put two or three of them together.
For an analytics team, PII is also the data that should never reach Google Analytics, an ad pixel, or a data warehouse without a reason and a legal basis. Most of the time it gets there by accident: an email in a URL, a name in a dataLayer push, a user ID that turns out to be a phone number. This page defines PII, lists the examples that matter, and shows where it hides in tracking and how to keep it out.
PII examples
PII splits into two kinds. Direct identifiers point to one person on their own. Linkable identifiers are harmless alone and identifying once combined.
| Direct identifiers | Linkable (indirect) identifiers |
|---|---|
| Full name | Date of birth |
| Email address | Zip code or city |
| Phone number | Gender |
| Home address | Race or ethnicity |
| Social Security number or national ID | Job title and employer |
| Passport or driver’s license number | Device ID or advertising ID |
| Credit card or bank account number | IP address |
| Biometric data (fingerprint, face scan) | Cookie or session ID |
| Login username with password | Browsing history |
| Photo of the person’s face | Approximate location |
The U.S. General Services Administration puts the rule well: the definition of PII is “not anchored to any single category of information or technology.” It requires “a case-by-case assessment of the specific risk that an individual can be identified” (GSA, Rules and Policies – Protecting PII). Context decides. A zip code in a public dataset is nothing; a zip code next to a birth date and a gender narrows the list to a handful of people.
Sensitive vs non-sensitive PII
Not every piece of PII carries the same risk, and regulations treat the two groups differently.
Sensitive PII can cause serious harm if exposed: fraud, identity theft, discrimination. It calls for the strictest protection, and laws such as GDPR and the US state privacy laws require consent, or at least a right to limit its use, before you process it.
- Government identifiers: Social Security number, passport number, driver’s license number
- Financial information: bank account numbers, credit card details
- Health and medical records: diagnoses, treatments, insurance information
- Biometric data: fingerprints, voiceprints, facial recognition data
- Precise geolocation, sexual orientation, religion, and other protected characteristics
The scale of the risk shows in breaches. In 2024, a background-check company’s dataset of about 2.7 billion records was leaked, including names, addresses, dates of birth, and an estimated 272 million unique Social Security numbers.
Non-sensitive PII is often public or harmless on its own. The danger is re-identification: pieced together, these fields can single out a person.
- Zip code or city
- Date of birth
- Gender
- Race or ethnicity
A privacy policy that only protects the sensitive group is incomplete. Your data handling has to account for what the non-sensitive fields reveal in combination.
PII vs personal data (GDPR) vs PHI (HIPAA)
The three terms overlap, but they come from different laws and cover different things.
| Term | Law | What it covers | Example |
|---|---|---|---|
| PII | US federal guidance and state laws | Data that identifies a person, directly or combined | Email address, SSN, name plus address |
| Personal data | GDPR (EU) | Any information relating to an identifiable person, including online identifiers and behavior | IP address, cookie ID, browsing history |
| PHI | HIPAA (US) | Health information held by a covered entity or its business associates that identifies a patient | A diagnosis tied to a name, an appointment record |
Personal data is the widest of the three. Everything that is PII is personal data; not everything that is personal data would be called PII in US usage. PHI is the narrowest: health data, and only in the hands of healthcare providers, insurers, and their partners.
Where PII hides in digital analytics
PII leaks in analytics are rarely the work of an attacker. They come from everyday setups: a form that puts the email in the URL, a developer who adds a helpful field to an event, an error logger that captures the whole payload.
Form submission URLs. A visitor signs up for a newsletter and the confirmation page carries their email in the query string. Every tag on that page sends it as the page location:
https://example.com/thank-you?email=john.doe@email.com
Custom event properties. A developer adds the user’s name to an event meant to track a feature:
event: 'feature_used',
properties: { user_name: 'Jane Smith', feature: 'profile_update' }
The dataLayer. A user_signup push that should carry an internal ID carries the email instead, and every tag that reads the object forwards it:
dataLayer.push({
'event': 'user_signup',
'user_id': '12345',
'email_address': 'sandra.dee@example.com' // accidental PII
});
Error logging. Detailed error messages sent to an analytics tool can include the data that caused the error, PII included.
In each case the fix is the same: remove the field, or replace it with an ID that means nothing outside your systems. The hard part is finding out it happened. See the guide to PII leak detection in analytics for the full picture of where leaks come from.
What happens if PII reaches Google Analytics or your ad pixels
Three things, usually in this order.
Vendor terms. Google’s policy prohibits sending Google Analytics data it could recognize as a personal identifier. A property found with PII can have its data deleted, which means losing the history, not just the offending rows.
Fines. Under GDPR, a violation can cost up to 4% of annual worldwide turnover. US state laws and the FTC have fined companies for sending personal data to ad platforms through pixels, from GoodRx and BetterHelp to the CCPA cases against Healthline and Disney. An email in a URL parameter is enough to start an investigation. See how to prevent privacy fines under CCPA and GDPR.
Trust and clean data. Customers leave when their data is mishandled, and PII in your analytics pollutes the datasets your decisions rest on. The cleanup, with forensic audits, legal fees, and notifications, costs more than prevention ever would.
How to detect and prevent PII leaks
- Keep a tracking plan. Define which events and properties you collect and which fields are off limits. When developers and marketers work from the same plan, accidental collection drops before it starts.
- Keep PII out of URLs. Submit forms with
POST, strip emails and tokens from confirmation and reset links, and turn on GA4’s data redaction for email addresses and query parameters. - Mask, hash, or tokenize anything that has to travel. Masking hides the value (
****1234); hashing turns it into a one-way, fixed-length string; tokenization swaps it for a stand-in that only your systems can resolve. Use the fields ad platforms built for hashed identifiers, not custom parameters. - Monitor on real traffic. Manual audits catch what existed on audit day. A release, a new pixel, or a CMP update can undo all of the above the next week.
Trackingplan does the fourth step automatically. It inspects every hit for PII leaks, Consent Mode misfires, and vendors firing without permission, across web, mobile, and server-side, and classifies what it finds by sensitivity. Private fields are masked on the device by default, so personal data never leaves the user’s browser on its way to Trackingplan. Findings land in your privacy channel with the hits, the vendor, the market, and the regulation involved, so the fix is a tag change, not an investigation. See how to secure PII with Trackingplan and the privacy and compliance page. Our own data practices are in the privacy policy.
FAQ
What are 5 examples of PII?
Full name, email address, phone number, Social Security number, and home address. Each one identifies a person on its own.
What is not considered PII?
Data that cannot be traced back to a person, even combined with other data: aggregated statistics, properly anonymized datasets, and business information such as a company name or a generic address like info@company.com. A single zip code or a date of birth is not PII on its own, but becomes PII once combined with other details.
Is an email address PII?
Yes. A personal email address identifies a person directly, and it is one of the most common pieces of PII that leaks into analytics, through URL parameters and form events.
Is a phone number PII?
Yes. US federal guidance and industry practice treat a phone number as information that can distinguish or trace a person’s identity, alone or combined with other data. The details, including hashing for ad platforms, are in is a phone number PII?.
Is an IP address PII?
Under GDPR, an IP address is personal data, because it can identify a device and, with help from the provider, its user. US definitions treat it as linkable PII, which is why Google Analytics 4 no longer stores IP addresses and why anonymization matters.
What is the difference between PII and personal data?
PII is the US term for data that identifies a person, directly or combined with other data. Personal data is the broader GDPR term: it covers PII plus any information relating to an identifiable person, including online identifiers and behavioral data.
Who is responsible for PII compliance?
Everyone who touches the data. A DPO or privacy lead owns the program, developers keep PII out of events and URLs, marketers check the tools they add, and leadership sets the rules. Monitoring makes the shared responsibility visible: when a leak appears, the finding names the field, the page, and the vendor, and the team that owns that tag fixes it.