Separate the Data Layers
Data retention in location analytics refers to how long you keep different categories of location-derived information before deleting it. In a beacon, NFC or indoor navigation deployment, this is not a single clock. A system typically holds several layers of data at once: raw signal readings, processed zone events, aggregated footfall counts and summary reports. Each layer has a different shelf life, a different risk profile and a different operational value.
The UK GDPR principle of storage limitation requires that personal data is not kept longer than necessary for the purposes for which it was collected. Location data that can be linked to an individual device or profile falls within this scope. Even when data has been separated from direct identifiers, retaining it beyond its useful life creates unnecessary risk and storage overhead without delivering proportionate insight.
A common source of confusion is assuming that all location data carries the same retention implications. A daily footfall total for a museum gallery, once separated from any individual device record, has a different risk profile than a log of which specific device identifier entered which zone at what time. Treating these as one category leads either to premature deletion of useful aggregated intelligence or indefinite hoarding of sensitive event-level records.
The practical starting point is not a fixed number of days, but a documented purpose for each data type. If the purpose is real-time queue monitoring, the raw event data may lose operational value within hours, even if the aggregated trend is worth keeping for months. If the purpose is comparing visitor flow across seasonal exhibitions, the retention period needs to span at least one full cycle. The retention setting should follow from the purpose, not from a platform default or an arbitrary calendar rule.
Set Purpose-based Retention Periods
Retail environments
In a retail setting, location analytics often serve two distinct purposes: daily operational response and longer-term strategic planning. Zone entry and dwell-time data used for real-time staffing adjustments or queue alerts may only need to be retained in its event-level form for a matter of days. Once the daily or weekly aggregated figures have been produced, the underlying device-level events can typically be deleted. Strategic analysis, such as comparing footfall patterns across product launches or seasonal peaks, relies on aggregated datasets that can be retained for longer provided they are genuinely irreversibly separated from individual device identifiers.
Museums and cultural venues
Museum deployments often track movement between galleries and exhibit dwell times. During a temporary exhibition, the detailed path data is useful for understanding how visitors navigate the space and which exhibits hold attention. Once the exhibition closes, the event-level data tied to that specific layout has limited future value. However, aggregated comparisons between exhibitions, such as average dwell time per gallery or peak visit times by day of week, may justify longer retention. The key distinction is between data that describes a specific visitor's journey and data that describes general venue behaviour.
Events and temporary installations
Event-based deployments have the narrowest retention window. The operational data from a three-day conference, such as session room occupancy or registration area flow, is typically analysed within days of the event concluding. Retaining device-level event logs for months after a one-off event is difficult to justify on operational grounds and increases exposure if a data subject request arrives. Aggregated headline figures, such as peak capacity by zone, may be worth keeping for future event planning, but again only once fully detached from individual records.
Storage and platform questions
When evaluating a location analytics platform, retention capabilities are often overlooked during procurement. Useful questions to put to a provider include whether the system allows different retention periods per data type or per data stream, whether you can export aggregated data before event-level records are deleted, and whether the deletion process produces an auditable confirmation. Some platforms store raw data indefinitely by default and only apply retention policies on request, which means the data exists on their infrastructure regardless of your internal policy until explicit action is taken.
Deletion, Backups and Evidence
Keeping everything indefinitely
The most frequent mistake is retaining raw location event data without a clear expiry, often because the platform does not prompt a decision at setup. The rationale is usually that the data might be useful later, but this conflicts with the storage limitation principle and inflates risk. If a data breach, subject access request or regulatory inquiry occurs, the scope of exposure is directly tied to how much historical data you hold.
Applying a single retention period across all data types
Setting one retention rule for the entire system, such as deleting everything after 90 days, is simpler to configure but typically wrong in practice. It either deletes aggregated intelligence that should have been kept longer or retains sensitive event-level data that should have been purged sooner. The system needs at least a basic separation between raw events, processed analytics and aggregated reports.
Assuming aggregation removes all retention obligations
Aggregated data is lower risk, but it is not automatically free from retention considerations. If the aggregation is reversible, if the group sizes are so small that individuals could be re-identified, or if the aggregated dataset is combined with other sources, it may still fall within scope. The test is whether the data can reasonably be linked back to an identifiable person, not whether it looks anonymous at first glance.
Relying on platform defaults without verification
Many location analytics platforms are configured with conservative defaults that prioritise data availability over minimisation. Unless you explicitly configure and verify retention settings, you may be storing far more than you intend. Checking what is actually stored, rather than what the settings panel suggests, is essential. This means requesting a data inventory or audit from the provider, not simply trusting the dashboard labels.
Key checks before going live
- Can the platform apply different retention periods to raw events, processed analytics and aggregated reports?
- Is there a mechanism to export or archive aggregated data before event-level deletion occurs?
- Does the system produce a verifiable record when data is deleted, or is deletion a silent background process?
- Have you documented the specific purpose and retention rationale for each data category your system generates?
- Have you confirmed what your provider stores on their own infrastructure, separate from what your dashboard shows?
- Is there a process to review and adjust retention periods when the operational purpose changes, such as when a temporary exhibition ends?
Data retention for location analytics is not a set-and-forget configuration. As deployments evolve, as exhibitions change, as event seasons pass, the justification for keeping specific data categories shifts. Building a brief retention review into each project milestone, rather than treating it as a one-time compliance task, keeps the system aligned with both operational needs and regulatory expectations.
