Why a visitor counting system lies at entrance areas
The most common complaint about an entrance area sounds like this: the POS registers one number of receipts, while the visitor counting system shows another, and the discrepancy fluctuates from day to day.
The problem stops being an abstraction when conversion and revenue per guest are calculated from these numbers, and the discrepancy with receipts during peak hours reaches tens of percent.
The first source of errors is a dense flow of people.
At the entrance, two or three people walk closely together, the detector sees one merged silhouette and one trajectory instead of three; a child in a stroller or in arms passes below the reliable recognition zone and is not counted at all.
Errors add up asymmetrically: the denser the flow, the greater the undercount, so the numbers lie exactly where the data is needed most.
The second source is double counting at the exit. The exit area is often wider than the entrance, the same line is crossed twice, and a guest who goes out to smoke and returns produces another entry.
The direction of crossing is determined from movement history: if the trajectory breaks — occlusion, a sharp change in lighting, a turn at the frame — the old track is closed and a new record is created in its place.
The third cause is triggering thresholds and zone geometry chosen "by eye" for one door: at the second point the configuration does not transfer, and errors at the entrance area grow.
As a result, metrics stop reconciling between points, and the numbers cannot be relied on when planning shifts and evaluating marketing.
Next we break down how this is resolved — from zone calibration to the logic of matching movements.
What changes after implementation: measurable effects
We measure the effect of a counting system not by the fact that cameras were installed, but by the metrics that operations live by.
We record them at acceptance: discrepancy with the POS, time spent on manual reconciliations, share of lost tracks during occlusions, and load profile by hour.
Discrepancy with the POS stops being a mystery
The difference between the number of entries and registered receipts remains, but it stops being a black box: you can see in which hours it occurs and at which entrance.
Detection and tracking of people between frames on the current YOLO branch keep the count in a dense flow, so the discrepancy with the POS is reduced severalfold — part of the difference is cut off by the very setup of counting, when all entrances are under observation, including service entrances and the ramp.
Manual recounts leave the weekly cycle
Reconciliation used to mean an export, walking the sales floor with a manual counter, and consolidating tables: half a day of one role every week.
After implementation, data flows continuously, and the discrepancy is visible in the report the next morning, so manual recounting remains a rare data-quality check — by trigger or once a month.
Separately, a class of failures during occlusions goes away: a dense group or a person behind a cart is no longer counted twice, and the track is not lost during brief occlusion.
A load profile by hour also appears — you can see when the queue at the entrance grows and staff should be redistributed before it becomes noticeable at the POS.
Comparison of approaches: cameras, sensors, and tags
The choice of method is determined by what data is needed at the output: the fact of entry or the movement trajectory inside the sales floor. Below are four options that are actually chosen between when launching a visitor counting system.
| Option | When it fits | Limitations |
|---|---|---|
| Machine vision cameras | Conversion by zone, queues, repeat visits, separating staff from guests | Requires a compute node next to the camera, calibration, and correct viewing angles |
| Infrared entrance sensors | One or two passages, need total flow and peak hours | Count beam crossings, not people: group entry and bags cause double counting |
| Tag-based counting | Linking to a specific customer: dwell time, returns | Works only on those who agree to wear a tag, low flow coverage |
| Manual counting | One-off measurements, checking automation at a small site | Depends on the observer and does not provide a 24/7 picture |
When a sensor is enough and when a camera is needed
If reporting only needs "how many entered during the day," an infrared sensor is enough: it is cheaper to maintain and does not require zone configuration.
As soon as questions arise about the share of people reaching the POS, queue length, or guest return, machine vision cameras are needed — they distinguish direction and build a route.
Where each option loses accuracy
Sensors get confused on group passage: two people close together produce one pulse, and a bag produces an extra one. Cameras make errors in backlight and when silhouettes overlap, tags — when people refuse to wear them.
These losses are removed by calibration, a dedicated counting zone, and reconciliation with POS data.
How we implement counting: from point audit to handover
Implementation of counting begins not with purchasing cameras, but with analyzing the physics of flow at each point. We look at entrances and exits, movement directions, occlusions, blind zones, and how staff appear in the frame. This is exactly what determines equipment placement and which metrics you will get at the output.
Point audit and zone scheme
We describe each point in a zone scheme: what falls into the field of view, where flows intersect, and how to separate a visitor from an employee. The scheme becomes the basis for installation and a reason to immediately reject places where counting will consistently make errors.
- Point audit — walking the site, recording entrances, occlusions, installation height, and angle.
- Zone scheme — marking viewing zones, "entered/exited" logic, separating visitor and shift flows.
- Installation and connection — setup, routing communication channels, checking round-the-clock access to data.
- Calibration for flow — tuning to actual density: peak hours and quiet periods require different thresholds.
Control measurements before handover
- Control measurements — parallel manual recounting at intervals of different density and reconciliation with the system.
- Discrepancy consolidation — a report by hourly slices, returning to calibration where the discrepancy exceeds the agreed threshold.
- Handover and training — access, instructions for the shift, review of typical situations and what is visible in reports.
We do not consider the work complete until the system readings reconcile with manual recounting at control intervals. After that, a regulation remains: who checks exports, how failures are recorded, and when recalibration is needed if the layout or flow changes.
Handover package: schemes, policies, regulations
What remains at the site after handover of a visitor counting system is not only a working loop but also a handover package. It is designed for your engineer: so that the contractor is not the only one who understands why the entrance counter counts the way it does.
Documentation your engineer reads
- Point placement scheme — floor plan with camera positions, installation height and angle, and viewing boundaries. With it, replacing a device reproduces the same scene geometry instead of being selected anew.
- Zone profiles — which areas are considered entrance, transit, and checkout line, where service passages run, and how employees are excluded from the flow.
- Recount rules — how fragments of the same visitor are merged, what is considered a repeat entry, and which events are discarded.
- Access policies — roles and visibility levels: daily aggregates for analytics, raw events for incident investigation, retention periods.
- Settings passport — the parameters with which the system passed acceptance, so there is something to compare against after changes.
- Control measurement log — manual recounts on reference intervals and the discrepancy with automation for each of them.
- Maintenance regulation — frequency of calibration, optics cleaning, and zone reconciliation, and the procedure when the discrepancy exceeds tolerance.
Update and access rights regulation
Updates are rolled out in a separate window with preliminary testing on archival recording, and rollback is done by restoring the previous settings profile. Fewer people have rights to change zones and thresholds than to view reports, and every change is recorded in a log. This way, the visitor counting system remains manageable by your team, not a black box.
Case study: how we eliminated the discrepancy with the POS
The site is a retail location with four entrance areas and a separate service entrance. Before the project, flow was counted by turnstile triggers, and during peak hours — manually, by an administrator.
Match rate with the POS stayed at 78%, dropping to 66% on Saturday: some people entered without being counted, and some produced double triggers.
Measurements before and after on the same flow
We compared two weeks on unchanged traffic — the same Saturday load, the same entrance areas, the same operating schedule. We counted three things: match rate with receipts, share of false triggers, and spread between entrance areas.
- Match rate with the POS: was 78% on normal days and 66% at peak, became 98% and 96%.
- False triggers — repeat entry, employees, glare at glass — decreased from 9% to 1%.
- Spread between entrance areas: previously the busiest one produced 35% error, now all converge within 2–3%.
Reconciliation with receipts from 1C was set up so that the discrepancy is visible the same day, not at the end of the month.
Rebuilding the zones took three days at the site and another week to fine-tune scenarios: we moved capture points, separated entrance and exit zones, and added a rule for the service door.
At peak, when up to 40 people per minute pass through the entrance, counting proceeds without losses in the crowd — previously, it was precisely at these intervals that the main error accumulated.
What to do if some points are already equipped with cameras?
Yes — if some points are already covered by cameras from a previous contractor, there is no need to replace the entire fleet.
First, an inventory: vendor and model, whether the camera outputs a stream externally, whether admin rights exist, at what height it is mounted, and what actually falls into the frame. We assign each point a status — reuse as is, reuse with addition, replacement.
Equipment reuse works when the camera looks along the passage and sees a person at full height, not the tops of heads, supports night mode, and outputs a continuous stream rather than clips triggered by motion detection.
At such points, installation and cable routes remain untouched — only the processing layer changes. The gain is not in hardware but in launch time: no new approvals, wall chasing, or point downtime are needed.
Replacing points is needed where the physics of the frame does not allow correct counting: backlight from a display window, occlusion by shelving, mounting that is too high, a narrow viewing angle, or a single-file flow where people walk one after another.
We change the angle or add a second camera, and leave the previous one for security and overview recording. A separate case is cameras that record only on motion: they output a stream, but with gaps, so for counting we switch them to continuous mode.
Then everything is brought to a unified layer: streams from own and third-party cameras compatible by ONVIF profile are normalized to a single form, entry and exit lines are marked at each point, and deduplication is configured at zone junctions — a person who passed under two cameras is not counted twice.
Points enter the general report with an accuracy passport: you can see where it is higher and where it is lower due to old optics, and this is not hidden behind a single final number.
This way, partial coverage turns into a point-by-point plan: what we keep, what we supplement, what we replace, and in what sequence — without stopping site operations.
Technical concerns: accuracy, lighting, integrations
Five concerns that we usually resolve before the start: dense flow at the entrance, changing lighting and shadows, communication loss, operation without image storage, and integration with what is already installed at the site. Below is how each is addressed at the architecture level, not with promises.
What happens with a dense flow — people walking closely together?
Each person is tracked by a separate track, and counting is based on zone crossing, not frames. In a group, tracks are not merged, and a repeat entry does not double the number — the discrepancy is visible in the peak-hour report and remains within a few percent.
Will changing lighting, shadows, and backlight throw off the count?
Exposure and balance are fixed for a specific scene, and shadows are cut off by zone geometry, not by brightness. At a street entrance, the trigger threshold is raised, so the transition "street — vestibule — sales floor" does not produce false triggers.
What happens if communication is lost?
The node at the site accumulates events locally and sends them after the channel is restored, with duplicates filtered by event label. Numbers for downtime hours are preserved, and the outage itself is visible in the report — it can be reconciled with other data.
Can visitors be counted without storing images?
Yes. The frame is processed locally, and only an event goes out: time, direction, zone. Video is not recorded or exported, so personal data does not leave the site — this removes most questions about its processing and storage.
Does the system integrate with what is already installed at the site?
Existing cameras, the recorder, and the accounting system remain in place. Events are retrieved via an open interface, and numbers are provided in your familiar format; schedules, zones, and retention periods are configured according to the site's regulations.
Let's discuss the task: what to send before the conversation
Counting accuracy is determined not by the algorithm but by the quality of the input data: how cameras are positioned, where the flow is blocked by shelves or columns, and how the site changes its operating mode during the day.
That is why we start discussing a task not with model selection but with gathering inputs — this way the estimate and work plan rely on the real geometry of the site, not on averaged assumptions.
- Floor plan with marked sales, entrance, exit, and service passage zones — from it we calculate viewing occlusions and the number of counting points.
- List of entrance and exit points with the direction of people's movement, including open terraces, emergency exits, and passages between floors.
- Diagram of already installed cameras: where they are located, where they point, what falls into the field of view, and whether network and power are nearby.
- Site operating mode and peak intervals — frame processing frequency and data retention depth depend on it.
- Example export from the accounting system: format, frequency, linkage to POS or zones. From it, you can see how to match flow and conversion.
- Reporting requirements: which slices are needed, at what frequency, who views them and in what form — a dashboard, table, or scheduled export.
- Contact person at the site for access to the server room, installation, and checking the observation scene.
We return with an estimate and work plan: the order of stages from survey to handover, the composition of counting points and zones, requirements for access and network, and a scheme for checking accuracy on real flow. Describe the task and attach what you have — we will clarify the rest during the conversation.
