Ownership and operating assumptions
A beacon asset register is a single, authoritative record of every Bluetooth beacon you operate. It ties together the hardware identity, physical location, configuration, battery status and operational assignment of each unit. Without it, even a modest deployment of thirty or forty beacons becomes difficult to manage within months, particularly when batteries start failing or units are moved between zones.
The register is distinct from the physical labelling process covered elsewhere in this series. Labelling deals with what is printed on the casing and where. The register is the structured data that sits behind those labels, giving your operations team a way to look up a beacon by its MAC address, assigned name, or location and immediately see its full history and current state.
At minimum, each entry should capture the following fields:
- Hardware identifier: MAC address and manufacturer-assigned UUID or major/minor values where applicable.
- Assigned name: A human-readable reference that matches the physical label, such as "FLOOR2-ZONE-C-03".
- Hardware model and firmware version: Essential when planning updates or diagnosing inconsistent behaviour.
- Installed location: Specific enough that a colleague can find the unit without a map — floor, zone, fixture or wall position.
- Installation date: The baseline for battery-life calculations and replacement scheduling.
- Battery type and expected life: Referenced from the manufacturer's documentation for the configured advertising interval and transmit power.
- Calibration record: The measured RSSI value at a defined reference distance, logged at installation and after any move.
- Assigned campaign, zone or function: What the beacon is currently doing — triggering a notification, marking a navigation waypoint, identifying an exhibit.
- Status: Active, under maintenance, decommissioned, or in storage.
The format can range from a well-structured spreadsheet for smaller deployments to a computerised maintenance management system (CMMS) or the asset module within a beacon management platform for larger operations. The choice depends on how many beacons you run, how many sites you cover, and who needs to access the data. A spreadsheet works for a single museum or retail unit with under a hundred beacons. Multi-site retailers or venue groups typically need something with access controls and audit trails.
Keep hardware and content under control
Retail environments
In a retail setting, beacons are often grouped by zone — entrance, till area, fitting rooms, specific product bays. The register should reflect that structure, making it straightforward to see which beacons belong to a current promotion and which are idle. When a seasonal campaign ends, the register tells you which units to reassign or power down, rather than relying on memory or a separate campaign document that may not have been updated.
If your retail operation spans multiple stores, include a site identifier in every entry. This allows you to filter by location and also to spot patterns — for example, if one store consistently reports earlier battery depletion, the register helps you correlate that with beacon model, transmit-power settings or environmental factors.
Museums and galleries
Museums frequently rotate exhibits, which means beacons move with them. The register needs a field for the associated exhibit or display case, plus a note of the previous assignment if the beacon was relocated rather than replaced. Without this, staff may pull a beacon from storage assuming it is unconfigured, only to discover it is still programmed for a different exhibit's content trigger.
Calibration data is particularly important here. A beacon calibrated against a stone wall will behave differently when moved to a glass partition. Recording the calibration context — distance, environment, device used — in the register prevents inaccurate assumptions when the unit is redeployed.
Events and temporary deployments
Event beacons have a different lifecycle. They are checked out of storage, installed for a defined period, then returned. The register should support a check-out and check-in workflow, even if that is managed through simple date fields and a status dropdown. Recording which event each beacon attended, and its condition on return, builds a history that informs future procurement and helps identify units that are being damaged through repeated handling or mounting on temporary fixtures.
Access and update responsibility
Decide who can edit the register and who can only view it. In most operations, the facilities or IT team updates hardware fields, while the marketing or content team updates campaign assignments. If you are using a shared spreadsheet, this is difficult to enforce. A platform with role-based access handles it more cleanly. Whichever approach you take, document the responsibility in a brief note within the register itself or in an accompanying operational guide.
Replacement, handover and decommissioning
Confusing identifiers
One of the most frequent errors is mixing up the MAC address, the broadcast UUID and the assigned name. The MAC address is fixed at manufacture. The UUID or major/minor values can often be reprogrammed. The assigned name is your internal convention. If your register does not clearly separate these, someone will eventually reprogram a UUID, assume the old records still apply, and lose track of which beacon is which. Use separate, clearly labelled columns and never rely on a single identifier.
Failing to update after physical changes
A register is only as reliable as the last update. If a beacon is moved during a refit and the register is not amended, every subsequent decision — battery replacement, troubleshooting, campaign assignment — is made against stale data. Build a simple rule: no physical move without a register update, logged with the date and the person who made the change.
Omitting calibration and configuration context
Recording that a beacon is set to "high power" is not enough. High power on one manufacturer's model may correspond to a different transmit level on another. Log the actual transmit-power value in dBm, the advertising interval in milliseconds, and the measured RSSI at one metre. This level of detail takes seconds at installation but saves considerable time when diagnosing range problems later.
Spreadsheet limitations at scale
Spreadsheets degrade as deployments grow. Version conflicts appear when two people edit simultaneously. History is lost when rows are overwritten. There is no automatic alert when a battery-replacement date approaches. If your deployment is likely to exceed a hundred beacons or span multiple sites, plan the register format with that growth in mind from the start, even if you begin in a spreadsheet.
Not linking to physical labels
The register and the physical label must use the same naming convention. If the label on the beacon reads "B2-C3-07" but the register entry says "Beacon 42, corridor 3", someone on the floor will waste time cross-referencing. Agree the naming scheme before you label anything, then enforce it in both places.
Key verification steps
Before considering your register operational, run through these checks:
- Can you take a beacon's MAC address from a monitoring dashboard and immediately find its physical location and current assignment in the register?
- Does every active beacon in the field have a corresponding register entry, and vice versa?
- Are all identifier fields populated — MAC address, UUID or major/minor, and assigned name — with no blanks?
- Is the calibration data present for each unit, including the reference distance and the device used to measure it?
- Is there a clear status field, and are all entries set to the correct current state?
- Does the register indicate who last updated each entry and when?
Conduct a physical audit periodically — quarterly for fixed installations, after every event for temporary deployments — comparing what is on the wall or fixture against what the register says should be there. Discrepancies at this stage usually point to a process gap rather than a technology problem, and fixing the process early prevents the register from drifting into irrelevance.
