Define the audience, purpose and trigger
Measuring a proximity campaign is fundamentally different from measuring a digital advertising buy. With a banner or a paid search click, the ad server logs an impression or a click directly. With beacons, NFC tags or QR codes, the measurement chain passes through physical space, a visitor's device, their consent status and an app or browser before anything is recorded at all. Understanding that chain is the starting point for useful measurement.
The basic data flow runs like this: a beacon broadcasts a signal, a device detects it, an app or web service decides whether to act on that detection, and if it does, a notification is shown or content is loaded. A backend system logs the event. Analytics then aggregates those logs. A break at any stage means no measurement. If Bluetooth is off, nothing is detected. If consent has not been granted, the app must not log the detection. If the venue's Wi-Fi drops, the event may not reach the backend.
This matters because proximity measurement is inherently partial. You are measuring interactions from devices that meet several conditions simultaneously: Bluetooth enabled, location services permitted, your app installed (or a compatible browser for web-based approaches), consent active and a network connection available. The proportion of total visitors who satisfy all of those conditions varies considerably by venue type and audience. A tech conference audience will produce a higher detection rate than a general museum crowd. Stating a campaign reached "3,000 visitors" when it actually reached 3,000 detected devices among an unknown total footfall is misleading and will erode trust in the technology internally.
Under UK GDPR and the Privacy and Electronic Communications Regulations (PECR), consent is not optional and it is not a one-time checkbox. If a user withdraws consent, their data must stop being collected immediately, and historical data handling depends on your retention policy and lawful basis. Measurement systems need to respect that in real time. Any analytics platform you connect to your beacon infrastructure must be capable of filtering out non-consented detections at the point of collection, not retrospectively.
There is also a structural distinction between anonymous, aggregate measurement and identified-user measurement. Aggregate data — how many devices entered a zone, average dwell time — can often be processed with a legitimate interest basis and appropriate privacy controls, provided you are not re-identifying individuals. Linking a zone entry to a named customer in a CRM crosses into a different category and requires explicit consent and a clear privacy notice explaining the linkage. Where this article discusses measurement mechanics, the privacy basis should be confirmed for each data type before deployment.
Measure usefulness without overstating attribution
Retail environments
In a retail setting, the most useful proximity measurement connects a physical zone trigger to a downstream action: a notification opened, a voucher redeemed at the till or a product category browsed. The practical challenge is linking the beacon detection event to the redemption event without forcing the customer through an unreasonable process. If the voucher code in the notification is scanned at the point of sale, that creates a clean link. If the customer simply shows the phone screen and the cashier types in a code, the link depends on till-system integration and consistent data entry.
Footfall counting in retail is a separate measurement from campaign measurement. A beacon placed near an entrance can count devices passing through, giving a relative picture of traffic patterns over time. However, this is not a campaign metric unless you are comparing a period with active notifications against a baseline period without them. Even then, external variables — weather, promotions, school holidays — make attribution difficult without a control group or a sufficiently long measurement window.
Museums and galleries
Museum proximity campaigns typically aim to deepen engagement with exhibits rather than drive a transaction. Measurement here focuses on dwell time near an exhibit, content triggered per visit, route completion through a gallery and return visits to a particular zone. Dwell time is estimated from the sequence of beacon detections: the first detection timestamp and the last detection timestamp before the device leaves the zone give an approximate duration, but the granularity depends on the advertising interval of the beacons and whether the visitor's phone is in a pocket or held in hand.
A practical consideration for museums is the visitor who does not have the venue's app. If your measurement depends entirely on app-based detection, you are measuring only a subset of visitors. Some museums supplement beacon detection with QR codes at exhibits, which provides a content-trigger event but no dwell-time data unless the web page itself sends periodic pings — a technique that raises its own privacy questions and battery-life concerns on the visitor's device.
Events and temporary venues
Event proximity measurement has a particular constraint: time. A three-day conference does not allow for long baseline periods. Measurement needs to be configured and tested before the event opens, with a clear plan for what constitutes a useful data point. Zone visits per attendee, session check-in via beacon rather than manual scan, and navigation usage (how many attendees used the indoor map to find a stage) are all measurable, but each requires the event app to be installed and permissions granted before the first session begins.
Temporary installations also mean beacons may be mounted on stands, truss or temporary partitions rather than fixed walls. The physical environment changes during build-up, which can alter the RF propagation compared to any pre-event survey. Measurement data from the first few hours of an event may not match the calibration done in an empty hall. Noting this in your reporting is more honest than presenting precise-looking figures that were collected under different conditions.
NFC and QR measurement differences
Beacon measurement is passive from the visitor's perspective — the device detects the signal without a deliberate action. NFC and QR measurement is active: the visitor must tap or scan. This distinction affects what you are actually measuring. A beacon zone entry tells you a device was physically present. An NFC tap tells you a visitor chose to interact with a specific tag. The tap is a stronger signal of intent but a much smaller sample. QR scans can be counted server-side with high reliability, but you lose the physical-zone context unless the QR code itself is location-specific.
Dynamic QR codes, where the destination URL can be changed after the code is printed, allow you to redirect traffic without reprinting. From a measurement standpoint, the scan event is logged when the redirect server handles the request, giving you a reliable count. The limitation is that you cannot measure how many people saw the QR code and chose not to scan — only those who did.
Respect choice, frequency and data minimisation
Assuming detection equals impression
The most persistent error in proximity measurement is treating a beacon detection as equivalent to a served impression. A detection means a compatible device with Bluetooth enabled was within range of the beacon's signal at a moment when the scanning interval coincided with the broadcast. It does not mean the user saw a notification, read the content or was even aware of the beacon's presence. If your reporting layer labels detections as "impressions," clarify what that means internally or you will set expectations that the technology cannot meet.
Ignoring the consent funnel
If 100 devices enter a zone, 60 have Bluetooth on, 40 have your app installed, 30 have granted location permissions and 25 have active consent, your measurable population is 25. Reporting the 100 figure as reach inflates the result by a factor of four. Track the consent funnel as a metric in its own right. If the drop-off between app installation and active consent is large, the campaign's measurement ceiling is low regardless of how well the beacons are placed.
Confusing correlation with causation
A visitor receives a notification about a product near aisle four and later buys that product. It is tempting to attribute the purchase to the notification. But the visitor was already in aisle four, already near the product and may have been intending to buy it regardless. Without a control group — similar visitors in the same zone who did not receive the notification — you cannot isolate the campaign's effect. For one-off deployments, a control group may not be practical, and the honest reporting approach is to describe the correlation and note the limitation.
Battery and hardware failures distorting data
A beacon with a depleted battery stops broadcasting. If your analytics show a sudden drop in zone entries, the cause may be a dead beacon rather than a drop in footfall. Without a hardware-monitoring layer that flags battery status or missing beacons, you can misinterpret operational failures as behavioural changes. Any measurement system should include a regular check of beacon health alongside the campaign metrics.
Key checks before launching measurement
- Consent mechanism verified: Confirm that the app or web service correctly filters out non-consented devices before any data leaves the device.
- Baseline period defined: Decide whether you need a pre-campaign baseline and, if so, how long it should run given the venue's traffic patterns.
- Event taxonomy agreed: Define precisely what counts as a "notification sent," "notification opened," "content viewed" and "conversion" in your analytics, and document those definitions so reporting is consistent.
- Beacon health monitoring active: Ensure battery levels and broadcast status are being logged separately from campaign analytics.
- Data retention policy set: Confirm how long raw detection logs will be kept, where they are stored and who has access, in line with your privacy notice.
- Reporting cadence agreed: Decide whether stakeholders will see daily, weekly or post-campaign reports, and what level of granularity each will contain.
Key checks during and after the campaign
- Detection volumes plausible: Compare detected device counts against independent footfall estimates (till data, door counters) to sanity-check the scale.
- Zone boundaries stable: If detections are spilling into adjacent zones or missing expected areas, the physical placement or calibration may have shifted.
- Notification-to-open ratio reasonable: If the ratio of sent to opened notifications is implausibly high or low, investigate whether the logging logic is correct.
- Post-campaign debrief includes limitations: Present results with clear notes on what the data can and cannot support, including any known hardware or environmental issues during the measurement period.
Proximity campaign measurement is not a precision instrument. It is a directional tool that, when set up carefully and reported honestly, tells you whether a campaign generated more engagement than would have happened without it — and where the gaps in your data make that conclusion uncertain. The operational discipline of maintaining beacons, respecting consent and documenting your methodology matters more than the sophistication of your analytics dashboard.
