Why distance estimates move
The terms immediate, near and far originate from Apple's iBeacon specification. They describe three proximity zones that a receiving device assigns to itself based on the relationship between the beacon's advertised transmit power and the received signal strength indicator (RSSI) at the phone. They are not direct distance measurements.
A beacon broadcasts a measured power value at one metre during calibration. The phone compares that reference figure against the RSSI it actually detects. The gap between the two numbers determines which zone the device falls into. Because RSSI fluctuates with the environment, the resulting zone is an approximation, not a ruler reading.
The standard zone definitions break down as follows:
- Immediate: Typically within a few centimetres. The device is very close to the beacon, often within arm's reach or directly adjacent. In practice, this zone is narrow and the most susceptible to signal instability.
- Near: Roughly within a couple of metres. The device is in the same general area as the beacon — standing in front of a shop display, for instance, or beside an exhibit.
- Far: Beyond the near threshold. The device can detect the beacon but is not in its immediate vicinity. This zone has no defined upper boundary; a beacon may be detectable at far range from tens of metres away in open air.
These classes are specific to the iBeacon protocol. Google's Eddystone format does not define equivalent zones. Instead, Eddystone provides the raw RSSI and transmit power values, leaving the receiving application to define its own thresholds. If your deployment targets both iOS and Android, or uses Eddystone, you will need to implement your own zone logic rather than relying on a built-in classification.
It is also worth noting that the zone boundaries are not fixed distances. A beacon calibrated in an open office will produce different zone boundaries when deployed in a cluttered retail floor. The classes describe relative proximity, not absolute position.
Build thresholds from observed data
The value of accuracy classes lies in triggering different behaviours at different distances without requiring the phone to calculate a precise metre reading. In most deployments, the zones map naturally onto physical interactions.
Retail environments
Far zone detection works well for entrance awareness — greeting a visitor as they approach the store or a specific department. Near zone suits aisle-level content, such as a promotion for the product category the shopper is standing beside. Immediate zone is occasionally used for product-level interaction, such as tapping a phone against a shelf edge to pull up a specific item page, though this use case often overlaps with NFC and QR, which handle that proximity more reliably.
Museums and galleries
Near zone is the most commonly useful class here. A visitor standing in front of a painting is typically in the near zone of a beacon mounted on the wall or plinth beside it. Immediate zone is rarely practical for exhibits because visitors rarely place their phone within centimetres of a fixed beacon. Far zone can trigger general gallery-level information, such as a welcome message or a floor plan.
Events and conferences
Far zone detection helps with broad area awareness — knowing that a delegate has entered the exhibition hall or a particular seminar room. Near zone can trigger session-specific content or check-in prompts when someone approaches the front of a room. Immediate zone has limited application in event spaces unless beacons are integrated into seating or badge scanners.
Choosing which class to act on
A sound approach is to design your trigger logic around the most reliable zone for each use case and avoid depending on immediate zone for anything critical. Because immediate zone is the narrowest and most affected by hand position, phone orientation and minor obstructions, it is better suited to supplementary interactions than essential ones. If a visitor must receive a notification, tie it to near or far. If immediate zone detection works, treat it as a bonus interaction.
When building cross-platform experiences, document your zone thresholds clearly. If you define near as an RSSI offset of between roughly -30 dBm and -60 dBm from measured power on Android, ensure your iOS implementation behaves comparably rather than relying on the iBeacon classes alone, which may not align exactly with your custom thresholds.
Records and triggers for re-testing
Treating zones as fixed distances
The most frequent error is assuming that immediate means "within 10 cm", near means "within 2 m" and far means "beyond 2 m". These figures appear in informal documentation but are not guaranteed by the specification. In a space with significant RF interference or absorptive materials, the near zone might extend to three metres, or the immediate zone might never register at all. Always validate zone boundaries in the actual deployment environment rather than relying on published approximations.
Testing with a single device
Different phone models have different Bluetooth antennas, casing materials and antenna placements. An iPhone held in a hand may report immediate zone, while an Android phone in a thick case at the same physical spot reports near. Test with a representative mix of devices — at minimum, a current iOS device and two or three common Android handsets — before finalising trigger logic.
Ignoring the measured power value
The accuracy class calculation depends entirely on the measured power value being correct for the specific beacon hardware and transmit power setting. If you change the beacon's transmit power from high to low without recalibrating and updating the advertised measured power, every zone calculation on every phone will be wrong. Whenever you adjust transmit power or swap firmware, re-measure and update the one-metre RSSI value.
Over-relying on immediate zone
Because immediate zone requires the phone to be very close to the beacon, it is the most fragile class. A user's hand, a pocket, a bag or a slight angle can shift the RSSI enough to drop the device from immediate to near. If your use case genuinely requires centimetre-level proximity — a specific exhibit, a checkout point, an asset tag — consider whether NFC or a QR code would deliver a more consistent interaction. Beacons are strongest at the near and far ranges.
Key checks before going live
- Verify that the measured power value advertised by each beacon matches a fresh one-metre RSSI reading taken with a reference phone in the deployment environment.
- Walk the space with test devices and log which zone is reported at each physical point you intend to use as a trigger.
- Confirm that your application handles zone transitions gracefully — a phone oscillating between near and far at a boundary should not fire repeated notifications.
- If using Eddystone or a cross-platform approach, document the exact RSSI thresholds you have chosen for each zone and the reasoning behind them.
- Check whether your beacon management platform allows per-beacon measured power configuration, or whether it applies a single value across the fleet — the latter can cause problems if beacons are mounted in different materials or at different heights.
Accuracy classes are a useful abstraction, but they are only as reliable as the calibration and environment behind them. Treat them as a starting point for interaction design, validate them on-site, and keep NFC or QR ready as a fallback when the use case demands close-range certainty.
