Quick definition: Personally identifiable information (PII) is information that can identify, contact, or be reasonably linked to a particular person, alone or when combined with other information.
What is personally identifiable information (PII)?
Personally identifiable information, usually shortened to PII, is a practical data-governance label for information that identifies a person directly or makes them identifiable through a reasonable combination of records. Obvious examples include a full name paired with contact details, an email address, a phone number, a government-issued identifier, or an account identifier that a business can connect to an individual. Less obvious examples can include a persistent device identifier, precise location history, a distinctive behavioral sequence, or a combination of approximate location, timestamp, and purchase data.
The boundary is contextual. A city name alone may describe thousands of people; a city, uncommon job title, event time, and account activity may narrow the set dramatically. Whether information is identifiable also depends on who holds it, which other datasets they can reasonably access, and how identifiers can be joined. Treating PII as a fixed list is therefore unsafe for measurement design.
PII is not a synonym for every kind of sensitive information, every record in an analytics system, or the legal definition of personal data in every jurisdiction. Terminology and obligations vary. This article describes engineering, analytics, and experimentation considerations; it is not legal advice. Organizations should have qualified privacy, security, and legal reviewers determine the rules that apply to their processing.
Concept boundaries: PII, personal data, and pseudonymous data
PII emphasizes whether a person can be identified or linked. Personal data is a broader term used in many privacy frameworks and can include information relating to an identifiable person, including online identifiers and behavioral data. Pseudonymous data replaces a direct identifier with a token or key, but the data can still be linked back when a mapping or other information is available. Anonymous data should not permit reasonable reidentification; merely deleting a name does not achieve that result.
| Data example | Typical identifiability concern | Measurement implication |
|---|---|---|
| Email address | Directly identifies or contacts a person | Do not place in event properties or URLs |
| Internal account ID | Linkable if the account table exists | Limit access and preserve purpose controls |
| Hashed email | Often linkable or guessable, not automatically anonymous | Do not assume hashing removes governance needs |
| Aggregated daily conversion count | Lower risk when groups are sufficiently broad | Check small cells and joinability before release |
Hashing changes the representation of a value, not necessarily its identifiability. Common identifiers have small or predictable input spaces and can be compared across systems. Encryption protects confidentiality when implemented correctly, but the organization can still decrypt the data. Tokenization can reduce unnecessary exposure by separating a token from the lookup service, yet the token remains linkable where the lookup is available. These controls are useful, but they are not labels that turn personal information into non-personal information.
PII in product measurement and attribution
Analytics systems often collect more data than their dashboards visibly display. Event payloads, browser URLs, referral strings, debug logs, error traces, support exports, and warehouse tables can all contain identifiers. A sign-up event with an email field, a search event containing free text, or a page URL containing a reset token can spread PII into vendors and environments that were never intended to receive it.
Start with a tracking plan that identifies each event, property, data type, purpose, owner, destination, retention expectation, and whether an identifier is required. Prefer an internal account key or a short-lived analysis key over direct contact details when a link is genuinely needed. Block unexpected keys at collection time, redact known sensitive URL parameters, and avoid unrestricted “properties” objects. Validate schemas before production and sample payloads in a restricted environment rather than copying raw events into routine tickets or chat.
Attribution creates additional linkage pressure because it tries to connect touchpoints across sessions, devices, channels, and conversions. The useful question is not “What identifier can we collect?” but “What is the minimum information needed to answer this reporting question?” A campaign report may need aggregate source, medium, and conversion totals, not a complete person-level journey. Where individual paths are necessary for a controlled workflow, restrict access, separate identity maps from event facts, and make the join logic auditable. See data minimization and identity graphs for related design choices.
Experimentation implications
Experiments need stable assignment and outcome measurement, not unlimited identity data. A service can often assign an opaque randomization key at the account, device, or session level, store it separately from direct identifiers, and measure aggregate outcomes by variant. The correct unit depends on the intervention: account-level changes generally need account-level assignment, while a page-only experiment may use a session or device key with clearly stated limitations.
Direct identifiers can introduce both privacy and statistical problems. If treatment encourages account creation or login, outcome events may become easier to link to treatment users than to controls. A naïve dashboard may then show apparent lift caused by better identity coverage rather than changed behavior. Report assignment counts, exposure counts, outcome-linkage rates, and missingness by variant. Preserve the original assignment record even if later identity resolution merges accounts or devices.
Never create a favorable experiment segment from information generated after assignment. For example, analyzing only users whose emails were captured after a new form design is shown conditions on a treatment-affected event. Instead, define eligibility using pre-treatment information and analyze all assigned eligible units. The A/B testing and exposure logging guides explain why assignment and exposure records must be reliable before results are interpreted.
Scenario: newsletter experiment with an email field
A publisher tests two newsletter sign-up forms. Version A asks only for an email address; version B also asks for a first name and job role. The team wants to compare successful sign-ups and later newsletter engagement. An early implementation sends the form payload to a general web-event stream, where email addresses appear in event properties and session-replay metadata.
A safer measurement design assigns a random variant before the form is shown, logs a limited exposure event with a randomization key, and sends the submitted email through the dedicated account or messaging workflow. The analytics event records only a successful-submission flag, variant, page context, and controlled analysis key. A restricted join can later connect the key to permitted aggregate engagement outcomes. The experiment report explains the linkage rate and does not include raw email addresses or row-level personal details.
Version B might raise completion among a particular pre-defined account segment, but it also collects extra information. That trade-off is not resolved by the experiment’s conversion result alone. Product, privacy, and security owners should assess whether every field is necessary for the experience and stated purpose, and whether the incremental value justifies the additional data handling.
Common mistakes and caveats
- Using a narrow PII checklist. Combinations of ordinary fields, precise timing, and joinable identifiers can identify people.
- Assuming hashes are anonymous. Hashes of predictable identifiers can remain linkable and should be governed accordingly.
- Logging raw URLs and free text by default. Query strings, support messages, and form fields routinely carry unexpected personal information.
- Using production data in broad QA tools. Screenshots, CSV downloads, and debug logs can create untracked copies.
- Equating a consent flag with a security control. Choices, access control, retention, and destination restrictions solve different problems.
- Discarding identity coverage diagnostics. Unequal linkage by variant or channel can bias measurement and attribution.
A practical PII handling workflow
- Inventory flows. Map collection points, fields, transformations, warehouses, vendors, and human access paths.
- Classify by context. Record direct, linkable, sensitive, and aggregated fields along with plausible joins.
- Minimize collection. Remove fields that do not serve a defined product, measurement, security, or operational purpose.
- Use controlled identifiers. Separate direct identity maps from analytical events and limit who can join them.
- Validate continuously. Detect schema drift, sensitive patterns, unexpected URL parameters, and new destinations.
- Measure coverage. In experiments and attribution reports, disclose identity and outcome-linkage limitations.
FAQ
Is an IP address PII?
It can be personal or linkable information depending on context, available records, and applicable rules. Treat it as a governed identifier rather than assuming it is harmless telemetry.
Is a hashed email address anonymous?
No. Hashing may reduce plain-text exposure, but a hashed email can remain linkable to a person or matchable across datasets.
Can analytics contain PII?
It can, but collection should be intentional, minimal, controlled, and reviewed. Many routine analytics questions can be answered with pseudonymous keys or aggregates.
Does removing names make a dataset anonymous?
Not necessarily. Other attributes, rare combinations, and external data can make records reidentifiable.
How does PII affect A/B test results?
Identity collection and matching can differ across variants. Monitor assignment, exposure, linkage, and missing-data rates so identification changes are not mistaken for product effects.
Summary
PII is information that identifies, contacts, or can reasonably be linked to a person. Its boundary depends on context and available joins, so a fixed field list is not enough. For measurement, collect the minimum data needed, keep identity maps separate from event facts, control destinations, and monitor data quality. For experiments, use stable analysis keys and report differential linkage rather than treating more identifiable records as better evidence.
Sources
- NIST Privacy Framework
- NIST Privacy Engineering Program resources
- UK Information Commissioner’s Office guidance on anonymisation and pseudonymisation