The iBeacon Identifier Hierarchy
When a Bluetooth beacon broadcasts its signal, the payload it sends includes a set of identifying values. In the iBeacon protocol, which remains the most widely implemented format in UK retail, museum and venue deployments, those values are arranged in a three-tier structure: UUID, Major and Minor. Together, they tell a receiving app or platform which beacon it is listening to and, by extension, what content or action should be triggered.
The UUID (Universally Unique Identifier) is a 128-bit value that acts as the top-level label. In practice, it is used to identify an organisation, a brand, or a distinct deployment. If a retailer runs beacons in fifty shops across the country, all of those beacons might share a single UUID assigned to that retailer. If the same retailer also runs a separate beacon network for warehouse tracking, that second use case would typically receive a different UUID to keep the two systems logically separate.
The Major value is a 16-bit unsigned integer, giving a range from 0 to 65,535. It sits below the UUID and is used to group beacons within that deployment. Common groupings include individual store locations, floors within a building, or distinct zones at an event venue. A museum might assign Major value 1 to the ground floor and Major value 2 to the first floor, all under the same UUID.
The Minor value is also a 16-bit unsigned integer and identifies an individual beacon within its Major group. Continuing the museum example, Minor value 12 might correspond to a specific exhibit case on the ground floor. The combination of UUID, Major and Minor therefore points to one precise physical location or asset.
This guide focuses on the iBeacon model. Eddystone identifier formats still appear in legacy and controlled systems, but Google’s Nearby Messages service is retired and the format should not be treated as a current universal app-free discovery route
Designing an Identifier Plan
Planning an identifier scheme before purchasing hardware prevents costly rework. The decisions you make about UUID, Major and Minor allocation will shape how your app, content management system and analytics platform interpret beacon signals for the lifetime of the deployment.
Single-site deployments
For an independent museum, a single retail unit, or a standalone venue, one UUID is usually sufficient. The Major value can represent floors or wings, and the Minor value can mark individual exhibits, product displays or points of interest. This keeps the logic straightforward and limits the amount of configuration needed in the receiving app.
Multi-site deployments
The question becomes whether to use separate UUIDs per site or a single UUID with Major values representing each location. Using separate UUIDs provides a clean logical boundary: if one site is decommissioned or sold, its UUID can be disabled in the backend without affecting other sites. Using a single UUID with Major-per-site keeps configuration more centralised but means every site's identifier range must be planned in advance to avoid collisions.
Temporary event environments
A dedicated UUID for each event is often the cleanest approach. Major values can represent stages, zones or halls, and Minor values can mark specific entry points, sponsor activations or accessibility features. After the event, the entire UUID can be retired, and the beacons reprogrammed for the next occasion.
Category-driven versus location-driven allocation
Retail environments sometimes use the identifier structure to tie beacons to product categories or promotional zones rather than purely to physical location. A Major value might represent a department, with Minor values distinguishing individual promotion endpoints within that department. This works when the triggered content is category-driven, but it breaks down if fixtures are frequently moved, since the identifier would no longer match the physical context.
Regardless of the approach, document the scheme in a central register before any beacon is programmed. Include the UUID, the meaning of each Major range, and the specific physical location or function of each Minor value. This register becomes essential during installation, troubleshooting and any future expansion.
Security, Reprogramming and Change Control
One of the most frequent errors is reusing a UUID across unrelated projects or clients. If an integrator programmes beacons for two different organisations using the same UUID, any app configured to listen for that UUID will react to beacons in both environments. This can trigger irrelevant notifications and create confusion in analytics data. Each distinct deployment should have its own UUID unless there is a deliberate, documented reason to share one.
Running out of Major or Minor values is rare for single-site deployments but becomes a genuine risk in large-scale or long-term rollouts. With 65,535 values available at each level, the numbers seem generous, but poor allocation can exhaust them. Assigning a whole Major value to a single beacon, or using Minor values sequentially without gaps, leaves no room for later insertions. Plan ranges with spare capacity, and avoid using 0 or 65,535 as functional values since some platforms treat these as special cases.
Changing an identifier on a deployed beacon without updating the receiving software is a common cause of silent failures. If a beacon is reprogrammed from Minor 5 to Minor 12 but the app still expects Minor 5 at that location, the beacon will broadcast correctly but nothing will happen on the user's device. Any identifier change must be mirrored in the backend configuration, and the update should be tested before the beacon is reinstalled.
Not all beacon hardware supports easy reprogramming. Some low-cost beacons are programmed once at the factory and cannot be changed. Before committing to an identifier scheme, confirm with the manufacturer or supplier that the hardware allows UUID, Major and Minor values to be updated, and understand the process required. If reprogramming is not possible, any change in your identifier logic means replacing the physical unit.
Mixing identifier logic between iBeacon and Eddystone formats causes confusion, particularly if the same physical beacon is configured to broadcast both. The iBeacon UUID, Major and Minor structure and the Eddystone Namespace and Instance structure do not map directly onto each other. If your deployment uses both formats, maintain separate documentation for each and ensure your backend handles the two identifier models independently.
Before going live, verify the following points:
- Every beacon in the deployment has a unique UUID, Major and Minor combination.
- The identifier scheme is documented in a register that someone other than the original installer can understand.
- The receiving app or platform is configured to match the exact identifiers programmed into the beacons.
- Spare ranges exist within the Major and Minor allocations for future expansion.
- The beacon hardware supports reprogramming if identifier changes are likely.
- If multiple formats are in use, each has its own documented identifier logic.
Getting the identifier structure right at the start does not eliminate later maintenance, but it prevents the kind of foundational errors that are expensive and disruptive to correct once beacons are installed across a venue.
