Map the information before choosing a rule
Do Bluetooth beacons collect personal data by themselves?
No. A beacon is a one-way transmitter that broadcasts a small packet containing identifiers such as a UUID, major and minor values. It does not receive data, store data or connect to phones. Personal data only enters the picture when a smartphone app or web service receives that broadcast, links it to a device or user profile, and logs the interaction. The privacy risk sits in the software layer and the backend analytics, not in the beacon hardware.
What counts as personal data in a proximity system?
Under UK GDPR, any information relating to an identified or identifiable individual is personal data. In a proximity deployment, that includes a device identifier linked to a known customer account, a phone's advertising ID combined with behavioural profiles, or a MAC address where the individual can be identified. Aggregated counts such as "forty devices entered zone three between 10:00 and 11:00" are not personal data provided no individual can be singled out from the dataset.
Do I need consent to send beacon-triggered notifications?
Yes, in nearly all commercial cases. If your app pushes a notification because it detected a beacon, that processing relies on the user's device identifier and location, which UK GDPR treats as personal data. You need a lawful basis, and consent is the most straightforward one for marketing notifications. The consent must be freely given, specific, informed and unambiguous, and as easy to withdraw as to give. Relying on legitimate interest for unsolicited proximity marketing is extremely difficult to justify.
What about QR codes and NFC tags — do those need consent?
The physical scan itself is a deliberate user action, which changes the consent picture. If a visitor scans a QR code or taps an NFC tag and lands on a webpage, the privacy obligations shift to what that page does. If the page simply shows exhibit text, no consent for tracking is needed beyond standard cookie compliance. If the page logs the scan time, device identifier or links to a customer profile, you need a lawful basis for that processing and a clear privacy notice at the point of interaction.
Do I need a Data Protection Impact Assessment?
A DPIA is mandatory under UK GDPR when processing is likely to result in a high risk to individuals' rights and freedoms. The ICO's guidance lists systematic monitoring of publicly accessible areas as a factor that triggers a DPIA. If your proximity system tracks individual device paths through a retail floor, museum or event venue, a DPIA is strongly advisable and in most cases required. Even if you only collect aggregated zone counts, documenting a brief assessment is good practice and helps if the ICO ever asks questions.
How long can I keep location analytics data?
There is no single fixed period in UK GDPR, but the principle of storage limitation requires you to keep data no longer than necessary for the purpose you collected it. For proximity analytics, that purpose is typically understanding footfall patterns, dwell times and zone popularity. If your operational decisions are based on weekly or monthly reports, retaining raw device-level logs for years is hard to justify. Many organisations set retention periods measured in weeks or a few months for granular data, with only aggregated, anonymised summaries kept longer. Document your rationale and stick to it.
Can I track an individual visitor's path through a venue?
Technically yes, if your system logs each beacon detection against a persistent device identifier. Legally, this is high-risk processing. You need a clear lawful basis, a transparent privacy notice explaining exactly what you are doing, and usually explicit consent. You should also consider whether path-level tracking is proportionate to your actual objective. If the goal is to find popular exhibits or congestion points, aggregated zone-entry counts often deliver the insight without the privacy exposure.
What should a privacy notice for a proximity system actually say?
Vague statements about "improving your experience" are insufficient. The notice should explain that the system detects Bluetooth signals from phones, what identifiers are collected, whether data is linked to a customer account, what the data is used for, how long it is kept, and the user's rights including the right to withdraw consent and request deletion. For app-based deployments, the notice belongs in the app's privacy policy and ideally at the point where location or notification permissions are requested. For web-based interactions triggered by QR or NFC, the notice should be on the landing page itself.
Who is the data controller — the venue or the technology supplier?
It depends on who determines the purposes and means of processing. In most proximity deployments, the venue decides why data is collected, what zones to monitor and how the analytics will be used. That makes the venue the data controller. The technology supplier providing the beacon management platform, the app or the analytics dashboard is typically a data processor. However, if the supplier runs its own audience network, sells aggregated insights to third parties or makes independent decisions about data use, the line blurs and you may have joint controllership. Your contract should state the roles explicitly.
Can I use anonymised data without consent?
Genuinely anonymised data falls outside the scope of UK GDPR. The challenge is that anonymisation is harder than it looks. A dataset of timestamped zone entries linked to randomised device IDs can sometimes be re-identified through pattern analysis, especially in small venues with few visitors. The ICO expects you to assess re-identification risk seriously. Pseudonymisation — replacing identifiers with tokens — does not count as anonymisation and the data remains personal data subject to UK GDPR.
What happens if a visitor asks for their data to be deleted?
You must comply with an erasure request unless an exemption applies. In a proximity system, that means finding all records linked to that individual's device identifier or account, deleting them from live systems and backups within the statutory timeframe, and confirming deletion to the requester. If you have already aggregated their data into anonymised summaries, those summaries do not need to be deleted because they no longer relate to an identifiable individual. The practical difficulty is matching a deletion request from "John Smith" to a database record held against an advertising ID — your privacy notice should explain how individuals can identify their data.
Does the system work if someone disables Bluetooth or location services?
Beacon detection requires Bluetooth to be active on the phone. If a user turns Bluetooth off, your app cannot receive beacon broadcasts and no proximity interaction occurs. On iOS, location services must also be permitted for the app to use Bluetooth in the background. On Android, background scanning behaviour varies by version and manufacturer. From a privacy perspective, this means a meaningful share of visitors will simply not be detectable, which affects the representativeness of your analytics. It also means that opt-out by disabling Bluetooth is an effective, if blunt, privacy control available to every user.
What should I ask a proximity supplier about privacy?
Useful questions to put to any vendor before procurement include: where is the data processed and stored; whether the supplier accesses raw device-level data for its own purposes; whether data is shared with third-party advertising networks; what encryption is applied in transit and at rest; how deletion requests are handled technically; whether the supplier sub-processes to other parties; and whether they provide a data processing agreement that meets UK GDPR requirements. If a supplier is reluctant to answer these questions directly, that is a meaningful signal.
Are there special considerations for children?
Yes. If your venue or event is likely to attract children under 13 and your system could collect their data, you need a lawful basis and, for consent-based processing, parental consent. In practice, a beacon system detecting a phone does not know the age of the person holding it, which makes targeted consent difficult. Many organisations address this by ensuring their proximity interactions are not age-sensitive — for example, sending the same exhibit information regardless of who is carrying the phone — and by avoiding behavioural profiling or targeted advertising that would heighten the risk.
Does using aggregated analytics remove the need for a privacy notice?
If the data is genuinely anonymised before it reaches your analytics dashboard, UK GDPR does not apply and no privacy notice is required for that data. But if your system collects identifiable data first and aggregates it later, the collection stage is still covered by UK GDPR and a notice is required at the point of collection. The practical question is where aggregation happens. If it happens on-device before any data leaves the phone, the privacy position is stronger. If raw identifiers reach your server before aggregation, you are processing personal data regardless of what you do with it next.
