What Location Data Is Collected by Proximity Systems

The data generated by beacons, NFC tags and QR codes varies considerably between technologies, and understanding that variation is the first step toward handling it properly.

UK update: the Data (Use and Access) Act 2025 amended parts of the data-protection and PECR framework. The ICO states that all provisions affecting these areas are now in force; current ICO guidance should therefore be checked when a project moves from planning to implementation.

Bluetooth beacons broadcast small packets containing identifiers such as a UUID, major and minor values, and a measured transmit power value. When a smartphone receives these packets, the receiving app or browser can log the beacon identifier, the received signal strength indicator (RSSI), and a timestamp. If the system is designed for indoor navigation, it may also record the sequence of beacons detected, which allows the backend to approximate a path through the space. In some configurations, the device's Bluetooth MAC address is also visible, though modern operating systems rotate these addresses periodically.

NFC interactions produce a narrower data set. A tap typically records the tag's identifier, the time of the tap, and the content served — usually a URL. No signal strength or path data is involved because the interaction requires physical contact.

QR scans generate similar records: the code identifier or destination URL, a timestamp, and sometimes the device type or browser. If the QR code resolves through a redirect service, that intermediary may log additional data such as approximate location derived from IP address, though this sits outside the proximity hardware itself.

A beacon identifier normally identifies the installed transmitter, not the visitor. A receiver event may still become personal data when it is linked to an account, device-level identifier or repeated journey that can identify or single out a person. Avoid declaring data anonymous only because it does not contain a name; assess linkability, persistence and access to additional information.

UK GDPR and Location Data

Under the UK GDPR, location data is not a special category in itself, but it frequently becomes personal data, and the way it is collected can engage other obligations. The Information Commissioner's Office (ICO) treats persistent device identifiers used for tracking as personal data when there is a reasonable likelihood that the data subject can be identified.

There is no single lawful basis for every proximity project. Promotional communications, app permissions, analytics and operational navigation may require different assessments, and PECR can apply alongside the UK GDPR. Consent is often appropriate for optional marketing, but it should not be selected automatically or stretched to cover unrelated processing. Record the purpose, necessity and user expectations for each data flow.

Legitimate interests may be considered for some analytics, but it requires a documented purpose, necessity and balancing assessment. Invisible or persistent tracking in a public space creates a higher risk to reasonable expectations. Aggregation, short retention, clear notices and avoidance of stable identifiers can materially change the analysis, but they do not replace it.

Data minimisation, a core principle of UK GDPR, is particularly relevant here. If your objective is to count how many people enter a zone each hour, you do not need to store individual device identifiers for days or weeks. Aggregating or anonymising data at the earliest possible point reduces risk and narrows the scope of your compliance obligations. The practical question to ask at each stage of the data flow is whether the level of detail you are retaining is genuinely necessary for the stated purpose.

Data Protection Impact Assessments for Proximity

A Data Protection Impact Assessment is required where the proposed processing is likely to create a high risk to people. Large-scale systematic monitoring of a publicly accessible area is one recognised trigger, but not every small beacon or QR deployment automatically meets that test. Screen the project against current ICO criteria, record the decision and complete a DPIA before launch where the threshold is met or material uncertainty remains.

A DPIA for a proximity system should work through the following elements:

  • Description of the processing: What data is collected, from which sources, by which hardware, and transmitted to which backend systems.
  • Purpose and lawful basis: A clear statement of why the data is needed and which lawful basis applies, supported by documentation such as a legitimate interests assessment where relevant.
  • Necessity and proportionality: Whether the same objective could be achieved with less intrusive means — for example, using aggregate counts rather than individual device tracking.
  • Risk identification: What could go wrong. This includes re-identification of anonymised data, unauthorised access to location histories, function creep where data collected for analytics is later used for marketing, and the risk of profiling visitors without their knowledge.
  • Mitigation measures: Technical controls such as encryption in transit, data minimisation at the point of collection, short retention periods, and access controls on the backend. Organisational controls such as staff training and clear policies on data use.

A common gap in proximity DPIAs is treating the hardware and the software as separate concerns. The assessment should cover the full data flow from beacon or tag, through the mobile device, to the app or browser, to the backend platform, and on to any third-party analytics or CRM systems. If data crosses organisational boundaries — for instance, if an integrator manages the beacon infrastructure but the venue manages the content platform — the DPIA should clarify who is the data controller for each processing activity.

Transparency and Privacy Notices

Being transparent about location data collection is both a legal requirement and a practical necessity. Visitors who encounter beacons or scan QR codes need to understand what is happening, and vague statements about "improving your experience" do not meet the standard.

A privacy notice for a proximity system should specify: what data is collected, the legal basis for processing, how long it is retained, who it may be shared with, and what the individual's rights are. For beacon-based systems, it should also explain what the beacons do, that the visitor's device must have Bluetooth enabled, and what happens if they disable it.

Physical signage at the entrance to a venue or zone is the most direct way to provide this information. The signage needs to be specific enough to be meaningful — stating that "beacons are in use" is less useful than explaining that "Bluetooth beacons in this area may detect your device to provide location-based information about exhibits." The notice should also direct visitors to the full privacy notice, whether via a URL, a QR code on the sign itself, or a printed leaflet.

For app-based proximity interactions, the privacy notice should be presented at the point where location permissions or Bluetooth permissions are requested, not buried in a general terms page. The timing matters because that is the moment the user is making a decision. If the app requests Bluetooth access but does not explain that this will be used for beacon-triggered notifications, the consent is unlikely to be informed.

Dynamic QR codes and NFC tags introduce a slightly different transparency question. When a visitor taps an NFC tag or scans a QR code, they are actively initiating an interaction, which provides a natural opportunity to present privacy information on the landing page. However, if the same tag or code is used to log the visitor's presence for analytics, that secondary purpose should be disclosed at or before the point of interaction.

Individual Rights: Access, Deletion and Objection

Once location data qualifies as personal data, individuals have the full set of UK GDPR rights. In practice, three rights arise most frequently in proximity deployments.

The right of access, exercised through a subject access request (SAR), entitles an individual to a copy of their personal data and information about how it has been processed. For a beacon system, this could include the log of beacon detections associated with their device, the timestamps, and any inferences drawn — such as zone visits or path data. If your system aggregates data quickly and does not retain individual-level records, the response may be that no personal data is held, but you must be able to demonstrate that this is genuinely the case rather than simply claiming it.

The right to erasure depends on the circumstances and lawful basis. When it applies, the organisation needs a process for live systems and for preventing erased data from being reintroduced during backup restoration. Properly anonymised aggregate figures are no longer personal data, but calling a dataset aggregate does not establish anonymisation by itself.

The right to object is particularly relevant where legitimate interests is the lawful basis. If a visitor objects to their device being detected for analytics purposes, you must cease that processing unless you can demonstrate compelling legitimate grounds that override the individual's interests. For most venue analytics use cases, continuing to track an objecting individual would be difficult to justify. Where consent is the lawful basis, the equivalent right is the right to withdraw consent, which must be as easy to exercise as it was to give. In a beacon system, this typically means providing a clear mechanism within the app to disable location or Bluetooth-based features, and ensuring that the backend stops processing that device's data promptly.

Operationally, the key question is whether your systems can actually fulfil these rights within the one-month timeframe the ICO expects. If your beacon platform logs raw device identifiers but your team has no straightforward way to search for a specific individual's data, that is a problem that should be identified during the DPIA and resolved before the system goes live. Building the capability to locate, review and delete an individual's data is not an afterthought — it is a design requirement.