Map the information before choosing a rule
Location analytics, in the context of proximity technology, means deriving operational insight from the signals that Bluetooth beacons, NFC readers and other sensors detect when a device moves through a physical space. For UK retailers, museums, event venues and similar sites, the practical question is not what the data looks like on a dashboard, but what decisions it can actually support.
The first distinction to understand is between interaction-based analytics and passive detection. Interaction-based analytics rely on a visitor actively doing something: scanning a QR code, tapping an NFC tag or opening an app that registers beacon detections. Passive detection, by contrast, picks up Bluetooth broadcast packets from devices in discoverable mode without any deliberate visitor action. The two approaches produce very different datasets, face different consent requirements under UK GDPR, and serve different analytical purposes.
A common mistake is assuming location analytics will automatically reveal why visitors behave in a certain way. The data can show that dwell time in a particular zone increased, but it cannot tell you whether that was caused by a new exhibit, a bottleneck, or a group of schoolchildren pausing for lunch. Location analytics produces behavioural observations. Interpreting those observations requires pairing the data with operational context that only venue staff possess.
Before investing in an analytics setup, define which operational questions you need to answer. Common legitimate uses include identifying underused areas, understanding peak congestion points, measuring the effect of a layout change, and comparing visitor distribution across opening hours. If the questions are vague, the resulting data will be voluminous but unactionable.
Footfall and Dwell-Time Metrics
Footfall counting via beacons works by logging a unique device identifier each time a beacon detects that device within its range. Dwell time is calculated as the duration between the first and last detection of that same identifier within a defined zone, often with an inactivity timeout to avoid counting a device that briefly passed through and then sat in an adjacent area.
Neither metric is as straightforward as it appears. A footfall count derived from beacon detections is a count of detected devices, not a count of people. One person carrying two Bluetooth-enabled devices registers as two entries. A visitor with Bluetooth disabled registers as zero. The ratio of detected devices to actual visitors varies by venue type, time of day, and demographic profile, and it changes as device habits evolve. Treating a device count as a people count without understanding this ratio leads to systematically wrong conclusions.
Dwell-time measurements face their own set of complications. If a zone is covered by a single beacon with a range of several metres, a visitor standing near the edge of that zone may flicker in and out of detection, producing an artificially short dwell-time reading. If the timeout is set too generously, a visitor who left the zone five minutes ago but whose last detection has not yet expired will be recorded as still present. Calibrating these parameters requires on-site testing with known paths and real devices, not relying on default platform settings.
For practical use, footfall and dwell-time metrics are most reliable when treated as relative indicators rather than absolute figures. Comparing the same zone on a Tuesday versus a Wednesday, or before and after a layout change, produces useful insight even if the absolute device count understates the true number of visitors by an unknown percentage.
Heatmaps and Zone Analytics
A heatmap in a proximity-analytics context is a visual representation of detection frequency across a floor plan. Brighter or warmer colours indicate zones where more device detections were logged. Zone analytics break the floor plan into defined regions and aggregate metrics such as total detections, unique devices and average dwell time for each region.
The usefulness of a heatmap depends entirely on how the underlying zones are defined and how many beacons are deployed. A venue with three beacons covering a large open floor will produce a heatmap with three broad blobs, which may confirm that the entrance is busier than the back corner but offers little else. Adding beacons increases spatial resolution, but each additional beacon also adds installation work, battery management overhead and calibration complexity.
Zone boundaries are another source of confusion. Beacons do not have sharp edges; their detection range is a fuzzy, uneven shape influenced by antenna orientation, nearby obstacles and interference. When a platform draws a neat polygon on a floor plan and labels it "Zone C", that boundary is a convention, not a physical reality. A device detected by a beacon assigned to Zone C may physically be standing in what the floor plan shows as Zone B. For analytics that compare zones, this bleed effect matters, particularly in areas where zones are small or irregularly shaped.
When reviewing heatmap outputs from a supplier or platform, ask specifically how zone assignments are made, whether overlapping beacon coverage is handled, and whether the visual smoothing applied to the heatmap obscures gaps in detection coverage. A polished graphic that fills the entire floor plan with colour can give a false impression of complete monitoring.
Visitor Journey Mapping
Journey mapping in location analytics means reconstructing the sequence of zones a device moved through during a visit. Rather than looking at a single zone in isolation, journey data attempts to show paths: entrance to zone A, then to zone B, then to the exit, for example.
The fundamental limitation is that beacon-based journey data is a sequence of discrete detections, not a continuous track. Between one detection and the next, the device may have taken any number of routes. If two zones are not directly connected by a corridor but a device is detected in both, the system will still plot a straight line between them on the visualisation unless path logic has been explicitly configured. Review any journey visualisation with a floor plan in hand and check whether the plotted paths correspond to physically possible routes.
Another practical issue is detection gaps. If a visitor walks quickly through a zone with a single beacon set to a long advertising interval, that beacon may not detect the device at all, creating a gap in the recorded journey. The path will appear to jump from the previous zone to the next one, omitting the intermediate zone entirely. Shorter advertising intervals improve detection probability but reduce battery life, a trade-off covered in our beacon battery and maintenance guidance.
Despite these limitations, journey data has genuine value for specific questions. Identifying the most common entry-to-purchase path in a retail setting, or understanding whether museum visitors follow the intended narrative sequence, are both problems where even imperfect journey data provides insight that would be expensive to gather through manual observation alone. The key is to frame questions in terms of sequences and frequencies rather than precise routes.
Comparing Analytics Across Locations and Periods
Organisations with multiple sites naturally want to compare location analytics across venues. A retail chain might want to know whether the same product display drives similar dwell times in different branches. A museum network might want to compare visitor distribution patterns across sites of different sizes.
Direct comparison requires normalisation. Raw detection counts from a large venue with forty beacons cannot be meaningfully compared against counts from a small venue with eight beacons, because the larger deployment detects more devices simply by covering more area. Comparing dwell times across venues requires that zones are defined and measured consistently, which is difficult when floor plans, beacon density and physical layouts differ.
Temporal comparisons within a single venue are more straightforward but still require care. Comparing a Saturday to a Tuesday tells you about day-of-week variation, but only if external factors such as weather, local events or school holidays are accounted for. A sudden drop in detected devices might reflect a change in visitor behaviour, or it might reflect a failed beacon that stopped broadcasting. Always cross-reference unexpected changes against hardware status logs before drawing operational conclusions.
For multi-site comparisons, a practical approach is to define a small set of standardised metrics, such as the ratio of detections in the primary zone to total detections, or the proportion of visits exceeding a defined dwell-time threshold. These relative measures are more robust to differences in beacon density and floor-plan size than absolute counts.
Analytics Tools and Platforms for Proximity
The platform layer sits between the physical beacons or sensors and the analytics outputs that operational staff actually use. Choosing a platform is not primarily a question of feature lists; it is a question of whether the platform's data model matches the questions the venue needs to answer.
Key practical considerations when evaluating platforms include how zone definitions are configured and modified, whether the platform supports custom metrics or is limited to a fixed dashboard, how historical data is stored and accessed, and what options exist for exporting data for analysis outside the platform. If your operational team uses business-intelligence tools internally, the ability to export structured data in a usable format matters more than an impressive built-in visualisation.
Ask providers specifically about how they handle device deduplication across multiple beacons, how they deal with devices that are detected by beacons in non-adjacent zones within a short time window, and whether their dwell-time calculations use a fixed timeout or an adaptive method. These technical details have a direct impact on the accuracy of every metric the platform produces, yet they are often glossed over in sales conversations.
Integration with other systems is a related but distinct concern. Some venues need location-analytics data to feed into workforce-scheduling tools, others need it alongside point-of-sale data, and others need it to trigger content in a visitor app. The extent of integration required should be established before selecting a platform, because retrofitting data exports or APIs to a closed system is often impractical. For the integration and application-layer side of these decisions, the considerations sit outside the scope of this site and are covered in detail elsewhere.
A final point on platforms: the analytics capability is only as good as the underlying deployment. A sophisticated platform fed by poorly placed, uncalibrated beacons will produce confident-looking but misleading outputs. Before investing heavily in the analytics layer, ensure the physical infrastructure has been properly piloted, calibrated and documented.
