At a glance

Do not decide that analytics are "anonymous" from a product label. Document what a sensor receives, what happens in memory and at the edge, what leaves the device, whether records can single out or be linked to a person, who receives them and how long they persist. Then establish necessity, lawful basis, transparency, security and whether the likely risk requires a DPIA.

Scope and status. This guide addresses operational planning under the UK GDPR and EU GDPR for commercial and public-facing digital signage analytics. Rules, regulator guidance and national implementations can differ. It was last reviewed on August 7, 2026 and is not legal advice. Consult your data protection officer or qualified adviser for the intended processing and countries involved.
In this guide
01

Map each analytics activity before classifying the risk

"Digital signage analytics" is not one processing operation. Basic device telemetry may report that a player is online, a file was downloaded and a playlist ran. Proof-of-play can record content, endpoint and time without observing an audience. Those records can still contain staff account identifiers, IP addresses or location data, but their privacy profile differs sharply from a camera that detects faces or a sensor that follows wireless device identifiers.

Audience measurement may count entries, estimate dwell, infer an approximate age range, classify attention or connect exposure with a later interaction. Touchscreens and kiosks may create event trails, search terms, accessibility selections, order references or contact details. Wi-Fi and Bluetooth systems may observe device addresses or derived identifiers. A camera can process identifiable images even if the supplier promises not to store video. Collection, transient computation and disclosure are processing; storage is not the only test.

Personal data includes information relating to an identified or identifiable person. Pseudonymised records remain personal data when re-identification remains reasonably possible. Truly anonymous, aggregate counts fall outside GDPR, but anonymisation is an outcome that must be supported by the design and context. A hashed device identifier, persistent face template or rare journey pattern is not automatically anonymous because a name is absent.

Example digital signage analytics data map
ActivityInputOutputKey question
Device monitoringStatus, IP, software versionAlerts and uptime historyAre staff or account records attached?
People countingVideo or dedicated sensor signalCounts by time and zoneCan raw input or trajectories identify people?
Audience estimationFace or body observationsDwell or demographic inferenceWhat is inferred, retained and linked?
Interactive journeyTouches, searches, form fieldsSession and conversion eventsDoes a session connect to a person or order?
Exposure matchingScreen log plus loyalty or device dataAttributed outcomeWho performs the match and for what purpose?
02

Fix the purpose before choosing a lawful basis

Write a specific purpose for every activity. "Improve experience" is too broad to test necessity or explain collection. Better examples are measuring queue length to schedule staff, counting aggregate visits to compare site capacity, monitoring endpoint health or evaluating whether wayfinding reduces requests for assistance. Keep security monitoring, commercial measurement, personalisation and research separate when their objectives and consequences differ.

The controller must identify an Article 6 lawful basis before processing. Legitimate interests may be considered for some proportionate commercial analytics, but requires a documented purpose, necessity and balancing assessment; it is not a default permission. Consent must be freely given, specific, informed and withdrawable, and is difficult to rely on where people cannot realistically avoid a monitored public space. Public bodies may have a public-task basis for defined functions. Contract is narrow and only applies where processing is objectively necessary for a contract with the individual.

Determine whether special-category data is involved. A face image is personal data when identifiable. It becomes biometric data in the special-category sense when specific technical processing is used for the purpose of uniquely identifying a person. Systems that infer health, ethnicity or other protected characteristics can also create special-category issues. A second Article 9 condition is then needed in addition to Article 6. Avoid collecting such data merely because a vendor dashboard offers the field.

Procurement rule: do not allow a feature demonstration to define the purpose. The organisation using the system should document the decision need first, then buy only the minimum processing capable of meeting it.
03

Screen for a DPIA early enough to change the design

Under both regimes, a data protection impact assessment is required where processing is likely to result in a high risk to people's rights and freedoms. The ICO highlights systematic monitoring of a publicly accessible area on a large scale. Its screening guidance also points to factors such as evaluation or scoring, automated decisions with significant effects, sensitive data, large-scale processing, matching datasets, vulnerable people and innovative technology. A combination of factors often indicates the need for a DPIA, but this is not a mechanical points test.

A camera-based audience system across hundreds of stores, persistent tracking between zones, emotion inference or matching screen exposure to loyalty records deserves close scrutiny. So does deployment around children, patients, employees or people using essential services. A basic count produced at the edge with no raw images retained may present a lower risk, but the organisation still needs evidence for that conclusion. If the decision is not to run a DPIA, record the screening and reasons.

Start before contracts and installation. The DPIA should describe flows and actors, assess necessity and proportionality, consult relevant stakeholders where appropriate, identify possible harms, rate likelihood and severity, select measures, record residual risk and obtain sign-off. Seek DPO advice where one is appointed and document it. If high residual risk cannot be mitigated, regulator consultation may be required before processing starts.

  1. Screen the real configured service, not the supplier's generic product.
  2. Include pilots, diagnostics, support access and model improvement flows.
  3. Consider people who do not engage with the screen but enter sensor range.
  4. Test less intrusive alternatives and explain why they are insufficient.
  5. Assign every mitigation to an owner and verify it before go-live.
  6. Review the DPIA after changes in purpose, model, sensor, sites or recipients.
04

Use edge processing and minimisation as verifiable controls

Privacy by design begins with the question the organisation needs to answer. If an hourly count is sufficient, do not retain frame-level observations. If a queue threshold is the goal, consider generating only a current occupancy state. Process at the edge where feasible, discard raw images immediately, remove persistent identifiers, use coarse time bands and suppress small cells that could expose a rare journey. Disable optional fields and diagnostic capture by default.

Verify the claim. Ask what is held in memory, temporary storage, support logs and crash dumps; whether remote engineers can activate a stream; whether images are sent to a cloud model; whether the provider reuses observations to train or improve its systems; and whether a supposedly random identifier persists between visits. Architecture diagrams, configuration exports and tests are stronger evidence than the word "anonymous" in a brochure.

Establish retention per dataset and purpose. Operational alerts may need days, aggregated trends months and raw diagnostic material only long enough to resolve a documented fault. Automated deletion should be tested across the primary platform, backups, exports and support systems. Separate tenancy and encryption matter, but so do role-based access, multi-factor authentication, secure updates, vulnerability handling and alerts for unusual exports.

Accuracy is a privacy and fairness issue. Validate sensors across lighting, placement, crowd density, mobility aids and relevant user groups. Document uncertainty and prevent estimates from becoming assertions about an individual. Do not use an aggregate measurement tool to make decisions about a person unless that new purpose has been separately assessed and communicated.

05

Make transparency work at the point of observation

People should not have to notice a hidden camera and search for a privacy page. Use layered information: a concise notice before or at the monitored zone, a short explanation near the display where practical, and a detailed online notice available through a short URL or QR code. State who is responsible, what is collected or inferred, why, the lawful basis, principal recipients, retention, rights and how to raise a concern. Do not describe video analytics as "footfall only" if the device processes faces to create the count.

The notice must reflect the actual configuration at that site. If some locations use cameras and others use infrared counters, use a site or sensor register to keep information accurate. Coordinate privacy notices with ordinary CCTV signage without obscuring the different purposes. Employees may need separate information and consultation where workplace monitoring is involved.

Design a rights-handling procedure even when the intention is to aggregate quickly. Teams need to know whether data can be located, corrected, deleted, restricted or objected to, how identity will be verified proportionately, and which supplier must assist. If records are genuinely anonymous and cannot be connected to a person, explain that limitation accurately rather than promising retrieval that the system cannot perform.

06

Control suppliers, transfers and change throughout the lifecycle

Determine the controller and processor roles for each flow instead of assigning labels by contract alone. The venue or brand will often determine the purpose of measurement; a technology provider may be its processor for hosting and support. A provider that independently reuses data for product training or benchmarking may have a different role for that activity. Document instructions, confidentiality, security, subprocessors, assistance with rights and DPIAs, breach notification, deletion and audit rights in an Article 28-compliant arrangement where applicable.

Map every hosting and support country. UK and EU transfer rules are related but not identical. Check the applicable adequacy decision or safeguard, the destination risk, onward transfers and whether support access creates a transfer. Keep the assessment current when a supplier changes cloud region or subprocessor. Procurement should require advance notice and a meaningful right to object or exit.

Treat new models, demographic fields, cross-site identifiers, loyalty matching, retention extensions and new dashboards as change events. The product team should not switch them on without the same privacy review used at launch. On termination, revoke device and user credentials, export only justified records, obtain deletion confirmation and verify that sensors no longer collect. Good governance makes privacy a release gate, not an annual document.

07

Official sources and operational references

DOWNLOADABLE PLANNING TOOL

Map analytics data flows before procurement or rollout.

Use the workbook to document purpose, sensors, personal-data questions, processors, retention, mitigations and review ownership.

Download the DPIA workbook Book a privacy-by-design review