Analytics identifiers can still be personal data

An analytics table may contain no names and still describe individual people. A persistent visitor identifier can connect a sequence of events. A login event can join that sequence to an account. A support export can add the missing link. The random-looking string is therefore only the beginning of the assessment.

Ask what the identifier can connect, how long it persists and who can combine it with other information. Those questions are more useful than asking whether the column is labelled personal data.

Apply the identifiability test

The DPDP definition in section 2(t) covers information about an individual identifiable by or in relation to that data. The definition has commenced. On 22 October 2026, the relevant substantive duties are scheduled for 13 May 2027 under the commencement notification.

An identifier does not need to contain a person’s name to contribute to identification. Consider the account mapping, device context, event history and information available to the intended recipient. A dataset that one team cannot immediately interpret may still be readily linkable by another authorised team or a provider.

NIST SP 800-188 supports assessing linkage and disclosure risk in the context of the sharing model. It is technical guidance rather than a DPDP definition, but it reinforces the need to examine relationships and combinations instead of only direct identifiers.

Trace the joining points

Find where an analytics ID is created, renewed and associated with an account. Check exports to customer systems, support tools and advertising services. An identifier that begins as a short-lived session reference can become persistent when another system stores a mapping.

Inspect the event payload too. A page title, search term, URL parameter or free-text field may contain identifying information even if the main identifier is well controlled. Avoid sending raw form contents merely because a general event-capture function can collect them.

Do not assume hashing removes the issue. If the value remains consistently linkable or can be matched against another dataset, the assessment must consider that capability. The technical transformation and the practical identification outcome are separate questions.

A hypothetical appointment-site review

A booking website wants to understand where users abandon a form. Its initial analytics design sends a persistent account identifier, the full page URL and the contents of failed fields. The team discovers that the business question needs only the form step, a bounded error category and a limited way to understand the session.

The team removes raw field contents and checks whether identifiers in URLs can be excluded. It evaluates how long a session reference needs to persist and whether the account link is necessary for the analysis. The resulting design is tested with synthetic entries so reviewers can see exactly what leaves the page.

The team does not automatically label the remaining data anonymous. It records the remaining identifiers, the available linkages and the access conditions. If people remain identifiable in the relevant context, the appropriate privacy treatment continues to apply.

Select the legal route for the actual purpose

Under the future sections 4 to 7, the analytics purpose will need an appropriate processing route. Do not assume that every analytics use is covered because it helps the business, or that the Act contains a general legitimate-interest balancing ground.

Equally, do not state that DPDP imposes a universal cookie-banner design identical to another jurisdiction’s rules. Identify the actual collection and use, assess the relevant framework and explain the purpose accurately. Other applicable requirements may need separate review.

Where the purpose changes from service measurement to individual profiling or promotion, revisit the assessment. The same event stream can support several activities with different implications.

Keep measurement useful without collecting everything

Choose the smallest set of events and fields that can answer the defined question. Document which values are allowed, which are excluded and who can change the schema. Review new event definitions before release instead of discovering sensitive payloads after a dashboard is built.

Limit access and retention according to the assessed purpose and applicable requirements. A restricted raw dataset and a suitably aggregated report can serve different audiences. Check that small groups or distinctive combinations do not reveal more than the report intends.

The recurring failure is treating an opaque identifier as proof that no person is involved. Follow the links and the event context. Then describe the dataset according to what it can reveal, and narrow the design where the business question does not require that exposure.