Requirements that separate the alternatives
Most Bluetooth beacon projects boil down to one of two approaches: working out roughly where a device is on a floor plan, or simply knowing whether a device has entered a defined area. The first is trilateration; the second is proximity zoning. They solve different problems, carry different overheads, and fail in different ways.
Trilateration estimates a position by measuring the received signal strength indicator (RSSI) from three or more beacons and applying a propagation model to convert those readings into distances. The software then calculates where those distance circles intersect. In a controlled, open environment with careful calibration, this can place a device within a few metres. In a cluttered retail unit or a museum with dense display cases, the error radius widens considerably.
Proximity zoning takes a simpler path. A beacon is assigned to a physical area, and the system triggers an action when a device detects that beacon above a configured RSSI threshold. There is no coordinate calculation, no floor-plan overlay, and no attempt to plot a dot on a map. The question the system answers is not "where exactly is this person?" but "is this person near this thing?"
The distinction matters because trilateration introduces complexity that is only justified when you genuinely need positional data. If your use case is triggering an audio guide when a visitor reaches an exhibit, proximity zoning is the more robust and maintainable choice. If you need to draw a route on a screen and guide someone to a specific meeting room, trilateration (often combined with indoor navigation software) becomes necessary.
Performance, adoption and support differences
When proximity zones are the stronger option
Retail stores commonly use proximity zones at entrances, till points and promotional ends. A beacon mounted above a display triggers a notification when a shopper's phone comes within range. The exact distance does not matter; what matters is that the shopper is close enough for the offer to be contextually relevant. Museums use the same logic beside exhibits, and event venues use it at session rooms and registration desks.
Proximity zones are also the practical choice when you need to deploy quickly, when your team has limited BLE experience, or when the physical environment contains significant signal obstacles. Because each zone depends on a single beacon's RSSI crossing a threshold, the system degrades gracefully: a reading that is off by a couple of decibels might shift the effective zone boundary slightly, but it rarely causes a complete failure.
When trilateration justifies the extra work
Indoor navigation is the clearest justification. If a visitor to a large conference centre opens a map and expects to see a blue dot tracking their movement, you need trilateration (or a hybrid approach combining BLE with Wi-Fi or other sensors). The same applies to asset tracking in warehouses, where operations staff need to locate equipment on a plan rather than simply knowing it is somewhere on the shop floor.
Queue-length estimation in retail banking or transport hubs sometimes uses trilateration to plot device positions over time and infer density. However, this is an advanced application that requires substantial baseline data and careful privacy handling, and in many cases a simpler zone-counting approach achieves a usable result with far less risk.
Operational differences that affect the decision
- Beacon density: Trilateration typically requires overlapping coverage from at least three beacons at any point where you want a position fix. Proximity zoning needs only one beacon per zone, though larger zones may use multiple beacons for more consistent detection.
- Calibration burden: Trilateration demands environment-specific calibration to account for reflections, absorption and obstacles. Proximity zoning still benefits from testing, but the threshold adjustments are more intuitive and easier to validate on-site.
- Advertising interval and battery life: Trilateration systems often use shorter advertising intervals to increase the frequency of RSSI samples, which reduces battery life. Proximity zones can usually operate at longer intervals, extending the interval between battery replacements.
- Device variation: Different phone models have different BLE radio sensitivities and antenna positions. Trilateration amplifies these variations because small RSSI differences shift the calculated position. Proximity zoning is more tolerant because the threshold is binary: above or below.
Fallbacks, lock-in and pilot evidence
Over-specifying the solution
The most frequent error is choosing trilateration because it sounds more capable, without confirming that the use case actually requires coordinates. If your stakeholder says "we want to know where people are," probe whether they mean a specific spot on a map or simply which zone they are in. The latter often satisfies the business requirement at a fraction of the deployment and maintenance cost.
Assuming trilateration accuracy from a datasheet
Manufacturer accuracy claims are typically measured in open, controlled environments. A quoted figure of two to three metres assumes no walls, no people, no metal racking and no competing RF sources. In a real venue, you should expect the error radius to increase, sometimes substantially, until you have measured it yourself. Run a pilot with representative devices in the actual space before committing to a trilateration architecture.
Neglecting the maintenance implication
Trilateration systems are sensitive to environmental changes. Relocating a display case, adding a partition or even changing the stock on shelving can alter signal propagation enough to degrade accuracy. Your operational plan needs to include periodic re-validation, not just battery replacement. Proximity zones are less fragile in this regard, though major physical changes still warrant a walk-through test.
Key checks before deciding
- Write down the exact question the system must answer. If it is "which zone?" rather than "where on the plan?", proximity zoning is likely sufficient.
- Map your beacon density requirements. If trilateration demands three times the hardware for the same floor area, confirm the budget and maintenance capacity can absorb that.
- Test with the phone models your visitors actually carry. Do not rely on a single test device.
- Ask your integrator or platform provider what happens when a device can see only two beacons in a trilateration setup. The fallback behaviour matters in practice.
- Confirm whether your chosen platform supports both approaches and allows you to start with zones and upgrade to trilateration later, rather than locking you into one architecture from day one.
Neither approach is universally superior. The right choice follows from what you need the system to do, what your environment will allow, and what your team can realistically maintain over months and years rather than a single launch week.
