What the signal can and cannot indicate
Queue detection built on Bluetooth beacons or other proximity sensors does not give you a precise headcount. It gives you an estimate derived from signal behaviour, and the gap between those two things matters considerably when you are making staffing or service decisions. Understanding where that gap comes from, and how wide it can become, is the starting point for any serious evaluation.
Most retail queue detection systems work by defining one or more zones near a checkout, service desk or entrance, then counting how many distinct devices are detected within those zones over a sliding time window. The system infers queue presence from device presence. That inference is where accuracy lives or dies.
Several factors prevent the inferred count from matching the real count. A device might be detected but its owner is not queuing — they could be browsing an adjacent display, walking past, or standing near a family member who is in the queue. Conversely, a person in the queue might have Bluetooth disabled, no smartphone, or a device with a particularly poor BLE receiver, making them invisible to the system entirely. The detection rate among visitors is never 100%, and the proportion who are genuinely queuing among those detected is never 100% either. Those two fractions multiply.
Manufacturer accuracy claims are frequently based on controlled test environments: open spaces, consistent devices, minimal interference, and clearly defined paths. A busy retail floor with metal shelving, glass fridges, varying ceiling heights and crowds of people moving unpredictably bears little resemblance to those conditions. Until you have measured performance in your own environment, treat any quoted figure as an upper bound, not a working expectation.
It is also important to distinguish between two different accuracy questions. One is count accuracy: how close is the detected device count to the actual number of people queuing? The other is trend accuracy: does the system correctly show the queue growing, shrinking, or staying stable over time? A system can be poor at absolute counts but still useful for trend monitoring, and that distinction should shape how you judge pilot results.
Measure across devices and operating conditions
Checkout queues versus service queues
The accuracy you need depends on what you intend to do with the data. At a supermarket checkout, the operational question is often "should we open another till?" Here, trend accuracy matters more than exact counts. If the system reliably shows a rising detection count in the queue zone, that can trigger a staffing response even if the absolute number is off by a third. The cost of being slightly wrong is low — an extra member of staff who was not strictly needed.
At a dedicated service desk — a post office counter, a pharmacy window, or a bank advisory point — the question is different. Visitors may have taken a ticket and be seated, or the queue may be short but each interaction long. Proximity detection alone struggles here because the physical queue does not map neatly to a dense cluster of devices. In these settings, queue detection is often better suited to measuring wait-time trends from zone dwell time than to counting heads.
Environmental factors that shift accuracy
Physical layout has a direct effect. A narrow corridor leading to a single till creates a relatively well-defined detection zone. An open-plan shop floor where the queue forms organically near multiple checkouts creates overlapping zones and ambiguous readings. Materials matter: metal fixtures and reflective surfaces cause multipath interference, where the same signal arrives at the receiver via multiple paths at slightly different times, distorting the received signal strength indicator (RSSI) reading that distance estimates rely on.
Human bodies attenuate Bluetooth signals. A dense crowd of shoppers between a beacon and a detected device will reduce the RSSI more than empty air would, making the device appear farther away than it is. In a fast-moving low-density environment this effect is modest. In a cramped queue at peak hours it can be significant, and it varies throughout the day in ways that a single calibration pass will not capture.
Calibration in a live environment
Calibration involves taking RSSI readings at known distances in the actual deployment location, then adjusting the algorithm's distance estimates to match. A single calibration session, however, captures one moment. Staff move fixtures, seasonal displays change, and stock levels alter the RF environment. Useful calibration is therefore a process, not an event. Operators who treat it as a one-time setup task typically see accuracy degrade within weeks.
When good enough is sufficient
Not every use case demands high accuracy. If the goal is to generate a rough heat map showing where congestion builds over a trading day, even a noisy signal can produce actionable insights when averaged over time. If the goal is to trigger an automated alert that sends a colleague to a till when the queue exceeds a threshold, the threshold itself can be tuned to absorb some inaccuracy — set it slightly low and accept occasional false positives rather than risk missing real congestion. The mistake is to demand precision the technology cannot deliver and then dismiss it when it falls short, rather than matching the expectation to the use case from the outset.
Records and triggers for re-testing
Assuming RSSI directly equals distance
RSSI is a measure of signal power at the receiver. It correlates with distance, but the relationship is noisy and environment-dependent. Two identical devices at the same distance from the same beacon will report different RSSI values depending on antenna orientation, the presence of obstacles, and even how the user is holding the device. Any system that presents RSSI-to-distance conversion as a simple formula rather than a statistical estimate is oversimplifying the problem.
Ignoring lingerers and passers-by
A detection zone around a queue will inevitably pick up people who are not queuing. If a promotional display sits two metres from the queue, browsers will be counted. If a main aisle runs past the checkout, every shopper walking through will briefly register. Systems can apply dwell-time filters — only counting devices that remain in the zone for more than a set number of seconds — but choosing that threshold involves a trade-off. Set it too low and you count passers-by. Set it too high and you miss people who join a short queue and move through quickly. The right value depends on your specific queue dynamics and must be tested empirically.
Treating zone boundaries as sharp lines
BLE detection zones do not have hard edges. Signal strength falls off gradually, and the point at which a device crosses a notional boundary will flicker as the person shifts position or turns their body. A queue that forms slightly outside the drawn zone, or that snakes around a corner, will be undercounted. During pilot planning, mark zone boundaries on a floor plan and then physically observe where queues actually form at different times of day. If there is a consistent mismatch, adjust the zone or the beacon placement before going live.
Not accounting for device variability
Not all smartphones behave the same way with BLE. Different manufacturers use different chipsets, antenna designs and Bluetooth stack implementations. A device in a thick leather case will produce weaker readings than the same device uncased. Some operating systems throttle BLE scanning to conserve battery, reducing the frequency at which a device is detected. You cannot control any of this, so your accuracy assessment should include a range of common devices rather than a single test phone.
Key checks to run during a pilot
- Manual count comparison: At regular intervals during the pilot, have a staff member manually count the actual queue and compare it to the system's reported count. Log the time, the manual count, and the system count. This is the only reliable way to establish real-world accuracy in your environment.
- Dwell-time distribution: Examine the dwell-time data for the queue zone. If you see a large number of very short detections (a few seconds), these are likely passers-by rather than queuers, and your dwell-time filter may need adjustment.
- Zone overlap analysis: If you have multiple queue zones near each other, check whether the same device is being counted in two zones simultaneously. This indicates overlapping coverage and will inflate your total count.
- Device detection rate: If possible, estimate what proportion of visitors have Bluetooth enabled and detectable. Some platforms can provide an estimated penetration rate based on broader regional data, but a local sample — for example, counting visible phones with Bluetooth active among a group of queuers — gives a more relevant figure.
- Post-change revalidation: After any physical change to the area — moving a display, adjusting shelving, changing the position of a beacon — repeat the manual count comparison. Do not assume the previous calibration still holds.
Questions to put to a supplier
- What accuracy figure are you quoting, and under what test conditions was it measured?
- Does the system use raw RSSI, filtered RSSI, or a probabilistic positioning algorithm? The latter generally handles real-world noise better.
- How does the system handle devices that appear briefly at the edge of a zone — are they included, excluded, or subject to a configurable dwell-time filter?
- Can you adjust zone shapes and thresholds after deployment without a site visit from your engineers?
- What granularity of data is available for manual validation — can I export timestamped detection logs alongside zone definitions?
Queue detection using proximity technology is a useful operational tool when deployed with realistic expectations and validated against ground truth in the actual environment. It is not a people counter, and treating it as one will produce misleading results. The practical value lies in trend detection, relative congestion monitoring, and timely alerts — all of which can tolerate imperfect accuracy provided you understand where the imperfections come from and how to measure their impact.
