Procurement questions that matter in practice
Compatibility in beacon hardware is rarely a single yes-or-no question. A beacon that broadcasts perfectly well on one site may fail to deliver value on another because the receiving software expects a different protocol, payload structure, or power behaviour. The checklist approach matters because the gaps tend to appear late in a pilot, once hardware is already fixed to walls or ceilings.
At its core, hardware compatibility means confirming that the beacon's broadcast output can be correctly interpreted by whatever is receiving it — a mobile app, a web browser, a gateway, or a third-party analytics platform. That sounds straightforward, but several layers sit between the radio transmission and the useful action.
Protocol and Format Matching
The first layer is the broadcast protocol. Most commercial beacons support iBeacon, Eddystone, or both, and some add AltBeacon. The receiving software must be written to parse the exact format the beacon transmits. An app built around iBeacon will not extract useful identifiers from an Eddystone-UID frame without additional code. If you are procuring beacons for an existing app or platform, confirm the required protocol before ordering anything.
Eddystone offers multiple frame types — UID, URL, EID, and TLM. Not every beacon firmware implements all of them, and not every receiving platform consumes all of them. A museum audio guide triggered by Eddystone-URL needs the beacon to actually broadcast that frame type, not just Eddystone in a general sense.
BLE Version and Device Support
Bluetooth Low Energy has evolved through several versions. BLE 4.0 introduced the basic advertising mode that beacons rely on. BLE 4.2 and 5.0 brought improvements to data throughput and range, but beacons do not automatically benefit from these unless both the beacon chipset and the receiving device support the newer features. In practice, most beacon use cases still depend on the basic advertising channel, so BLE 4.0 compatibility on the receiving device is usually sufficient. However, if a gateway or scanning system relies on BLE 5.0 features such as extended advertising or higher transmit power modes, the beacon hardware must match.
Check the minimum OS versions on the devices your visitors or staff actually carry. Older Android handsets may have inconsistent BLE scanning behaviour, and iOS background scanning rules have changed across versions. The beacon itself does not control these limits, but knowing them shapes realistic expectations for detection reliability.
Supplier claims, testing and qualification
Retail Environments
In a retail setting, beacons often feed into a queue detection system, a footfall analytics platform, or a push-notification engine. Each of these back-end systems has its own requirements. A footfall platform may accept raw RSSI feeds from compatible gateways, while a notification system needs the beacon identifiers mapped to campaign content in its content management system. The compatibility check here is not just beacon-to-phone but beacon-to-gateway-to-platform. Verify that the gateway hardware supports the beacon's transmit power and advertising channel configuration, and that the platform's data ingestion format matches what the gateway exports.
Museums and Exhibitions
Museum deployments frequently use beacons to trigger exhibit content in a dedicated app or a progressive web app. The compatibility question centres on whether the app's scanning logic matches the beacon's broadcast settings. If the app filters by a specific service UUID or manufacturer code, the beacon must be configurable to broadcast that exact value. Some budget beacons lock the manufacturer data field to a fixed value, which can prevent integration with platforms that expect a different identifier structure.
Where museums mix beacons with NFC tags or QR codes at the same exhibit, the backend must handle identifiers from all three sources. This is a software concern, but it affects hardware selection: if the platform assigns content by a universal identifier rather than a beacon-specific one, the beacon hardware simply needs to broadcast that ID reliably in the expected format.
Events and Temporary Installations
Event deployments often involve rapid setup and teardown, sometimes with beacons sourced from different batches or even different suppliers. Mixing beacon models is a common compatibility trap. Two beacons that both claim iBeacon support may behave differently at the same transmit power setting because of antenna design, casing material, or firmware calibration. If your event platform calibrates distance thresholds based on one model's RSSI profile, substituting another model mid-event can shift those thresholds enough to trigger notifications at the wrong moment or not at all.
For events using rented or shared venues, check whether existing building infrastructure — Wi-Fi access points with BLE scanning, security systems, or other IoT devices — operates on the same 2.4 GHz band and could introduce interference. The beacon hardware itself cannot solve this, but selecting beacons with configurable channels and power levels gives you room to adjust around the interference.
Infrastructure-Based Detection
When beacons are detected by fixed gateways rather than visitor phones, compatibility extends to the gateway's scanning firmware. Some gateways only scan for specific manufacturer IDs or filter by expected packet lengths. Others pass all BLE advertisements to the back-end and let software handle filtering. Confirm that the gateway can receive the beacon's exact frame type and that the pairing between beacon and gateway does not require a proprietary handshake beyond standard BLE advertising.
Operational ownership and requalification
Assuming All Beacons Are Interchangeable
The most frequent mistake is treating beacons as commodity hardware. Even within a single manufacturer's range, different models use different chipsets, antenna designs, and firmware branches. A beacon model discontinued and replaced by a "compatible" successor may have a measurably different RSSI curve at the same configured power level. If your system relies on consistent RSSI values for zone detection, swapping models without re-calibrating will produce unreliable results.
Overlooking Firmware and Configuration Lock-In
Some beacons can only be configured using the manufacturer's own app or cloud platform. If that platform changes its terms, loses support, or requires an account that your team cannot access, you may be unable to reconfigure the beacons or update their firmware. Before procurement, check whether the beacon supports open configuration protocols such as the standard Bluetooth SIG provisioning methods or whether it is tied to a single vendor's ecosystem. This matters less for simple set-and-forget deployments but becomes critical for installations that may need re-purposing.
Not Testing with Real End-User Devices
Compatibility testing conducted solely with development phones or high-spec handsets will not reveal the behaviour visitors experience. Budget and mid-range Android devices often have slower BLE scan rates, weaker antennas, or aggressive background process management that delays beacon detection. Run at least a basic detection test with a handful of the most common devices among your expected audience, including older models if your venue serves a broad public.
Key Checks Before Procurement
- Protocol support: Does the beacon broadcast the exact frame type (iBeacon, Eddystone-UID, Eddystone-URL, etc.) that your receiving software expects?
- Identifier structure: Can the beacon's UUID, Major, and Minor values (or Eddystone namespace and instance) be set to the values your platform requires, or are any fields locked?
- Configuration method: Is beacon configuration tied to a proprietary app or platform, or can you use open tools? Can you configure beacons at scale without individually connecting to each one?
- Firmware update path: How are firmware updates delivered, and what happens if the manufacturer discontinues support? Can you roll back a firmware version if an update causes problems?
- Gateway compatibility: If using infrastructure scanning, has the beacon-gateway pairing been tested with your specific gateway model and firmware version?
- Physical and environmental fit: Does the beacon's casing material (plastic, acrylic, metal-backed) suit the mounting surface? Metal surfaces and certain wall materials can detune the antenna regardless of protocol compatibility.
- Power flexibility: Can transmit power and advertising interval be adjusted to suit your environment, or are you limited to a few preset profiles?
- Device-level testing: Have you confirmed detection on a representative sample of the actual devices your visitors or staff will carry?
Running through these checks before placing an order does not guarantee a flawless deployment, but it eliminates the majority of compatibility failures that otherwise surface during pilot testing or, worse, after full-scale installation. When in doubt, procure a small batch first and validate against your specific software stack and physical environment before committing to a larger order.
