Scope the question before collecting data
An analytics dashboard for a proximity campaign is the interface where raw Bluetooth, NFC, or QR signal data is converted into readable metrics. It is not a magic window into customer behaviour; it is a filtered view of events that your hardware, app, and backend have successfully registered. Understanding exactly what is being measured, and what is being discarded, is the first step toward using these tools effectively.
Most dashboards sit within a campaign management system or a dedicated IoT platform. They aggregate three core data types: device detections (a phone saw a beacon or scanned a code), notification deliveries (the system sent an alert), and engagement actions (the user opened the notification or tapped a link). The critical distinction is between a detection and an engagement. A phone passing a shop entrance might register fifty beacon pings, but if the user has not granted location permissions or does not have the relevant app installed, those pings are invisible to the dashboard.
The quality of a dashboard is entirely dependent on the calibration and filtering applied before the data reaches the screen. If beacons are poorly placed or RSSI thresholds are too loose, the dashboard will display inflated footfall figures. If filtering is too aggressive, genuine visitors will be excluded. When evaluating a dashboard, look at the underlying logic—how it handles signal bounce, how it deduplicates repeated pings from the same device, and how it respects the user’s current consent status.
Compare periods, zones and audiences fairly
How a dashboard is used depends heavily on the physical environment and the objectives of the campaign. The metrics that matter to a retail operations manager differ from those tracked by a museum curator or an event organiser.
Retail environments
In a retail setting, dashboards are typically used to measure zone activity and notification conversion. A useful layout will show a floor plan with heat-mapped detection zones, allowing staff to see where dwell times are highest. For a promotion near the till, the key metrics are the number of unique devices that entered the trigger zone, the number of notifications successfully delivered, and the open rate. If the open rate drops significantly at certain times of day, it may indicate notification fatigue or a change in shopper behaviour that requires adjusting the broadcast frequency.
Museums and galleries
Museum dashboards tend to focus on exhibit engagement and visitor flow. Rather than pushing sales notifications, the system might trigger audio guide content or information panels. Here, the dashboard should display trigger counts per exhibit, average dwell time per zone, and the path visitors take between points. This data helps curators understand which exhibits hold attention and whether the physical layout creates unintended bottlenecks. A practical check is to compare the dashboard’s dwell times against manual observations; if the digital data consistently overestimates time spent, the RSSI timeout settings likely need adjustment.
Events and temporary venues
For events, dashboards need to handle high-density, short-duration traffic. Real-time views are more valuable here than in retail or museums. Organisers use live dashboards to monitor queue lengths at entry points, track movement between seminar rooms, and measure attendance at specific activation zones. Because event infrastructure is often temporary, the dashboard must also highlight hardware health—such as beacon battery levels or offline scanners—so technical staff can replace units before they fail during a peak period.
Real-time versus historical views
Most platforms offer both views, but they serve different operational purposes. Real-time dashboards are for tactical responses: redirecting staff to a busy zone or spotting a failed beacon. Historical dashboards are for strategic decisions: evaluating whether a two-week campaign justified the hardware investment. A common configuration error is setting a real-time dashboard to refresh too frequently, which creates visual noise and makes it difficult to spot genuine trends. A refresh interval of one to five minutes is usually sufficient for operational monitoring.
Interpretation, action and review
The most frequent mistake is treating dashboard metrics as precise counts of human beings. A proximity dashboard measures device signals, not people. One person carrying two phones will register as two devices. A family walking together might appear as a single device if only one phone has Bluetooth enabled and the app installed. Presenting these figures as exact visitor counts to stakeholders undermines trust in the system.
Another common error is ignoring the impact of operating-system-level privacy changes. Both iOS and Android have progressively restricted background location access and Bluetooth scanning. A dashboard might show a sudden drop in detections that has nothing to do with lower footfall and everything to do with a recent OS update. When reviewing dashboard data, always cross-reference detection drops with known OS release schedules.
Key limitations to keep in mind
- Signal noise: Dashboards cannot distinguish between a customer standing still and a device left on a table. Without sensible dwell-time thresholds, static devices inflate zone occupancy figures.
- Consent dependency: Under UK GDPR, devices that have not opted in must not be tracked individually. Dashboards may show aggregate, anonymised counts for non-consented devices, but they cannot link those to specific profiles or previous visits.
- NFC and QR blind spots: Unlike beacons, which detect beacon broadcasts on receiving devices, subject to permissions and platform behaviour, NFC and QR require a deliberate physical action. A dashboard will only show an interaction if the user actually tapped or scanned. Low numbers do not necessarily mean low interest; they may indicate poor signage or inaccessible tag placement.
Questions to put to a dashboard provider
Before committing to a platform, clarify the following points:
- How does the system deduplicate repeated pings from the same device within a set time window?
- What happens to data when a device moves between zones—does it count in both, or is it handed off cleanly?
- Can you manually adjust RSSI sensitivity and dwell-time filters, or are these hardcoded?
- How does the dashboard handle data retention and deletion requests from individuals exercising their data rights?
- Is the raw event log exportable for independent analysis, or are you restricted to the platform’s pre-built charts?
A well-configured dashboard is a practical operational tool, not a marketing trophy. Focus on setting sensible filters, understanding the gap between device signals and human behaviour, and using the data to make immediate physical adjustments—moving a beacon, rewriting a notification, or changing a trigger zone—rather than treating the screen as an end in itself.
