Purpose, people and data flows
Proximity systems — Bluetooth beacons, NFC tags, QR codes and the indoor navigation platforms that tie them together — are built on signal data. That signal data, even when it looks like a string of random characters, frequently qualifies as personal data under UK GDPR. This is the point where many deployments start to drift into trouble: the technical team focuses on getting reliable RSSI readings and zone triggers, while the privacy implications of what happens to those readings are treated as an afterthought.
The most persistent misunderstanding is the assumption that because a beacon broadcasts a public identifier and the receiving device decides whether to respond, the system is inherently privacy-friendly. The broadcast itself may be passive, but once a smartphone app, a web browser or a venue-owned scanner logs that a device was near a particular beacon at a particular time, a record exists that can be linked back to an individual. The same applies to QR scans and NFC taps: the act of interacting creates a timestamped event that is rarely as anonymous as it first appears.
These mistakes matter for practical reasons beyond regulatory enforcement. Visitors who notice that their movements are being tracked without a clear explanation will disable Bluetooth, ignore QR codes or simply stop engaging with the venue's digital offerings. In retail environments, that means wasted hardware spend and campaigns that reach nobody. In museums and events, it means the accessibility and wayfinding features the organisation invested in go unused. Privacy mistakes do not just create legal exposure — they directly undermine the operational purpose of the deployment.
The mistakes outlined below are not theoretical. They recur across UK retail spaces, heritage sites, conference venues and temporary event setups. Recognising them early allows operational managers and integrators to adjust the system design before hardware is fixed to walls and labels are printed.
Controls for collection, use and disclosure
The privacy profile of a proximity deployment changes depending on what the technology is being asked to do. A system designed to count how many people pass through a zone has fundamentally different data requirements — and different privacy risks — from one that pushes a personalised offer to a specific shopper's phone.
Retail footfall and dwell time
When beacons are used to measure footfall patterns or queue lengths, the temptation is to log every detectable device with full granularity: exact timestamps, signal strength at multiple beacons, inferred path through the store. The operational need might only require an hourly count per zone, but the system is configured to collect far more. The mistake is not the technology — it is the failure to restrict data collection to what the use case actually requires. If the business question is "how many people stood near this display last Tuesday", the system does not need to store per-device identifiers to answer it.
Museum and gallery exhibit analytics
Museums commonly want to understand which exhibits hold attention and which are skipped. A beacon near each exhibit can detect how long a device lingers, but the resulting dataset becomes sensitive if it can be reconstructed into an individual visitor's complete route through the building. The practical safeguard is to aggregate early: process dwell times into exhibit-level averages within a short window and discard the raw per-device records. This preserves the analytical value while removing the ability to trace a single person's visit.
Event environments and temporary infrastructure
Events present a particular risk because deployments are often assembled rapidly, operated for a few days and then dismantled. In that rush, privacy notices may be generic, consent mechanisms may be bolted on at the last minute and — critically — there may be no clear plan for what happens to the collected data once the event is over. Temporary does not mean exempt from data protection obligations. If an event app collected proximity data across a three-day conference, that data needs a defined retention period and a deletion process, not an unmonitored database that persists on a contractor's server.
Queue detection and cross-referencing
A common error in venue and retail settings is to use proximity detection to measure queues and then quietly link that data to a ticketing or loyalty system. The queue measurement on its own may be unproblematic if handled as aggregated counts. The moment it is joined with a customer record to identify specific individuals who waited too long, the data processing has changed nature and requires a different level of transparency and, in most cases, explicit consent.
Consent models across interaction types
The privacy expectations differ significantly between interaction methods. An app-based beacon interaction can carry a detailed consent record because the user chose to install the application and grant permissions. A QR code scan opens a web page where consent can be presented before any further action. An NFC tap is more ambiguous — the user touched a tag, but did they understand that their interaction was being logged? And passive detection by venue-owned scanners, with no user action at all, sits in the most restricted category. Designing a deployment without accounting for these differences leads to inconsistent privacy practices across what visitors experience as a single service.
Proving the controls work in practice
Treating hashed device identifiers as anonymous
Hashing a MAC address or advertising identifier does not automatically make the data anonymous under UK GDPR. If the hashing is consistent — the same device always produces the same hash — and the hash can be correlated with other data points (a Wi-Fi login, a loyalty card lookup, a ticket scan), the result is pseudonymous, not anonymous. Pseudonymous data still falls within the scope of data protection law. The practical check is whether anyone with access to the dataset and one other system could re-identify an individual. If the answer is yes, the data is not anonymous.
Collecting at full granularity by default
Many beacon platforms log every advertising packet received, with timestamps accurate to the millisecond and RSSI values for every beacon in range. This is useful during calibration but unnecessary — and risky — for ongoing operations. The mistake is leaving the system in a debug-grade logging mode once the pilot is complete. Operational configurations should define the minimum data resolution needed for each use case and truncate or aggregate everything else.
No defined retention period
Data that is kept indefinitely because "it might be useful later" is a liability. UK GDPR requires that personal data is not kept longer than necessary. For proximity deployments, a practical approach is to define retention periods tied to the use case: aggregated footfall reports might be kept for a year for seasonal comparison, while raw interaction logs might be retained for 48 hours before aggregation and deletion. The key is that these periods are decided before the system goes live, not after a data subject access request arrives.
Inadequate notices at the point of interaction
A privacy policy buried in an app's settings menu does not satisfy the transparency requirement for a visitor who walks into a retail store and receives a push notification triggered by a beacon. The notice needs to be contextual: the visitor should be able to understand, at or before the point of interaction, what data is being collected, why and how to opt out. In physical spaces, this typically means clear signage at entrances and at the point where proximity interactions begin, written in plain language rather than legal boilerplate.
Assuming blanket consent from app installation
A user who downloads a venue's app and grants location permission has not consented to every possible proximity use case the organisation might later devise. If the original consent was for indoor navigation, using the same beacon infrastructure for targeted marketing or behavioural profiling requires a fresh consent prompt that describes the new purpose. Broad, catch-all consent wording does not hold up under scrutiny.
Combining datasets without reassessing privacy impact
A proximity dataset that is low-risk on its own can become high-risk when combined with another source. Joining beacon interaction logs with a CRM system, ticketing database or Wi-Fi captive portal records can enable individual profiling that neither dataset supported alone. Each time datasets are merged or cross-referenced, the privacy implications need to be reassessed — this is not a one-time exercise at deployment.
Ignoring platform-level privacy changes
Operating system vendors regularly change how Bluetooth scanning, advertising identifiers and background location access work. A deployment that was privacy-compliant when launched can become problematic if a platform update changes what data is available or how consent is managed. Operational teams need a process for monitoring these changes and adjusting their configuration accordingly, rather than assuming the initial setup remains valid indefinitely.
Practical limitations to accept
There are genuine limits to what a privacy-compliant proximity system can achieve. You cannot reliably track individual paths through a busy venue without processing that is difficult to justify under data minimisation principles. You cannot retain raw interaction logs indefinitely without a clear purpose. You cannot assume consent from passive detection. These are not design flaws — they are constraints that shape what is realistically buildable. Deployments that acknowledge these limits early tend to produce more robust, trustworthy systems than those that try to work around them.
Key checks before going live
- Can you describe, in one sentence per data type, why it is being collected?
- Is each data type retained only for as long as that purpose requires?
- Could any dataset be combined with another to re-identify individuals, and if so, is that processing covered by a valid legal basis?
- Is there a clear, visible notice at each physical point where proximity interactions occur?
- Does the system aggregate or truncate raw data within a defined short window?
- Is there a documented process for handling data subject access and deletion requests?
- Has someone outside the technical team — ideally someone who would represent a visitor's perspective — reviewed the privacy notices for clarity?
These checks do not replace a formal Data Protection Impact Assessment, which is covered separately. They are the operational hygiene that should happen during system design and configuration, before the deployment reaches the stage where a DPIA is formally required. Catching these issues at the point of hardware placement is considerably cheaper and less disruptive than retrofitting privacy controls after the system is already live and collecting data.
