Counting and Flow

Counting people is one of the most useful applications and one of the easiest to do in a way that raises no serious concern — provided one design decision is made correctly.

What it answers

Occupancy, against a limit or a comfort threshold.

Queue length and waiting time.

Flow through a space: which routes, at what times.

Dwell time in an area, in aggregate.

Utilisation of a space across a day or week.

All of these are aggregate questions. None requires knowing who anyone is.

The design decision

Compute the aggregate on the device and discard the rest.

A counter that stores tracks is holding movement records of identifiable individuals, even without names attached, and those records can frequently be linked to a person by other means.

A counter that emits "fourteen people, average dwell four minutes, for the hour to ten" holds nothing sensitive.

Same sensor, same model, entirely different position — which is why this is worth deciding explicitly rather than accepting whatever the product does by default.

Doing it well technically

Overhead cameras count far better than oblique ones: less occlusion, consistent scale, and they capture the tops of heads rather than faces.

Line crossing at a doorway is more reliable than area counting in a crowd.

Crowds are the hard case. Occlusion defeats individual detection, and density estimation is the alternative — an estimate rather than a count, and it should be reported as such.

Bidirectional counting needs the geometry to distinguish direction, which is a placement question.

Validate against a manual count, repeatedly, at different densities. The error at low density tells you nothing about the error at high density.

Where it drifts

Group behaviour: families and pairs walking closely are undercounted.

Trolleys, pushchairs and luggage confuse detection.

Seasonal clothing changes appearance substantially.

Staff walking the same route repeatedly inflate counts unless excluded, and excluding them by identity is exactly what you should not do — better to exclude by zone or by time.

Re-validate quarterly, and after any change to the space.

The re-identification trap

A system that recognises the same person returning is doing identification, whatever it is called.

"Repeat visitor analytics" is identification with a friendlier name, and it needs the analysis in the boundary section rather than this one.

Distinguish clearly: counting how many people entered twice today is aggregate; recognising that this is the same person who came last Tuesday is not.

What to publish

Tell people the space is counted, which is cheap and disproportionately reassuring.

Say what is not collected — no identification, no faces stored, no individual tracks retained — and make it true.

Publish the retention: if only hourly aggregates are kept, say so.

A visible, specific notice reduces objection far more than a general privacy policy, and it is much easier to write when the design is genuinely aggregate.

Validating against a manual count

The check that keeps a counter honest, and it must be done at several densities.

Have a person count the same period independently.

At low density, at typical density, and at peak.

The error at low density predicts nothing about the error at peak, where occlusion dominates.

Report the error by density band, not as one figure.

Repeat seasonally and after any change to the space, because layout and clothing both affect it.

Overhead placement

The configuration that is better for counting and better for privacy simultaneously.

Minimal occlusion, because people do not stand behind each other from above.

Consistent scale across the frame.

Sees the tops of heads rather than faces, which removes most identifying detail at capture.

Simpler geometry for line crossing and direction.

Costs more cameras to cover an area, which is the trade.

Where counting is the application, this is close to a default, and it is rarely what an existing estate provides.