What information the service actually handles
App-free proximity experiences rely on technologies that work without requiring the visitor to install anything beforehand: QR codes scanned with a native camera, NFC tags tapped against a phone, Eddystone URL beacons that surface a link via the operating system's nearby-notifications layer, and Web Bluetooth interactions initiated through a browser. The appeal is clear—lower friction, no download barrier, and broader reach. But removing the app does not remove the obligation to handle personal data lawfully under UK GDPR and the Privacy and Electronic Communications Regulations (PECR).
The core difficulty is that an app typically provides a persistent channel for consent: a first-launch prompt, a settings screen, and a record of the user's preference stored on the device. Without an app, you have no built-in mechanism to capture, store or recall consent across visits. Each interaction may effectively start from zero, which creates practical problems for both compliance and user experience.
It is a common misunderstanding that the physical act of scanning a QR code or tapping an NFC tag somehow constitutes consent to all downstream data processing. Under UK GDPR, consent must be freely given, specific, informed and unambiguous. Scanning a code to read a menu or an exhibit label demonstrates intent to access that content, but it does not, on its own, signal agreement to have the device's location logged, to receive subsequent marketing messages, or to have an identifier added to an analytics profile. The purpose for which data is collected must be stated clearly at or before the point of collection, and the user must have a genuine choice.
The landing page that loads after a scan or tap becomes your primary consent interface. What happens on that page—what information is presented, what choices are offered, and what happens if the visitor declines—determines whether your consent mechanism holds up. This is where many deployments fall short: the page serves content but says nothing about data use, or it bundles content access with analytics consent in a way that is not freely given.
Build privacy into the service workflow
QR codes in retail and hospitality
When a customer scans a QR code to view a product information page, the data processing is often minimal: the server logs a page request, which may include an IP address and a user-agent string. If that is all you do, the legitimate-interest basis may apply rather than consent, though you still need a privacy notice accessible from that page explaining what is collected and why.
The position changes if you want to tie that scan to an individual or a device for retargeting, session stitching across multiple QR touchpoints, or location-based analytics. At that point, you likely need consent, and the landing page must present it before any identifier is written to a cookie, local storage, or your backend. A practical approach is to serve a lightweight consent layer on first visit that separates two decisions: access to the content (no consent needed) and participation in analytics or marketing (consent required). Dynamic QR codes make this feasible because the destination URL can be updated server-side without reprinting the physical code.
NFC tags in museums and galleries
Museum visitors tapping NFC tags at exhibits typically expect to receive interpretive content—text, audio, or images. If the NFC tag simply encodes a static URL that opens a web page, the same principles apply as with QR: the tap is an action, not a consent signal. If the museum wants to build a visit path—recording which exhibits a particular visitor tapped in what order—that requires a mechanism to identify the device across multiple taps, and consent must be obtained before that tracking begins.
One practical pattern is to present a consent prompt on the first tap of a visit, store the preference in the browser's local storage, and check it on subsequent taps within the same session. This works reasonably well for a single visit but does not persist across days or after the visitor clears browser data. For museums that want longitudinal data—return visits, repeat engagement—the app-free approach has a structural limitation that should be acknowledged in planning.
Web Bluetooth and Eddystone URL beacons
Web Bluetooth allows a web page to interact with nearby BLE devices directly through the browser, without an app. The browser itself enforces a permission prompt: the user must explicitly click "allow" when asked whether the page can access nearby Bluetooth devices. This prompt is a form of consent, but it is limited to the device-connection layer. It does not cover what your server does with the data transmitted over that connection, so a separate privacy notice and, where required, a separate consent mechanism for analytics or marketing are still necessary.
Eddystone URL beacons broadcast a URL that appears as a "nearby" notification on Android (Google's Nearby Notifications feature was discontinued in 2018, but Physical Web and similar mechanisms still operate in some contexts). If a visitor taps that notification and opens the URL, they arrive at a landing page with the same consent considerations as a QR scan. The difference is that the visitor did not make a deliberate scanning motion; the notification appeared passively. This makes the transparency requirement even more important, because the user may not immediately understand why they are seeing the page or what system generated it.
Signage and notice at the point of interaction
For app-free experiences, physical signage near the QR code, NFC tag, or beacon zone is often the first opportunity to set expectations. A notice stating something like "Scanning this code will open a web page. We may log anonymised page views to improve our service. See [privacy URL] for details" provides a baseline of transparency. If you are collecting anything beyond anonymised aggregate data, the notice should be more specific and should direct the visitor to the full privacy information before they scan or tap.
Retention limits and ongoing governance
Assuming the scan or tap equals broad consent
This is the single most frequent error. A visitor who scans a QR code to read a menu has not consented to location tracking, device fingerprinting, or marketing emails. If your system performs any of these, you need a separate, specific consent mechanism on the landing page, and the visitor must be able to access the content even if they refuse.
Bundling content access with analytics consent
If the only way to read the exhibit label is to accept analytics cookies, the consent is not freely given. The content must be accessible regardless of whether the visitor agrees to optional data processing. Design the landing page so that declining analytics still delivers the primary experience.
Collecting device identifiers without a clear basis
Some QR and NFC platforms generate a unique session ID or write a persistent identifier to local storage to recognise returning visitors. If that identifier can be linked to an individual—directly or through combination with other data—you need a lawful basis, typically consent. If it is truly anonymised and cannot be linked back, the processing may fall outside the scope of personal data entirely, but the bar for "truly anonymised" is higher than many assume. Check your platform's documentation to understand exactly what is stored and whether it can be reversed.
No link to a full privacy notice from the landing page
The landing page is often the only digital touchpoint in an app-free flow. It must contain or link to a privacy notice that explains what data is collected, the legal basis, retention periods, and the visitor's rights. A privacy notice buried in a site-wide footer that is not easily reachable from the proximate landing page is unlikely to meet the transparency requirement.
Ignoring session boundaries
Without an app, consent stored in browser local storage expires when the session ends, the browser is closed, or the user clears site data. If you need consent to persist across visits, you must either re-ask each time (which creates friction) or use a different mechanism such as a progressive web app with installable consent state. Be clear in your planning about whether your use case requires persistent consent and, if so, whether an app-free approach can realistically deliver it.
Key checks before going live
- Map every data point your system collects from the moment the visitor scans or taps, including server logs, third-party analytics scripts, and any identifiers written to the device.
- For each data point, document the lawful basis and ensure consent is obtained before collection if that is the basis you are relying on.
- Verify that the landing page is accessible and functional even if the visitor rejects all optional processing.
- Confirm that a privacy notice is directly reachable from the landing page, not just from a general website footer.
- Test the experience on both iOS and Android, as browser behaviour, local-storage persistence, and Web Bluetooth support differ significantly between platforms.
- Check whether your QR or NFC management platform injects its own tracking scripts and, if so, whether those are covered by your consent mechanism or operate under a separate basis.
- Review physical signage near each touchpoint to ensure it accurately describes what will happen when the code is scanned or the tag is tapped.
App-free proximity experiences trade persistent control for lower friction. That trade-off is legitimate, but it places greater weight on the landing page, the signage, and the honesty of your data-flow mapping. Where the use case demands ongoing consent, preference memory, or granular withdrawal, the limitations of the app-free model should be weighed honestly against the operational benefit of not requiring an install.
