Retail and Service Environments

Retail analytics bundles genuinely useful measurement with applications that carry substantial legal and reputational risk. The bundle is the problem.

The useful aggregate applications

Queue length and waiting time, which drives staffing and is measurable against a real outcome.

Occupancy, for capacity and comfort.

Flow through a store: which routes, which areas get traffic.

Dwell time by area, in aggregate.

Conversion between footfall and transactions, using counts rather than individuals.

Shelf availability, which is inspection of objects and has no privacy dimension at all.

All of these are answerable from aggregate counting with per-person data discarded at source.

The applications that are not that

Sold alongside, in the same product, frequently enabled by default.

Repeat visitor recognition, which is identification.

Demographic estimation — age and sex inferred from appearance — which is biometric categorisation, is of questionable accuracy, and in the EU falls foul of specific provisions.

Emotion or sentiment estimation, which is scientifically contested and prohibited in some contexts.

Watchlist matching against a database of individuals, which is identification with the strongest obligations of any application in this field.

These are different products wearing the same interface, and they require the analysis in the boundary section, not this one.

Separating them at purchase

Ask for the feature list and mark each as aggregate or individual.

Ask whether the individual features can be disabled at the device, not in a settings page.

Ask what is transmitted: derived counts, or images and templates.

Ask what is stored and for how long, and check the default.

Ask for the data flow diagram. A product that cannot produce one is one you cannot assess.

Buy the aggregate capability and refuse the rest, which is usually possible and rarely offered.

The loss prevention case

Where the pressure is strongest, and worth addressing directly.

Detection of a defined event — an unattended bag, a door propped, a person in a restricted area — is a condition and is defensible.

Identification against a watchlist is a different thing: it identifies people, it has an error rate that falls unevenly, and a false match results in someone being approached or accused.

The consequence of an error here lands on a person, which is what separates it from every application in the previous note.

Where it is used at all, it needs the whole apparatus: legal basis, assessment, subgroup performance figures, a human decision before any action, a route to challenge, and retention limits.

Many organisations conclude the reputational and legal exposure exceeds the benefit, and that is a reasonable conclusion rather than a timid one.

Telling customers

A camera notice is not sufficient if the system does more than record.

Say what is analysed, specifically, and what is not.

Say whether anyone is identified. This is the question people actually have.

Publish the retention.

Make it findable and readable, rather than a clause in a policy nobody opens.

An honest, specific notice about aggregate counting attracts almost no objection. One that conceals identification attracts a great deal when it emerges.

The feature audit

A twenty-minute exercise that frequently finds capability nobody chose.

Open the vendor console and list every feature, enabled and available.

Mark each: aggregate or individual.

Check the defaults. Demographic estimation and face detection are commonly on.

Disable what is not needed at the device, not in a reporting filter.

Record the resulting configuration and re-check after every upgrade, because new features arrive enabled.

What a specific notice achieves

Aggregate counting attracts almost no objection when described honestly.

"We count how many people are in the store to manage queues. We do not identify anyone. No images of individuals are kept. Counts are held for 30 days."

Four sentences, checkable, and it answers the question people have.

Compare with a general privacy policy paragraph, which answers nothing and reads as concealment.

Where the honest version is uncomfortable to write, the design is the problem, and that discomfort is useful information at design stage rather than after deployment.