Identify people, identifiers and recipients
Location privacy in the context of proximity technology is fundamentally about what signals are emitted, what is received, and what happens to that data once it is stored. Unlike GPS tracking, which relies on satellite signals processed by a device, indoor location systems use Bluetooth Low Energy (BLE) beacons, NFC tags, and QR codes to infer position within a physical space.
The core privacy question is not whether a beacon knows who someone is—a standard beacon only broadcasts a identifier and cannot see or store anything—but what the receiving infrastructure does with the signals it detects. When a venue uses gateway scanners to detect mobile phones, or when a visitor uses a venue app that listens for beacons, data is generated. This data typically includes a device’s Bluetooth MAC address, the received signal strength indicator (RSSI), a timestamp, and the ID of the beacon or scanner.
Under UK data protection law, including the UK GDPR and the Privacy and Electronic Communications Regulations (PECR), this data can become personal data if it can be linked to an identifiable individual. Even if a MAC address is randomised, combining it with other data points—such as a loyalty app login or a Wi-Fi handshake—can cross that threshold. This guide addresses the practical questions operational managers and integrators face when balancing useful location analytics with legal and ethical obligations. For definitive legal requirements, venues should refer directly to current guidance from the Information Commissioner’s Office (ICO).
Minimisation, notice and access controls
Retail footfall and dwell time
A common use case is placing BLE scanners above shop entrances to count devices and measure how long visitors spend in specific aisles. The privacy consideration here is whether the system retains raw MAC addresses or immediately hashes or aggregates them. To minimise privacy risk, a system should convert the MAC address into a pseudonymised token at the point of collection, count the token, and then discard it. This allows the retailer to understand peak times and queue lengths without building a history of individual device movements.
Museums and exhibition spaces
Museums often use beacons to trigger audio guides or exhibit information via a dedicated app. In this scenario, the privacy burden shifts partly to the app developer. The museum’s operational team must ensure the app’s privacy policy clearly explains that Bluetooth will be used to determine the visitor's position within the building, what data is logged (such as which exhibits were visited), and how long that data is kept. If the museum uses web-based Bluetooth rather than a native app, the browser’s permission prompt acts as the consent mechanism, meaning the venue must ensure the prompt is accompanied by a clear explanation of why location access is needed.
Temporary event setups
At conferences or trade shows, organisers might deploy a temporary network of beacons for indoor navigation or to track attendance at specific sessions. The primary privacy challenge here is data retention. Because the event has a fixed lifespan, the location data collected has a strictly limited usefulness. Operational managers must configure the backend system to automatically purge location logs shortly after the event concludes. Keeping location data "just in case" it proves useful later directly conflicts with the principle of data minimisation.
NFC and QR code interactions
While beacons broadcast continuously, NFC and QR codes require a deliberate physical action from the user—tapping a tag or scanning a code. From a privacy standpoint, this explicit interaction is easier to frame as consent. However, the backend systems handling these scans still log IP addresses, timestamps, and device types. If a dynamic QR code is used to serve personalised content, the system must manage the resulting data trail with the same rigour applied to beacon-triggered interactions.
Proving the controls work in practice
Relying on static MAC addresses
One of the most persistent technical mistakes is assuming a device’s Bluetooth MAC address is a permanent identifier. Modern iOS and Android operating systems use randomised MAC addresses for BLE scanning to prevent long-term tracking. A system designed to track a single device across a shopping centre over several weeks using raw MAC addresses will fail technically while simultaneously raising unnecessary privacy concerns. Integrators should be questioned on how their software accounts for MAC randomisation.
Inadequate physical signage
Digital privacy policies buried inside an app are not sufficient for physical spaces. If a venue is scanning for devices, visitors must be informed before they enter the scanning zone. Generic "CCTV in operation" signs do not cover BLE or Wi-Fi scanning. Signage must specifically state that Bluetooth or wireless signals may be detected for analytics or navigation purposes, and it should provide a way to find out more, such as a short URL or a QR code linking to the full privacy notice.
Unnecessary data linkage
The most significant privacy risk in location technology occurs when anonymous location data is joined with a customer relationship management (CRM) database. If a loyalty app logs a beacon interaction and ties it to a named customer account, the venue has shifted from anonymous footfall counting to precise personal tracking. This is legally permissible only with explicit, informed consent, but operationally it is often done poorly, leading to scope creep where marketing teams assume they have broader rights to use the data than the consent actually covers.
Key checks for operational managers
- Data storage location: Where is the location data processed and stored? If a third-party integrator hosts the data outside the UK, adequate transfer mechanisms must be in place.
- Encryption standards: Is data encrypted both in transit (between the scanner and the server) and at rest?
- Retention controls: Can the system enforce automatic data deletion based on a defined schedule, and can you verify that deletion has occurred?
- Aggregation capabilities: Can the analytics dashboard function using only aggregated, anonymised data, removing the need for operators to access raw device logs?
- Scanner behaviour: Can gateway scanners be configured to count devices locally and only transmit aggregated totals, rather than sending individual MAC addresses to the cloud?
- Vendor access: Does the technology supplier have access to raw location data for their own debugging or product development purposes? If so, this must be explicitly addressed in the data processing agreement.
Location privacy is not a barrier to deploying proximity technology, but it requires a precise understanding of what the hardware actually records and what the software is configured to keep. Asking these specific technical questions during procurement prevents both compliance failures and the operational burden of managing data that was never necessary in the first place.
