Consent is one possible lawful basis for personal-data processing and is commonly relevant to optional proximity marketing. It must be freely given, specific, informed and unambiguous when relied upon. However, not every proximity interaction requires consent under the UK GDPR, and PECR or operating-system permissions may create separate requirements. The correct design begins by separating each purpose and communication channel.

A professional reviewing privacy-conscious analytics on a tablet
Illustrative example of aggregated analytics and privacy review.

A poster at a venue entrance stating "We use beacons" provides information but does not constitute valid consent. Similarly, a pre-ticked box buried within broader terms and conditions fails the unambiguous requirement. The user must take a clear affirmative action.

In practice, a valid consent mechanism for a beacon or NFC deployment should clearly state:

  • What data is collected (for example, a pseudonymised device identifier and signal strength).
  • Why it is being processed (for instance, to trigger a location-based notification about a specific exhibition).
  • Who is processing it (naming your organisation and any third-party platform providers).

The mechanism must be separate from general terms of service. If you change the purpose of the proximity system later—such as moving from wayfinding to retail analytics—you must seek fresh consent for the new purpose.

Opt-In vs Legitimate Interest for Location Data

PECR contains specific rules for electronic marketing. Prior consent is often required, but the exact position depends on the communication type, recipient and whether a limited exception such as the soft opt-in applies. Push notifications should be assessed against current ICO guidance rather than assumed to follow the same rule as every SMS, email or in-app message.

The question of legitimate interest arises more often in passive footfall analytics—counting how many devices pass a beacon without sending them a message. Some organisations attempt to rely on legitimate interest for pseudonymised MAC address or BLE signal tracking.

Using legitimate interests for passive analytics requires a documented purpose, necessity test and balancing assessment. Persistent observation of movement in a venue can conflict with reasonable expectations, particularly when stable identifiers create individual histories. Reduce the data first, make the activity visible and verify the analysis against current ICO guidance.

Do not choose consent simply because it appears safer. Consent must remain a genuine choice and can be withdrawn, so the project must still work appropriately when a visitor declines. For analytics, assess whether aggregate or non-identifying data can meet the purpose before considering individual-level tracking, then document the lawful-basis analysis against current ICO guidance.

When using a dedicated mobile application, consent operates on two distinct layers: the operating system level and the application level. Both must be satisfied.

Modern iOS and Android operating systems enforce strict permission prompts for Location Services and Bluetooth. If a user denies the OS prompt, your application cannot detect beacons, regardless of what your privacy policy says. These OS prompts serve as a technical gate, but they do not replace your GDPR obligation to explain why you want those permissions.

A common deployment mistake is triggering the OS Bluetooth or Location prompt the moment a user opens the app for the first time, before they understand the value exchange. If the user denies the prompt, they rarely navigate back to settings to reverse their decision.

A more effective mechanism delays the OS prompt until the user actively engages with a proximity feature. For example, when a user taps an "Enable in-store offers" button within the app, the app should first display a brief explanation of what data is collected, and then trigger the OS permission prompt. This contextual approach significantly increases opt-in rates.

Where consent is relied upon, it should be specific enough for visitors to choose between materially different purposes, such as navigation and promotional notifications. Do not bundle an optional marketing choice into access to a service that does not need it.

App-free experiences rely on QR codes, NFC tags, or Web Bluetooth to bypass app downloads. The consent dynamics here are different because the interaction is inherently transient.

Scanning a QR code or tapping an NFC tag shows an intention to open the immediate experience, but it does not authorise unrelated tracking, profiling or later marketing. Present the necessary privacy information at the appropriate point and establish a lawful basis for any personal data processing beyond delivering the requested page or function.

If a web page uses the Web Bluetooth API, the browser requires an explicit user gesture and permission to select a nearby BLE device. That technical permission is not a privacy notice and does not itself establish a lawful basis. Browser availability is limited, so this pattern should not be presented as a universal app-free beacon journey.

The practical limitation of app-free consent is session persistence. Web browsers handle consent via cookies or local storage. If a user clears their browser data, or if the browser automatically discards local storage after a short period, the consent record vanishes. For recurring visitors, you will likely need to re-request consent on subsequent visits, which introduces friction. App-free flows are best suited to single-session interactions—such as retrieving information about a specific exhibit—rather than continuous tracking.

UK GDPR requires that withdrawing consent must be as easy as giving it. If a user can opt in with a single tap, they must be able to opt out with a single tap.

For app-based systems, this typically means a prominent toggle within the app's settings menu. When a user disables proximity tracking, the application must immediately stop scanning for beacons and stop logging any associated data. A common technical failure occurs when an app continues to collect BLE signals in the background even after the user has toggled the setting off, relying on a delayed sync to update the backend. Your integration must halt the local collection instantly.

For app-free web interactions, the service should provide its own clear preference and deletion controls wherever personal data is processed. Browser permission and storage controls can be explained as an additional route, but an organisation should not make users clear all site data as the only practical way to withdraw a marketing choice or exercise a data-protection right.

Operationally, you need a mechanism to ensure that a withdrawal instruction propagates through your system. If your beacon management platform caches device profiles or if an analytics pipeline processes data with a delay, you must have logic in place to discard or ignore data from devices that have withdrawn consent, even if the signal was captured moments before the withdrawal command reached the server.

This article provides practical operational guidance on consent mechanisms for proximity technology. It does not constitute legal advice. For specific compliance questions regarding UK GDPR, PECR, or ICO enforcement actions, consult a qualified data protection solicitor and refer to the current guidance published by the Information Commissioner's Office.