The practical problem behind the topic
Data minimisation is one of the core principles in UK data protection law. For proximity systems—beacons, NFC interactions, QR scans and indoor navigation—it means collecting only the information genuinely necessary for each specific purpose, and nothing more. The principle applies at every stage: what you choose to log, how finely you record it, how long you keep it and whether you aggregate or delete it afterwards.
In a proximity context, the temptation to over-collect is structural. Beacons broadcast constantly, receivers can log every packet, and indoor-navigation platforms often generate high-frequency position updates. The fact that a signal can be captured does not make capturing it lawful or proportionate. Before deploying any hardware, you need a clear, documented statement of why each data point is needed and what would break if it were absent.
The UK Information Commissioner's Office expects organisations to demonstrate minimisation through concrete design choices, not policy statements alone. That means your technical architecture—what the beacon firmware logs, what the app transmits, what the server stores—must reflect the principle. A privacy notice that says "we only collect what we need" carries little weight if the backend is quietly archiving every RSSI reading with a timestamp and device identifier.
What "necessary" actually means in practice
Necessity is judged against the stated purpose. If the purpose is "count visitors per gallery per hour," then storing individual device paths through the museum is not necessary—aggregate counts are sufficient. If the purpose is "trigger a notification when a shopper enters the footwear zone," then the system needs to detect zone entry, not maintain a continuous log of that shopper's coordinates.
The purpose must also be specific. "Improving the customer experience" is too vague to justify location tracking. "Sending a relevant offer when a loyalty-app user enters a zone they have opted into" is considerably more defensible, because it defines both the trigger and the boundary.
Granularity and frequency
Two dimensions of minimisation are frequently overlooked in proximity deployments: spatial granularity and temporal frequency. Spatial granularity is the level of detail in the location record. Zone-level presence ("the device was in Zone 3") is less intrusive than coordinate-level tracking ("the device was at x, y coordinates updated every second"). Temporal frequency is how often you record. A check-in event when someone taps an NFC tag is a single data point. A beacon system that logs a receiver's RSSI observation every 200 milliseconds generates a continuous stream.
The correct granularity and frequency are determined by the use case, not by what the hardware is capable of. A warehouse asset-tracking system may legitimately need metre-level positioning updated every few seconds. A museum audio-guide trigger needs only to know that a visitor entered an exhibit zone. Designing to the lower bar that still satisfies the purpose is the essence of minimisation.
From requirement to verifiable operation
Retail footfall counting
A common retail use case is measuring how many people pass through a department or dwell near a display. If the purpose is purely aggregate footfall, the system should be designed so that individual device identifiers are processed and discarded at the edge or within a short processing window, with only the count reaching long-term storage. Some beacon platforms offer an on-device or gateway-level aggregation mode specifically for this reason. When evaluating hardware or a platform, ask whether aggregation can happen before data leaves the local network.
Proximity-triggered notifications
When a beacon or NFC interaction triggers a notification, the system needs to verify that the user is in the right zone and has an active opt-in. It does not, in most cases, need to record that detection event for analytics. If you do want to measure how many notifications were delivered, you can log the event count without storing the device identifier alongside it. The distinction matters: "notification sent to an anonymous device in Zone 4" is a different data point from "notification sent to device ABC123 at 14:03:22."
Indoor navigation paths
Wayfinding apps necessarily process real-time location data to draw the route on screen. Whether the backend stores that path is a separate design decision. For a one-off visit to a conference centre, retaining the route after the session ends is hard to justify. For a hospital wayfinding system being evaluated for future layout changes, a short retention period with clear deletion may be defensible—but only if the data is pseudonymised and the purpose is documented before collection begins.
Event check-in via QR or NFC
Scanning a QR code or tapping an NFC tag at an event entrance is a point-in-time interaction. The data minimisation question is what you record: the ticket identifier and scan timestamp are typically necessary for admission control. Recording the device model, battery level or additional telemetry from the scanning device is not. Ensure your check-in app or scanner software is configured to send only the fields the admission system requires.
Questions to put to a platform supplier
- Can the platform aggregate at the gateway before transmitting to the cloud?
- What fields are included in each event log by default, and can unused fields be disabled?
- Is there a configuration option to discard raw identifiers after a defined processing window?
- Does the analytics dashboard require individual-level data, or can it work with pre-aggregated inputs?
- Can retention periods be set per data type rather than globally?
Acceptance, records and review triggers
Logging everything because storage is cheap
The argument that cloud storage is inexpensive misses the point. Minimisation is not a cost-saving measure; it is a legal obligation. A large historical dataset of individual location traces is a liability under UK GDPR regardless of what you paid to store it. If you cannot articulate a current, specific purpose for retaining each data type, it should not be kept.
Conflating minimisation with anonymisation
Reducing the granularity of what you collect is not the same as stripping identifiers from data you have already collected. Minimisation asks whether you need the data point at all. Anonymisation or pseudonymisation addresses what you do with data you have decided to keep. Both matter, but they are separate controls applied at different stages. Designing a system to collect less in the first place is always preferable to collecting heavily and anonymising later.
Default-on telemetry in beacon firmware
Some beacon management platforms log every configuration change, firmware update, battery-level report and telemetry ping by default. For fleet management, a subset of this is useful. For privacy compliance, the remainder is unnecessary data about the beacons themselves—but if those logs are tied to location or time patterns that could reveal staff movements or visitor presence, they fall within scope. Review what the beacon's backend logs automatically and disable what you do not need.
Ignoring derived data
Data minimisation applies to derived and inferred data as well as raw inputs. If your system starts with zone-entry events and then calculates "average dwell time per visitor per zone," that derived metric is still personal data if it can be linked back to an individual. The question is whether you need visitor-level dwell times or whether zone-level average dwell is sufficient. Often, the aggregate figure serves the operational purpose—understanding queue buildup or exhibit popularity—without the individual-level risk.
Key checks before going live
- For each data field in your event schema, write down the specific purpose it serves. If you cannot, remove the field.
- Confirm that spatial granularity matches the use case: zone-level where possible, coordinate-level only when justified.
- Set temporal resolution to the lowest frequency that still meets the purpose.
- Define retention periods per data type before deployment, not afterwards.
- Verify that aggregation or deletion happens automatically rather than relying on manual processes.
- Check whether your platform's default logging settings collect more than your privacy notice describes.
Data minimisation in proximity systems is fundamentally a design discipline, not a compliance checkbox. The decisions that matter—what to log, at what granularity, for how long—are made when you configure the hardware and write the data pipeline, not when you draft the privacy policy. Getting those technical choices right at the outset avoids both regulatory risk and the operational burden of managing datasets you never actually needed.
