Ask three vendors for the accuracy of their people counting camera and you may get 95%, 98% and 99%. Those numbers are probably not measuring the same thing. None of the vendors is necessarily being dishonest — the figures are simply undefined, and an undefined figure cannot be compared, budgeted against, or used to settle a dispute after installation.
Accuracy is a property of a deployment, not a product. It depends on where the camera is mounted, what the scene looks like, and how the number is calculated. The only accuracy figure that means anything to you is the one you measure on your site, with your traffic, using a method you defined in advance.
This article covers what the different accuracy metrics mean, what changes them in the real world, and — the part most projects skip — how to run a defensible site acceptance test.
What "accuracy" actually means
Four different measurements routinely get called "accuracy." Before you buy, decide which one you need.
Count accuracy against ground truth (per interval)
The device reports that N people entered during an interval; humans counted M. This is the operational metric for footfall reporting.
- count error % = (device count − ground truth) / ground truth × 100
- accuracy % = 100 − |count error %|
A device that reports 1,020 when 1,000 people entered has a +2% error, or 98% accuracy, for that interval. Note the sign. Overcounting and undercounting have different consequences: a consistent +5% bias cancels out in week-over-week trends but distorts any absolute conversion-rate calculation, while random error adds noise on both sides. Ask whether the quoted error is signed (bias) or absolute.
Detection precision and recall (event level)
At the level of individual detections:
- Recall — of all real people present, what fraction did the system detect?
- Precision — of all detections the system made, what fraction were real people?
Low recall produces undercounting. Low precision produces false positives and overcounting. A single "accuracy" percentage hides which failure mode you actually have, and the two demand different fixes.
Count error percentage — and why averages hide peaks
Vendors often report an average error across a long period. Averages hide peaks. A system with a 3% mean error that spikes to 20% during the morning rush is acceptable for annual reports and useless for queue management or peak staffing. Always ask for the error distribution across intervals, not just the mean.
Directional and tracking accuracy
For entry/exit and dwell analysis you also need:
- direction accuracy — of the crossings detected, how many were assigned the correct direction;
- tracking quality — identity switches and track fragmentation, which matter when you analyse paths and dwell time rather than just totals.
The six variables that decide real-world accuracy
1. Mounting height and angle
Too high and people become small and heavily foreshortened; too low and the first person occludes those behind. A steep, top-down view reduces overlap but compresses the body. Vendors publish a working range for a reason: staying inside it is the cheapest accuracy improvement available on any project.
2. Field of view versus entrance geometry
A single wide door, a double door, a vestibule, a mall atrium — each creates a different crossing pattern. An angle that works for a narrow door may miss the edges of a wide opening or entire side entries. Covering the whole threshold, including its edges, matters more than pixel count.
3. Lighting and night behaviour
Backlit glass doors in the afternoon, near-darkness at closing, mixed artificial light and daylight, and infrared illumination at night all change what the model sees. Ask how the device performs with IR enabled, and test during the hours your reporting actually depends on.
4. Occlusion and density
Counting one person at a time is easy. Counting a group that passes together, where one body blocks another, is hard — and it is exactly what happens at peak. Density handling is where depth-based 3D systems separate most clearly from 2D detection.
5. Algorithm class and model version
Detection models differ in how they cope with crowding, silhouettes and motion blur. Firmware updates can change accuracy; usually for the better, but occasionally they change behaviour in ways that affect your numbers. Record the firmware or model version at acceptance so you know precisely what you signed off.
6. Calibration and configuration
Detection lines, zones, staff-exclusion areas, minimum object size and tracking parameters all shape the result. A correct installation with a careless line placement will underperform a cheaper camera configured carefully. Re-calibration after a refit is part of the maintenance plan, not an optional extra.
Environmental factors belong in this list too: reflective floors, mirrored columns, glass facades, escalator handrails and direct sunlight can all generate phantom detections.
Reading vendor claims without being cynical
You do not have to distrust every number. You have to know what it describes. Useful questions:
- On what scenes, densities and lighting conditions was it measured?
- Over what duration and with what sample size?
- Is that the average, the median, or the worst case?
- Is the error signed (systematic bias) or absolute?
- Is it measured per camera or for the whole system?
- Which firmware version was running?
A vendor who can answer these clearly is more trustworthy than one who simply quotes a bigger number. You can see how we frame the 2D-versus-3D trade-off in more depth on our blog if you want the technical background before the test.
Site acceptance testing: a method integrators can run
This is the part that protects you commercially. Define it before installation so that nobody argues about methodology afterwards.
Step 1 — Agree acceptance criteria in writing
State the metric (count error %, direction accuracy), the thresholds, the scenes to be tested, the time of day and the duration. "Accurate" is not a criterion; "count error within X% across each measured interval for this entrance" is.
Step 2 — Establish ground truth
Choose one of:
- manual counting with a clicker for lower-traffic entrances, with two operators cross-checking each other;
- recorded video replay, counted independently by someone who does not see the device's figures, to avoid confirmation bias;
- a known-count event — a controlled walk-through of a known number of people — for scenario testing.
Step 3 — Cover representative conditions
Test across the conditions that define your operation: peak and off-peak, weekday and weekend, daytime and night, backlit afternoons, and rain if the entrance is exposed.
Step 4 — Run the scenario battery
Controlled walk-throughs, each repeated several times:
- single person, walking each direction;
- small group (2–4) passing together;
- dense group (5+) passing together;
- simultaneous two-way traffic;
- someone carrying a suitcase or pushing a trolley or stroller;
- a person stopping exactly on the threshold, or turning back;
- fast walkers;
- a wheelchair or mobility aid;
- children;
- staff passing in and out repeatedly.
Record pass/fail per scenario and note the direction of any error.
Step 5 — Compute the numbers properly
For each interval:
- count error % = (device − ground truth) / ground truth × 100
- accuracy % = 100 − |count error %|
- MAPE = mean of |count error %| across all intervals
- direction accuracy % = correct-direction crossings / total crossings × 100
Report the mean, the worst case and the spread — never a single aggregate number.
Step 6 — Respect sample size
A two-hour test with 40 people cannot support a claim about peak-hour behaviour. Run long enough to accumulate meaningful crossing counts, and treat small-sample results as indicative only. The arithmetic here is trivial; the sampling is not. If the result will decide a contract, have someone with statistics training sanity-check the design.
Step 7 — Document and sign off
Use a table: scenario | expected | measured | error % | pass/fail | notes. Store it together with the firmware version, mounting positions and configuration files, so any future dispute has a baseline to measure against.
Common error sources and how to reduce them
- Double counting at the line. Reposition or angle the detection line so a person crosses it once, and verify with direction logic enabled.
- Group counted as one. Depth-based 3D detection generally handles this better; otherwise adjust mounting distance to separate bodies, or accept a known undercount at peak.
- Reflections and shadows. Re-aim the camera, tighten zones, or choose a position with no mirrored surfaces in view.
- Glass doors and shopfronts. Reflections can register as people. Zone masking and careful line placement reduce the effect.
- Staff traffic. Use staff-exclusion zones so employee movement does not inflate footfall.
- Re-entry. Set a re-identification window so a person who leaves and returns quickly is not counted twice.
- Clock drift. Sync devices over NTP; otherwise POS correlation breaks even when the counting itself is correct.
Setting realistic expectations
No camera counts perfectly in every condition, and per-interval error compounds in ways that make daily totals look worse than minute-level series. Use footfall data for trends, ratios and comparisons — conversion rate, staffing patterns, campaign lift — rather than as audit-grade headcount. That framing keeps the system genuinely useful without over-promising to the people who will eventually question the numbers.
FAQ
What accuracy should I expect from an AI people counting camera? It depends on the scene and the metric. In a clean, single-door, correctly mounted installation, count accuracy is typically high. In dense, wide or poorly lit entrances it drops, and peak intervals are always the weakest.
Is 99% accuracy realistic? In ideal conditions with light traffic, yes — and it says almost nothing about peak performance. Ask what the worst measured interval looked like, not just the average.
Are 2D and 3D cameras equally accurate? No. Depth-based 3D (stereo binocular) systems handle crowding, occlusion and group passage more reliably, which is why they are common in malls and wide entrances. 2D AI cameras are economical and accurate in lighter, simpler scenes.
How long should an acceptance test run? Long enough to include representative days and peak periods — typically several days to a few weeks, plus controlled scenario tests. A single quiet afternoon proves nothing.
Do I need ground-truth video? It is the most defensible method and doubles as a tuning aid. If storing video is not acceptable for privacy reasons, use manual counting with two operators instead.
Next step
Write your acceptance criteria before you buy, then test on site. Explore the camera classes in our product center, see how counting is deployed in different retail formats in our solutions, and contact us if you want the mounting and configuration guidance that gets a deployment into its accuracy sweet spot from day one.