Context that should shape the decision
A Bluetooth beacon does not track anything. It simply broadcasts a small radio packet at a regular interval, and any device within range with an active Bluetooth radio can receive it. Understanding this one-way broadcast model is the starting point for every deployment decision that follows.
The detection process has four distinct stages. First, the beacon's Bluetooth Low Energy (BLE) radio transmits an advertising packet containing its identifiers and, depending on the beacon protocol, optional telemetry data such as battery voltage. Second, a nearby smartphone, tablet or gateway's Bluetooth radio picks up that packet during a scan window. Third, the device's operating system filters the raw packets and passes relevant ones to any installed application — or, in some cases, a web browser — that has registered to listen for that beacon format. Fourth, the application's logic decides what to do: display a notification, update a position on a map, log an entry, or ignore the signal entirely.
The advertising interval is central to how quickly a device can detect a beacon. If a beacon transmits every 100 milliseconds, a scanning device has frequent opportunities to pick up a packet. If the interval is set to 1,000 milliseconds, detection will be noticeably slower. However, shorter intervals drain the battery faster, so every deployment involves a trade-off between responsiveness and maintenance frequency. Manufacturer documentation will specify the relationship between interval settings and estimated battery life for each hardware model.
Scan behaviour differs significantly between operating systems and between foreground and background states. When an application is open on screen, iOS and Android both allow relatively frequent and responsive scanning. In the background, both operating systems throttle scans to conserve battery, and the exact behaviour changes between OS versions. This means a visitor walking past a beacon with their phone in their pocket may not trigger a response at all, or may trigger it several seconds later than expected. Any system design that assumes instant background detection without testing is built on an unverified assumption.
The received signal strength indicator (RSSI) value that arrives with each packet gives the receiving device a rough measure of proximity. A strong RSSI suggests the device is close to the beacon; a weak one suggests it is further away. However, RSSI fluctuates constantly due to human bodies, metal fixtures, walls and other radio sources, so it cannot be treated as a precise distance measurement on its own.
Implementation choices and evidence
In a retail environment, a common use case is triggering a notification when a customer enters a specific zone, such as the footwear department. The beacon placed above that department broadcasts continuously. A customer with the retailer's app installed walks in, and their device detects the beacon packet. The app's logic checks whether the RSSI exceeds a configured threshold — indicating the customer is genuinely in the zone rather than in an adjacent aisle — then checks whether a notification has already been sent recently to avoid repetition, and finally presents the message. The entire chain from packet arrival to notification on screen can take anywhere from under a second to several seconds depending on OS state, interval settings and signal conditions.
Museum exhibit triggers work on the same principle but with different expectations. A visitor approaches a painting, and their device detects a beacon mounted near the exhibit. The app responds by displaying contextual audio or text. Here, the visitor is usually holding their phone and the app is likely in the foreground, so detection is faster and more reliable than in the retail background-notification scenario. The practical consideration is placement: the beacon needs to be close enough that the trigger fires when the visitor is actually looking at the exhibit, not when they are still three metres away reading a neighbouring label.
Event venues use beacon detection for session check-in and zone-based information. A delegate entering a conference room may have their attendance logged automatically when their device detects a beacon inside the room. The reliability requirement here is different from a marketing notification: a missed detection means a missing attendance record, which may need a manual fallback. Event organisers planning this kind of system should test whether the detection rate over a typical session entry period meets their accuracy requirements, and should have a manual check-in process available as a contingency.
Device variability matters in every use case. Two phones of the same model can produce different RSSI readings in the same position due to minor hardware tolerances. Phones in thick cases, in handbags, or held at different heights will detect the same beacon at different signal strengths. A deployment tested only with one phone model held at chest height will behave differently when visitors use a mix of devices stored in pockets and bags.
Limits, fallback and ongoing ownership
The most frequent mistake is assuming that detection equals positioning. A device detecting a beacon knows it is within range of that beacon, but it does not have a precise coordinate. Systems that treat a single beacon detection as a definitive location fix will produce unreliable results, particularly near zone boundaries where a device might detect beacons from two adjacent zones simultaneously.
A second common error is designing around a single operating system during development and only testing the other at launch. iOS and Android handle BLE scanning, background restrictions and Bluetooth permissions differently, and these differences change with OS updates. A pilot that works reliably on Android in the foreground may fail silently on iOS in the background.
Ignoring the user's Bluetooth state is another oversight. If a visitor has Bluetooth switched off, or has denied location or Bluetooth permissions to the application, no detection will occur regardless of beacon placement or configuration. The proportion of visitors with Bluetooth enabled varies by venue and demographic, and it is worth measuring this during a pilot rather than assuming near-universal availability.
Key checks before committing to a deployment:
- Test detection with at least three different phone models, including both iOS and Android devices.
- Test with phones in pockets, bags and hand, not just held at a consistent height.
- Test with the application in the foreground and in the background.
- Measure the time between a person physically entering a zone and the response appearing on screen, across multiple passes.
- Check whether the system handles the edge case where a device detects two or more beacons simultaneously.
- Verify what happens when Bluetooth is disabled or permissions are denied: the application should degrade gracefully, not crash or display errors.
- Confirm the advertising interval and transmit power settings on every beacon, as factory defaults may not match the deployment plan.
The fundamental limitation is that beacon detection is probabilistic, not deterministic. A beacon transmits, and a device may or may not receive the packet during any given scan window. Over a period of seconds, the probability of at least one successful detection rises, but it never reaches certainty. System designs that account for this inherent variability — through appropriate thresholds, time windows and fallback processes — will perform more reliably than those that assume every broadcast will be received.
