What is PII? Personally identifiable information, with examples

What is PII?

PII (personally identifiable information) is any information that can identify a specific person, either on its own or when combined with other information. A name, an email address or a passport number identifies someone directly. A ZIP code, a birth date and a gender do not, but put the three together and they often point to exactly one person.

The US National Institute of Standards and Technology (NIST) defines PII in two parts: information that can be used to distinguish or trace an individual's identity, and any other information that is linked or linkable to that individual. The second part is what most people miss. Whether a field is PII depends on what else you hold.

Direct vs indirect identifiers

Indirect identifiers are not a technicality. In a well-known study, Latanya Sweeney estimated that 87% of the US population could be uniquely identified by ZIP code, gender and date of birth alone. "We removed the names" does not make a dataset anonymous.

Sensitive vs non-sensitive PII

Sensitive PII is information whose exposure could cause real harm: identity theft, financial loss, discrimination or physical danger. Examples are government ID numbers, financial account numbers, health and genetic data, biometric data, precise location history and login credentials. It needs encryption at rest, tight access control and, in many jurisdictions, explicit consent.

Non-sensitive PII is easy to find or low-risk on its own, such as a business email address or a city. It is still PII and still subject to privacy law; the difference is the level of protection.

PII vs personal data vs personal information

Different laws use different terms, and the scope is not the same.

In practice, if you work with EU, Californian or Chinese users, treat the broader definitions as the standard. Cookie IDs, device IDs and IP addresses all count.

Where PII leaks into analytics data

Most analytics setups do not intend to collect PII. It arrives by accident:

• URLs. A sign-up form submitted with GET puts ?email=jane@example.com in the address bar, and every page view stores it.
• Page titles. Account pages titled "Orders for Jane Smith".
• Event properties. A developer sends user_email with a signup event "for debugging".
• Autocapture text. Capturing the visible text of clicked elements picks up names in greeting banners.
• User IDs. Using an email address as the login ID that you pass to analytics.
• Free text. Search queries, form fields and chat messages where people type phone numbers and order details.
• Network data. Full IP addresses and precise geolocation.

A worked example: auditing page URLs

Sample data: export one day of page URLs (1,000 rows) and search the query strings for an @ sign and for runs of 9 or more digits.

Fixing the form method and the partner links removes the problem at the source. Masking afterwards is a second line of defence, not the fix.

How to protect PII: a practical checklist

1. Do not collect what you do not need. This is data minimization, and it removes more risk than any later control.
2. Keep identifiers out of URLs and titles. Use POST for forms; use opaque IDs, not emails, in links.
3. Pseudonymize identifiers you need. Replace emails with an internal user ID. Remember that hashing an email is pseudonymization, not anonymization.
4. Truncate network data. Drop the last part of the IP address before storage; store country or city, not coordinates.
5. Classify every property. Mark each field as a direct identifier, indirect identifier or non-personal, and mask direct identifiers by default.
6. Limit retention. Delete raw events after a set period; see data retention policy.
7. Restrict and log access. Not every analyst needs to see raw emails.
8. Be able to answer requests. Access, deletion and portability requests must be findable by user ID.

How TapCub handles PII

• IP addresses are not written on events. The collector truncates the address (by default the last two IPv4 octets) before a city lookup, uses it for geography and the visitor hash, then discards it. See IP truncation and retention.
• Email- and phone-like strings are replaced with a placeholder when stripping is on, which is the default. Autocapture does not record visible element text by default, and email or phone passed at login stay out of the profile by default.
• Every property has a sensitivity. In All-platform analytics › Data › Property dictionary, each key is a direct identifier, indirect identifier or non-personal. Direct identifiers are masked by default in lists and exports, and member-level masking combines with it by taking the stricter level.
• Live chat masks numbers before storage if you turn on sensitive data masking: card numbers that pass a checksum and phone numbers keep only the last four digits.
• Data subject requests (access, erasure, restriction, portability) are handled in Configuration › Privacy center. See handling data subject requests and keeping personal data out of analytics.

Sources

• NIST, SP 800-122: Guide to Protecting the Confidentiality of PII (2010).
• GDPR Article 4: Definitions.
• California Civil Code §1798.140 (CCPA definitions).
• Sweeney, L. (2000). Simple Demographics Often Identify People Uniquely. Carnegie Mellon University, Data Privacy Working Paper 3.