Where location information becomes personal data
In the context of Bluetooth beacons, NFC tags, QR codes and indoor navigation, an inadequate consent mechanism is any method of obtaining permission that fails to meet the standard required by UK data protection law—specifically the UK GDPR and the Privacy and Electronic Communications Regulations (PECR). For proximity technology, this is a frequent point of failure because the gap between what a system can technically do and what a user has actually agreed to is often wide.
Consent must be freely given, specific, informed and unambiguous. In a physical space, this becomes complicated. A visitor entering a venue with a smartphone is not giving consent to be tracked simply by walking through the door. Likewise, installing a venue’s app does not automatically grant permission for background location tracking or proximity-triggered notifications. The mechanism used to ask, record and manage that permission must be robust enough to prove, if challenged, that the user understood exactly what they were agreeing to.
A common source of confusion is the difference between a technical device permission and legal consent. When an operating system asks a user to allow location services or Bluetooth for an app, this is a technical gate. It does not, on its own, satisfy the legal requirement to explain how the data will be used, who will process it, and for what specific purpose. Relying solely on the iOS or Android permission prompt is one of the most prevalent forms of inadequate consent in proximity deployments.
Controls for collection, use and disclosure
Retail proximity notifications
A retailer deploys beacons at shop entrances and specific product aisles to push offers to shoppers. If the app’s onboarding flow bundles the request for push notifications, background location and marketing communications into a single "Accept All" button, the consent is inadequate. The user has not been given a genuine choice to accept location tracking but decline marketing messages. Each distinct purpose requires a separate, granular action.
Museum and gallery dwell-time analytics
A museum uses beacons to understand how long visitors spend in different zones. If the museum’s app requests location access "to provide you with exhibit information" but the backend is actually using that same signal to build individual visitor journey profiles for operational analytics, the consent is misaligned with the purpose. The mechanism failed because the stated purpose did not match the actual processing activity.
Event venue QR and NFC check-in
At a conference, attendees scan a dynamic QR code or tap an NFC tag to collect their badge. If that single scan silently enrolls them in a day-long indoor navigation tracking programme without a clear, preceding prompt, the consent mechanism is inadequate. The physical act of scanning a code to retrieve a badge does not imply agreement to continuous location processing.
Temporary installations and pop-ups
Short-term events often rush consent mechanisms to reduce friction. A pop-up experience might display a poster stating "By entering this space, you consent to Bluetooth tracking." This is inadequate because it is not specific, it does not offer a way to refuse without missing the event entirely, and it fails to record individual consent. Freely given consent cannot be a condition of entry to a public or semi-public space.
Proving the controls work in practice
Common mistakes
- Pre-ticked boxes and default-on settings: Consent must require a positive opt-in action. A pre-ticked box for location-based offers is legally invalid under UK GDPR.
- Bundling purposes: Grouping "app functionality", "analytics" and "third-party advertising" into one consent toggle forces an all-or-nothing decision, which invalidates the consent for all purposes.
- Using dark patterns: Designing the interface so that rejecting tracking is deliberately difficult—such as hiding the decline button or using confusing wording—undermines the "freely given" requirement.
- No withdrawal path: If a user cannot easily find how to withdraw consent within the app or via a web portal without contacting customer support, the original mechanism is inadequate.
- Ignoring physical context: Failing to use clear physical signage to inform visitors that beacon technology is active in the space, which forms part of the "informed" requirement.
Limitations of consent models
Consent as a legal basis has inherent limitations in physical IoT environments. Operating systems restrict background access; for instance, iOS requires "Always Allow" location permissions for background beacon detection, which users rarely grant. This creates a tension where the technical capability of the deployment is heavily constrained by user trust. Furthermore, consent is fragile—it can be withdrawn at any time, meaning any system relying on it must be architected to gracefully handle a user opting out without breaking the core venue infrastructure.
Key checks for your deployment
- Separation of purposes: Can a user accept indoor wayfinding but decline proximity marketing, using separate toggles?
- Plain language: Does the consent prompt avoid legal jargon and clearly state what data is collected (e.g., "Bluetooth signal strength to estimate your position") and what is done with it?
- Timing: Is consent requested before any location processing begins, rather than after the first beacon ping has already been logged?
- Technical versus legal: Does your system treat the OS permission prompt as step one of a two-step process, rather than the final word on consent?
- Physical signage: Are there clear notices at entry points explaining that location-based technology is in use and directing visitors to the app’s privacy controls?
- Audit trail: Does your system log the timestamp, version of the privacy notice, and the specific granular choices the user made, so you can evidence valid consent if required?
Reviewing your consent mechanisms against these checks will not guarantee legal compliance—specific situations require specific legal guidance—but it will highlight the structural weaknesses that most commonly cause proximity deployments to fall short of UK expectations.
