Map collection, inference and sharing
Under the UK GDPR and the Privacy and Electronic Communications Regulations (PECR), sending location-based notifications to a visitor’s device requires valid consent. For proximity technology—whether Bluetooth beacons, NFC tags, or QR codes—this consent must be freely given, specific, informed, and unambiguous.
A common operational misunderstanding is assuming that physical proximity equates to consent. A Bluetooth beacon broadcasting a signal into a retail aisle or museum gallery does not grant permission to send a push notification. Consent occurs at the software layer: when the user enables location services, accepts push notifications, or actively taps an NFC tag and proceeds through a clear permission screen.
The burden of proof lies with the organisation running the proximity system. You must be able to demonstrate that a specific individual consented to a specific action at a specific time. This means your system needs to log the timestamp, the version of the consent text shown, and the user’s identifier (such as an anonymised device token) without necessarily storing their name or email unless explicitly provided and required for the service.
This guidance relates to practical deployment and system design rather than legal advice. For definitive interpretations of UK GDPR and PECR obligations, organisations should refer directly to the Information Commissioner’s Office (ICO) documentation.
Consent, lawful basis and user choice
The mechanism for obtaining consent changes depending on the physical trigger and the software environment. Designing the consent flow requires close coordination between the operations team setting up the hardware and the developers building the app or web interface.
App-based beacon interactions
When using Bluetooth beacons, the consent process typically involves two distinct permissions on the user’s device: location access and push notifications. Requesting both simultaneously the moment a user opens the app is poor practice and leads to high rejection rates. Effective deployments separate these requests. Location access is requested when the user actively engages with a feature that requires it, such as viewing an indoor map or opting into a "nearby offers" programme. Push notification consent is requested only after the user has experienced value from the app, not on the first launch screen.
NFC and QR code triggers
NFC taps and QR scans offer a stronger implicit signal of intent because the visitor physically initiates the interaction. However, the landing page must still present a clear consent statement before any location data is processed or notifications are scheduled. If scanning a QR code at a museum exhibit simply loads a web page with text, explicit consent for marketing may not be required, but if that scan registers the device for ongoing location-based alerts throughout the venue, a distinct opt-in action is necessary.
Event environments and temporary infrastructure
At conferences or exhibitions, attendees often receive RFID or NFC-enabled wristbands. Tapping the wristband at a checkpoint can serve as a consent moment, provided the signage at the tap point clearly states what the tap will trigger—for example, "Tap here to receive session reminders and exhibitor offers to your event app." The physical act of tapping, combined with clear signage, forms the basis of the consent record, which the event platform must log.
Granularity and separation
Valid consent requires granularity. A single toggle labelled "Accept all" that bundles together indoor navigation analytics, personalised retail offers, and third-party advertising does not meet the standard of being specific. Users must be able to accept analytics to improve wayfinding while declining marketing notifications. Your deployment should separate these functions at both the user interface and the backend configuration level.
DPIA screening, monitoring and review
Deploying proximity hardware without aligning the software consent flows is a frequent source of compliance failure. The following points outline the most common pitfalls and the operational checks required to avoid them.
- Pre-ticked boxes and default-on settings: Under UK GDPR, consent cannot be pre-selected. If a venue app displays a checkbox for proximity marketing that is already ticked, that consent is invalid. All opt-ins must require an active, unambiguous action from the user, such as toggling a switch from off to on.
- Bundling consent with terms and conditions: Requiring a user to agree to proximity marketing as a condition of using a basic venue map or accessing free Wi-Fi invalidates the consent, as it is not freely given. The core service must function without the marketing consent.
- Ignoring the withdrawal mechanism: Consent must be as easy to withdraw as it is to give. If a visitor can opt in via a single tap, they must be able to opt out via a single tap within the app settings or venue profile. Operationally, this means your backend must immediately process suppression requests and stop triggering notifications when the updated consent status is received.
- Lack of version control on consent text: If you update your privacy notice or the wording of your proximity marketing prompt, you must record which version the user agreed to. Storing only a boolean "consent: true" without a timestamp and version identifier will not satisfy an ICO audit.
Operational limitations
The physical environment introduces limitations that pure web-based consent does not face. Signal interference can cause a beacon to trigger a notification outside its intended zone. If a user has consented to notifications in the "footwear department" but receives one in the "food hall" due to signal bleed, this undermines the specificity of their consent and can lead to complaints. Careful calibration and zone definition are necessary to ensure the physical trigger matches the consented context.
Additionally, Web Bluetooth—which allows websites to interact with beacons without a native app—has significant limitations on iOS devices and requires explicit browser prompts that can feel disjointed to the user. Relying on Web Bluetooth for consent-heavy marketing campaigns is operationally risky compared to a well-designed native app flow.
Key checks before going live
Before activating a proximity marketing campaign, walk through the entire user journey physically in the venue. Trigger the beacon or scan the tag, and verify that the exact consent text displayed matches the version stored in your audit log. Check that declining consent does not restrict access to non-marketing features. Finally, test the withdrawal flow by revoking consent on a test device and walking back through the same zone to confirm no notifications are delivered.
