Anonymisation and Pseudonymisation Are Not the Same
Anonymisation aims to reduce identifiability so that the information is no longer personal data in the relevant context. The assessment is risk-based: consider singling out, linkability and the means reasonably likely to be used by the organisation or another party, rather than relying on an absolute claim that re-identification is impossible.
For proximity systems—beacons, NFC readers, QR scan logs, indoor navigation platforms—this distinction matters because location data carries a high re-identification risk. A sequence of zone entries and exits, even without a name or email, can single out a person when combined with contextual factors such as arrival time, dwell duration, or a known work pattern. The Information Commissioner's Office has repeatedly warned that pseudonymised data remains personal data under UK GDPR and must still be handled according to the full data protection framework.
Anonymisation, when achieved, takes the data outside the scope of UK GDPR entirely. That is the reason it attracts so much interest from venue operators and retail technology teams: if you can genuinely anonymise footfall counts or dwell-time aggregates, you reduce compliance overhead and the risk profile of the system. The difficulty is that genuine anonymisation of location data is considerably harder than stripping a name field from a spreadsheet.
Why Location Data Resists Simple Anonymisation
Several characteristics of proximity-sourced data work against straightforward anonymisation. Spatial resolution matters: a count of visitors to an entire exhibition floor is far less identifying than a log showing which exhibits a single device approached, in what order, and for how long. Temporal granularity compounds the problem. A record at minute-level resolution over a two-hour visit creates a behavioural fingerprint that can be matched against staff rosters, ticketing data, or simply the observed habits of a small team.
Population size is another factor. A visitor count aggregated from a large city-centre department store over a busy Saturday is harder to attribute to any one person than a zone log from a private museum with forty daily visitors. The ICO's guidance on anonymisation stresses that the risk of re-identification must be assessed relative to the specific dataset and the reasonably likely means available to a motivated party—not against an abstract standard.
Location-specific Re-identification Risks
In practice, most proximity deployments use a mixture of pseudonymisation and aggregation rather than true anonymisation. Understanding where each technique fits helps you design a system that matches the actual analytical need without retaining more identifying information than necessary.
Pseudonymisation in Beacon and NFC Systems
When a smartphone receives a beacon broadcast and the associated app reports the device's presence to a backend, the typical approach is to hash the device identifier before it leaves the handset or at the point of ingestion. The hash replaces the raw advertising ID with a consistent but opaque string. This prevents staff or third-party processors from reading the identifier directly, and it limits the usefulness of any intercepted log.
However, the hashing key must be stored somewhere. If the same key is held alongside the pseudonymised records, the data remains re-linkable to the individual device and therefore remains personal data. Some architectures separate the key into a different legal or technical domain—for example, a distinct processing environment with restricted access—but this does not achieve anonymisation unless the key is destroyed or the linkage becomes practically impossible.
NFC tap logs present a slightly different shape. If a visitor taps an NFC tag with their own phone, the tag typically returns a URL and the phone's identifier may not be logged at all, depending on the implementation. If the venue provides NFC-enabled devices, the interaction log may be tied to a borrowed-device number rather than a personal identifier, which can simplify pseudonymisation but introduces separate questions about handover records.
Aggregation as a Path to Anonymisation
The most reliable route to anonymised location data is aggregation: collapsing individual-level records into group-level summaries before they leave a controlled processing environment. Common approaches include:
- Zone-level counts at fixed intervals. Rather than logging each device's arrival and departure, the system records only the number of distinct devices detected in a zone during a 15-minute or 60-minute window. If the count threshold is high enough and the interval coarse enough, re-identification becomes impractical.
- Dwell-time distributions. Instead of storing per-device dwell times, the system outputs a histogram—how many visitors spent zero to two minutes, two to five minutes, and so on. The shape of the distribution is useful for exhibit performance analysis without identifying anyone.
- Path aggregation. Rather than recording individual routes, the system counts how many visitors moved from Zone A to Zone B within a given period. This supports flow analysis and bottleneck detection at a population level.
If identifiable or pseudonymised raw logs remain available, the aggregate report does not make those underlying records anonymous. Assess the output and the retained source records separately, and restrict or delete the source data according to the documented purpose and retention plan.
When Pseudonymisation Is Sufficient
If a system sends a location-triggered notification to a known app user, the related records are likely to be personal data. Pseudonymising an identifier is a security and governance measure, not an automatic route outside UK GDPR. Select and document the lawful basis from the available bases according to the purpose and context, and analyse direct-marketing rules separately where relevant.
Pseudonymisation is also appropriate during a pilot phase when you need to validate detection accuracy, zone boundaries and signal behaviour before deciding on the final data architecture. During pilot, the priority is usually technical verification rather than production analytics, and strict access controls on the pseudonymised dataset may provide adequate protection for a limited period.
Testing and Governing the Result
Mistaking Pseudonymisation for Anonymisation
This remains the single most common error in location-data projects. A supplier describes its system as "anonymised" because it hashes device IDs, but the hashing key resides in the same database or is available to the same support team. Under UK GDPR, that data is pseudonymised personal data, not anonymised data. If you are relying on anonymisation to justify a reduced compliance burden or to share data without a data-processing agreement, this misunderstanding creates direct legal risk.
Underestimating the Mosaic Effect
Even individually innocuous datasets can become identifying when combined. A pseudonymised beacon log might not identify anyone on its own, but if it can be joined with a ticketing system, a Wi-Fi captive-portal log, or a staff access record, the combined picture may be highly identifying. When evaluating whether your data is genuinely anonymised, consider not just the dataset in front of you but the other data sources your organisation or its partners hold.
Ignoring Small-Population Scenarios
Aggregation thresholds that work in a busy retail environment may fail completely in a small venue or during off-peak hours. A zone count of "three devices between 10:00 and 10:15" is not meaningfully anonymised if only three people were scheduled to be in that area. Your anonymisation approach should account for minimum population thresholds and, where necessary, suppress or bucket small counts rather than publishing them.
Retaining Raw Data "Just in Case"
If identifiable or pseudonymised raw logs remain, those records are still within the data-protection assessment even when the published report is aggregate. The report itself may be anonymous if the identification risk is sufficiently remote, but that conclusion does not change the status of the retained source data.
Key Checks Before Relying on Anonymisation
- Can any individual in the dataset be re-identified using the data alone? If a motivated person with no special access could single out a visitor from the zone logs, the data is not anonymised.
- Can re-identification occur when the data is combined with other available sources? Consider publicly known schedules, visible footfall patterns, and any datasets held by partners or co-located tenants.
- Is the aggregation threshold appropriate for the venue's typical occupancy? A threshold that works at peak times may fail during quiet periods.
- Are the individual-level records deleted after aggregation? If they persist, you have not anonymised the data—you have only produced a summary from personal data.
- Has the pseudonymisation key been isolated or destroyed? If the key is accessible alongside the pseudonymised data, the data remains personal data under UK GDPR.
- Has the approach been documented? The ICO expects a reasoned anonymisation assessment, not an assumption. Record the methodology, the thresholds chosen, and the rationale for considering the output non-personal.
For most UK proximity deployments, the practical outcome is a layered approach: pseudonymise at the point of collection to limit exposure, aggregate as early as the analytical requirements allow, delete individual-level records on a defined schedule, and treat any dataset that could conceivably be re-linked to an individual as personal data unless a robust, documented assessment concludes otherwise. This is more work than accepting a supplier's claim of "anonymised data," but it aligns with the ICO's expectations and avoids the compliance gap that arises from confusing the two concepts.
