Data Minimisation in Footfall Analytics

Data minimisation is one of those GDPR principles that is easy to nod along to and hard to actually practise, because practising it means saying no to data you could have collected and might one day find useful. The principle asks a blunt question of every field you gather: do you need this for the stated purpose, or are you keeping it because it was there. For footfall analytics, that question has an unusually clean answer, because footfall reporting turns out to need far less about a visitor than most people assume.

This post takes the minimisation principle and applies it to real footfall data: what the reporting actually consumes, what it can leave uncollected, and how a camera-free method minimises by construction rather than by policy. It sits alongside the design-stage argument in privacy by design at the sensor; that post covers the design principle, this one covers the minimisation obligation applied to what the numbers really need. This is general information, not legal advice.

How does data minimisation apply to footfall analytics?

Data minimisation, from GDPR Article 5(1)(c), says you should collect only the data you actually need for the purpose. Footfall analytics needs very little: how many people entered, how long they stayed, and the shape of the paths they took. It does not need who they were. Ariadne collects only the count, dwell, and trajectory, and captures no face, no biometric template, and no MAC address by default, so the identity data footfall reporting never uses is simply never gathered. Storing an identifier happens only when a visitor explicitly opts in. This is general information, not legal advice; your DPO should confirm the minimisation position for your deployment.

The rest of this post walks the principle, then puts it side by side with the actual inputs a footfall report consumes, so you can see the gap between what the reporting needs and what a data-hungry method would collect.

GDPR Article 5(1)(c) in plain terms, and why minimisation is a live obligation

Article 5 of the GDPR sets out the core principles that all processing of personal data has to follow, and one of them, at 5(1)(c), is data minimisation. In plain terms it says personal data must be adequate, relevant, and limited to what is necessary for the purpose you are processing it for. The word doing the work is "necessary." Not useful, not convenient, not potentially valuable later: necessary for the specific purpose you have named.

That is a live obligation, not a nice-to-have. Minimisation is one of the principles a controller has to be able to demonstrate compliance with, which means "we only collect what we need" is a claim you should be able to back up on request, not a general aspiration. It also cuts against a common instinct in analytics, which is to collect broadly now and decide what is useful later. Under Article 5(1)(c), that instinct is the thing the principle is written to restrain: you are meant to work out what the purpose needs first, and collect to that, not the other way round.

As with the rest of this post, this describes the principle in general terms. The regulation states the obligation; how it applies to your particular deployment, and whether a given field counts as necessary, is a judgement for your data protection officer to make on the facts.

What footfall reporting actually consumes: counts, dwell, path shape

Strip a footfall analytics programme down to what its reports and decisions actually run on, and the list is short. Almost everything a retailer, an airport, or a shopping centre does with footfall data traces back to a handful of inputs:

• Counts. How many people entered a space, a zone, or a store, over a given period. This is the base metric almost everything else derives from, and on its own it carries nothing about who anyone was.
• Dwell. How long people stayed, in the space overall or in a particular zone. Dwell is a duration attached to a location and a time, not to a person.
• Path shape. The shape of the routes people took through the space: which zones connect, where flow concentrates, where it stalls. A path is a geometry, a sequence of positions over time, and it describes movement without needing to name the mover.
• Capture rate. What share of the people who passed actually came in, which pairs an outside count with an inside count. Understanding how reliably a method captures those counts is its own topic; see how accurate people counters are for what affects it and how it is measured.

Notice what every one of those inputs has in common: none of them is about identity. A count is a number. A dwell is a duration. A path is a geometry. You can produce a complete footfall report, run conversion analysis, plan staffing, and evaluate a layout change without ever knowing who a single visitor was, because the analysis operates on aggregates and shapes, not on people.

What footfall does not need, and therefore should not collect

If the reporting runs on counts, dwell, and path shape, then a large category of data that some counting methods do collect is, for footfall purposes, unnecessary. Under a minimisation reading, unnecessary data is data you should not be collecting. The main categories footfall does not need:

• Identity. A name, a face, or any stable identifier that ties one visit to a specific person. Footfall reporting is about the aggregate, so the identity of any individual visitor is not an input to it.
• Demographics. Inferred age, gender, or similar attributes. Some camera-based systems estimate these, but footfall counting and flow analysis do not require them, and inferring them is additional processing of exactly the kind minimisation is meant to question.
• Faces and biometric templates. A facial image or a biometric template is among the most sensitive categories of personal data, and none of the core footfall metrics needs one to be produced.
• Persistent device IDs. A MAC address or similar device identifier persistent enough to recognise the same phone across visits turns a count into a tracked individual. Footfall counts do not need that persistence, and collecting it is a common way a counting method drifts into collecting far more than the purpose requires. That over-collection is the specific problem with older signal methods; see why Wi-Fi probe sniffing collects too much for how MAC-based sniffing gathers persistent identifiers the reporting never uses.

The point is not that these data types are always forbidden. It is that footfall analytics does not need them for its purpose, so under minimisation, a footfall system should not be collecting them. When a system does collect them, the burden shifts: the operator now holds sensitive personal data that the reporting itself never consumes, which is close to the definition of the problem Article 5(1)(c) is written to prevent.

How a camera-free method minimises by construction

Ariadne measures this with Hybrid Fusion, its patented camera-free method. Time-of-Flight depth sensing counts every visitor at the entrances, capturing geometry rather than images, while patented phone signal sensing follows movement through the interior, detecting the signals a phone emits even in airplane mode, and tracks that movement to about one-metre precision. The sensor streams both feeds to Ariadne, where Hybrid Fusion combines them into one trajectory per visit and computes counts, dwell, and paths. The streams carry no identifier: no MAC address, no device ID, no biometric data, and no camera is involved. Identifiers are stored only when a visitor explicitly opts in, which keeps the method GDPR-friendly and outside biometric territory.

Line that up against the two lists above and the fit is exact. The method produces the three things footfall reporting needs, counts, dwell, and paths, and it does so without gathering any of the four things it does not need. Time-of-Flight captures geometry, so no face and no image. Signal sensing reads no MAC address by default, so no persistent device identifier. There is no demographic inference, because there is no image to infer from. And the fusion that assembles a trajectory happens centrally inside the Ariadne platform, working on feeds that already carry no identity, not on the sensor and not at the edge.

This is what "minimises by construction" means. The system is not collecting the full picture and then discarding the identity, which would still be collect-then-discard. It is not gathering the sensitive categories in the first place, so there is nothing to discard. The strongest form of data minimisation is not collecting the personal data at all, and a method that captures geometry and signal counts rather than identity reaches that form by how it is built. The opt-in path is the single, bounded exception: an identifier is stored only when a visitor has explicitly asked to be recognised, which is the one case where storing it is necessary for the purpose the visitor chose.

A minimisation checklist for a people-counting deployment

Minimisation is easiest to enforce at the point you choose a system, because that is when the collection decisions are still open. Once a method is installed, its data appetite is largely fixed. A short set of questions, put to a vendor before you buy, will surface whether a system minimises or over-collects:

1. What does the sensor capture at the moment of capture, before any processing? The honest answer is either an image or it is not. If it is an image, ask what happens to the face in it, and when.
2. Do you read a MAC address or any persistent device identifier by default? "By default" is the operative phrase. A system that collects a persistent ID unless you turn it off is collecting it.
3. Do you infer demographics such as age or gender? If yes, ask which footfall metric requires that inference, because the core ones do not.
4. What of the above is stored, and for how long? Data that is captured and immediately discarded is different from data that is retained, and both are different from data never captured.
5. Where does the processing that combines the data happen, and does that combined record carry an identity? This surfaces whether identity is reconstructed downstream even if the sensor did not capture it.
6. What is the minimum data the reporting actually uses? If a vendor cannot map each collected field to a report that consumes it, the fields without a consumer are the ones minimisation questions.

For a fuller procurement framework that folds these into a complete evaluation, see what to ask a people-counting vendor. And to turn the answers into a documented risk assessment your DPO can sign off, a DPIA template walks the same ground in the format an assessment expects. A method built for camera-free people counting should be able to answer every question above with the minimising answer, and to show it in the architecture rather than assert it in a datasheet.

FAQ

Do I need cameras to count people accurately?

No. Ariadne counts with Hybrid Fusion: Time-of-Flight depth sensing plus patented phone signal sensing, never cameras. Time-of-Flight captures geometry rather than images, and signal sensing captures no MAC address by default, so the measurement involves no video, no faces, and no biometric data.

Is footfall data personal data?

The core footfall metrics, counts, dwell, and path shape, are aggregates and geometries that do not identify anyone, so a method that captures no face and no persistent identifier produces footfall data that is not personal data. Whether a specific implementation processes personal data depends on what it actually collects; your DPO should confirm the position for your deployment.

Do people counters store who visited?

A camera-free method like Ariadne's does not. It captures counts, dwell, and paths with no face and no MAC address by default, so there is no record of who visited. An identifier is stored only when a visitor explicitly opts in for a service that needs it.

What is the strongest form of data minimisation?

Not collecting the personal data at all. Applying controls to personal data after it is captured is a safeguard, but the personal data still existed at the point of collection. A method that captures only counts, dwell, and paths, and no identity, reaches minimisation by not gathering the personal data in the first place.

What data does footfall analytics actually need?

Counts, dwell, path shape, and capture rate. Every common footfall report and decision derives from those inputs, none of which requires the identity, demographics, face, or persistent device ID of any individual visitor.