Map collection, inference and sharing
When operational managers and venue teams evaluate proximity technology, a common source of confusion is what "location data" actually means in this context. Unlike GPS, which calculates a latitude and longitude coordinate, proximity systems deal primarily with relative position and interaction. Understanding the exact data points generated by Bluetooth beacons, NFC tags, and QR codes is essential for setting realistic expectations and managing privacy obligations.
How beacons generate data
A Bluetooth beacon does not collect anything. It simply broadcasts a small radio packet containing identifiers—typically a UUID, Major, and Minor value—along with a measured transmit power value. The data collection happens on the receiving device, usually a smartphone running a dedicated app or a browser using Web Bluetooth. When the phone detects the broadcast, it reads the Received Signal Strength Indicator (RSSI) and compares it to the transmit power to estimate rough distance. The system then logs an event: a specific device ID was near a specific beacon at a specific time. The resulting dataset does not contain a map coordinate; it contains a record of proximity to a known physical fixture.
NFC and QR interaction logs
NFC and QR systems collect even simpler data. Because these technologies require a deliberate physical action—a tap or a scan—the system records a point-of-interaction event. The typical data fields are the tag or code identifier, a timestamp, and occasionally the device type or operating system if the landing page detects it. There is no continuous tracking, no signal strength measurement, and no ambient presence data. The log simply shows that someone interacted with a specific asset at a specific moment.
On-device vs server-side processing
Where the data is processed significantly alters what is collected. In many modern deployments, the smartphone app determines the user's zone entirely on the device and only sends an aggregated, anonymised payload to the server—for example, "Zone 3, dwell time four minutes." In older or less sophisticated setups, the raw RSSI values and device identifiers might be sent to the server for processing. When evaluating a system, distinguishing between these two architectures is critical because the volume and sensitivity of the collected data differ substantially.
Design controls around the real data flow
The structure of the collected data dictates what insights a venue can realistically extract. Across retail, museums, and events, the practical application of this data relies on defining zones rather than plotting precise paths.
Retail environments
In a retail setting, a typical dataset might show that an anonymised device entered the footwear zone at 10:15, dwelled for seven minutes, and then moved to the till zone. The collected fields are usually limited to a hashed device identifier, the beacon zone ID, entry timestamp, and exit timestamp. Retailers use this to measure footfall by department, assess queue times near tills, or evaluate the draw of window displays. The data does not show which aisle the customer walked down or which specific shoe rack they stood in front of, unless beacons are placed at an impractically dense granularity.
Museums and galleries
Museums typically use proximity data to understand exhibit engagement. A visitor carrying an audio guide device or using a venue app might trigger a beacon at an exhibit entrance. The system logs the exhibit ID, the time the interaction started, and the time the visitor moved out of range to calculate dwell time. If NFC tags are used instead, the log only records the tap. Curators use this data to identify which exhibits hold attention and which are routinely bypassed, informing future layout decisions.
Events and temporary venues
For conferences or festivals, organisers often prioritise flow mapping. By placing beacons at key choke points—corridors, entrance gates, and stage perimeters—the system collects sequential zone entries. The resulting data shows movement trends, such as the volume of people moving from the keynote hall to the catering area between 12:00 and 13:00. Because event infrastructures are temporary, the data is usually tied to session times and is retained only for the duration of the post-event analysis cycle.
Exceptions, incidents and reassessment
Assuming that proximity systems provide the same granular data as outdoor GPS is the most frequent error in project planning. RSSI is highly susceptible to environmental noise. A person standing between a phone and a beacon, a metal display case, or even high humidity can cause the signal to fluctuate wildly, making precise distance calculation unreliable. The data collected reflects an estimated zone, not a plotted coordinate.
The MAC address limitation
Historically, some systems collected the raw Media Access Control (MAC) address of passing smartphones to track footfall without requiring an app. Both iOS and Android now randomise MAC addresses by default to prevent this exact form of tracking. Any supplier proposing a system that relies on harvesting raw MAC addresses for passive footfall counting is offering a technically obsolete approach that will yield incomplete data and poses significant privacy concerns.
Sample bias
Proximity data only reflects the behaviour of visitors who have Bluetooth enabled, have downloaded the relevant app, and have granted the necessary permissions. In a retail context, this might be a small fraction of total footfall. Using beacon data to calculate absolute visitor numbers will produce misleading figures. It is reliable for understanding the behaviour of the opted-in cohort, but that cohort may not represent the general visitor base.
Questions to put to a supplier
Before procuring a system, operational managers should request a sample data export to see exactly what fields are generated. Key questions to ask include whether the data is hashed or anonymised on the device before transmission, what the exact granularity of the zone reporting is, and whether the system retains raw RSSI logs or only processed zone entries. Clarifying where the data is stored, how long it is kept, and what controls exist for deleting it prepares the venue for the compliance requirements covered in the adjacent guidance on UK GDPR and location data.
