In-store customer tracking: where the system breaks down
In-store customer tracking seems like a predictable task as long as the system runs on a single camera and recordings. On a real sales floor, counting accuracy drops, and the cause is more often not the model but the geometry of the space and the nature of the flow.
Occlusions in the frame are the main source of errors. Shoppers walk in pairs and groups, one person blocks the one walking ahead, the detector loses the object for a few frames and brings it back with a new identifier. As a result, the visitor count is inflated, and dwell time and route are distorted.
Blind spots on the sales floor make the picture worse. At the entrance area the camera sees the tops of heads, at the checkout the queue closes up and blocks neighbouring lanes, a person steps into a doorway or behind a shelving unit and comes back. Double counting at the junction of zones turns one shopper into two.
Glare from display windows, sun in the doorway, lighting swings between the floor and refrigeration equipment reduce detector confidence: shadows and reflections are recognised as objects.
The same problem comes from a change of angle when a camera is repositioned without recalculating the zones.
The result: the report looks plausible, but conversion, checkout load and peak hours are calculated from incorrect data. We break down how this is addressed at the stage of designing coverage zones and tracking logic.
The measurable effect of video analytics on the sales floor
The effect of video analytics shows up not in the report but in the fact that traffic data starts to reconcile with revenue and the staff schedule. Below are three areas of the sales floor where changes become visible fastest.
Traffic reconciles with revenue
In-store customer tracking delivers not a "number of people who came in" but a funnel: entrance, area of interest, shelf or fitting room, checkout. Visitor conversion is calculated for every hour of operation, not from one-off measurements at peak hours.
The discrepancy between visitor numbers and receipts is visible the same day: if traffic grew and the checkout did not respond, the question is already about merchandising and shift schedules, not about analytics.
Checkout queues are managed by threshold
The system tracks waiting time and the number of people in the checkout zone, not just the fact that a queue exists. A threshold at peak hours triggers a signal to open an extra checkout before visitors start walking away.
The share of shoppers who abandon a purchase because of the wait stops being an unknown quantity and becomes a manageable sales-floor metric.
Double counting as a separate class of failures
Frames from neighbouring cameras are linked into a single trajectory by time and path, and entry and exit zones are configured without overlaps. Double counting disappears along with manual measurements: traffic data stays within a few percent of checkout figures. Images are not stored — processing complies with GDPR requirements.
Data capture options: comparing approaches
Traffic data can be captured in several ways, and they do not replace one another: some answer the question "how many people came in", others "what they did inside the store".
The choice is determined by the task and the layout, not by ease of deployment, so below are real alternatives with their limitations.
| Option | When it fits | Limitations |
|---|---|---|
| Counter on the entrance line | You need traffic and conversion by hour and day; one or two entrances, a complex-shaped floor | Gives only the number at the entrance: no routes, no zone analytics, counts groups as one flow |
| Trajectory tracking across the whole floor | You need paths, time at the shelf, heat zones, queues | Sensitive to occlusions and angle changes; requires camera calibration and zone marking |
| Sensors at the entrance area | Simple layout, robustness to low light and draughts matters | Counts entry events but does not distinguish groups and does not show behaviour inside the floor |
| Selective observation by staff | One-off hypothesis checks, a small store | Manual labour, little data, the observer effect changes shopper behaviour |
Combined setup
In practice the circuits are combined: a counter on the entrance line serves as the traffic reference, trajectory tracking provides zone analytics, and sensors act as a backup at the entrance area in poor light.
Reconciling two independent sources makes it possible to see discrepancies within a few percent and catch calibration failures before they reach the reports. Such a setup costs less than full camera coverage of the floor while matching it in data depth.
How we implement the system: stages of engineering work
Implementing customer tracking is not camera installation but a sequence of work where each step builds on the result of the previous one. A zone scheme agreed before models are configured saves weeks: it defines what counts as an event and what counts as background.
Implementation stages
- Survey of the floor and cameras — layout, mounting height, blind spots, occlusion by shelving, lighting throughout the day. Result: a coverage map and a list of areas that will have to be covered by an additional camera point.
- Marking out zones and points of interest — entrance area, checkout line, fitting rooms, promo zones. For each we define rules: boundary crossing, dwell time, entry and exit. This determines which metrics the system calculates.
- Tuning models for the specific flow — shopper density, trolleys, staff uniforms, movement speed. We exclude staff from the count with a separate rule; otherwise footfall is inflated.
- Camera calibration and validation on recordings — we tie the perspective to the floor plan, then run the system on archived footage from different days of the week. We compare manual recounts with machine counts and eliminate the discrepancy before handover.
- Integration with the accounting system — we pass events via export or through a software interface, match visits with receipts, and calculate conversion by zone. We align the point reference lists so reports reconcile with accounting.
- Staff training and handover — the floor administrator understands how to read the reports and what to do if the camera connection is lost. We hand over documentation on zones and rules so the system can be developed further.
After handover we provide support: we adjust zones when equipment is rearranged and retrain models on new product ranges — without rebuilding the project from scratch.
Zone schemes, access policies and regulations
After implementation, the client is left not with a presentation but with a working documentation set: their own team uses it to operate the system, and a new contractor uses it to take over. We fix the contents in an acceptance report and work through it at sign-off like a checklist.
- Layout and zone scheme — floor plans with camera positions, boundaries of the entrance area, checkout line, sales floor and areas excluded from filming.
- Configuration description — which flows are analysed, trigger thresholds, operating schedule, behaviour when a camera is switched off or the connection is lost.
- User roles — system administrator, analyst, store manager and a contractor service account with a limited validity period.
- Data access policies — where recordings are stored, retention period, anonymisation rules, grounds for exporting a video clip.
- Staff instructions — actions in the event of an incident, escalation procedure, prohibition on moving cameras without approval from the responsible person.
- Maintenance schedule — calibration frequency, checking viewing angles and cleaning optics, updating reference features after rearrangement.
- Report export procedure — generation schedule, formats, the responsible employee and reconciliation of discrepancies with related systems.
We validate the set in practice: an employee who was not involved in the implementation adds a new zone and exports a report following the instructions. If they can do it without calling us, the documentation is workable, not merely formal.
Case study: how the system stopped losing visitors
A store with dense traffic: four entrance-exit points, a narrow checkout area and up to 120 people on the floor at the same time.
Manual measurement by receipts and selective observations diverged from the system by 12–18% — operational reporting did not reconcile, and merchandising decisions were made by eye.
What exactly we fixed
We re-marked the zones: entrance-exit lanes, checkout line, fitting rooms — each with its own geometry rather than a single box per frame. We recalculated perspective calibration for each camera — queue "tails" stopped falling into the floor zone.
We rewrote the track merging logic: matching by movement vector and silhouette features instead of pure frame-by-frame intersection, so a track survives when a shopper stops at a shelving unit or is briefly occluded by someone else.
Video processing was moved to Nvidia locally, in the store itself: frames do not go to external services, and counting does not depend on the network link.
Metrics before and after
- Discrepancy against a control manual count: 15% → 4%, and up to 2% for the checkout zone.
- Track breaks in dense traffic: from 8–10 trajectories per twenty people to one per sixty.
- Share of "blind" minutes when a camera restarts: 6–8 minutes → under thirty seconds.
- The conversion report is ready by opening time for the previous day — with no manual proofreading.
Over a month the system holds up at peak hours: in peak intervals the discrepancy stays within 4%, and daily reports reconcile with selective recounts.
How trajectory tracking differs from line counting
Line counting answers the question "how many", while trajectory tracking answers "how each one moved". A line records crossings of a virtual boundary: the event fires once and has no history.
Object tracking works differently — a person gets an identifier that lives as long as they are in frame, and all their events are collected into a single route.
A line is cheaper in computational terms and almost independent of the floor layout: you place it at the entrance and get a stable flow of entries and exits even with occlusions and low light.
The limitation is different — it does not distinguish who passed straight through from who stayed on the floor, and a visitor returning across the same boundary is counted again. Zones, time at a display and the path to the checkout are invisible to it.
Trajectories provide zone footfall, dwell time, routes, the share of visitors who reach the checkout and queue behaviour.
The price is a demanding approach to tracking: occlusion by a trolley, turning away, re-entry and lighting changes break the track or merge two different people.
This is addressed by matching external features, filtering by floor geometry and configuring track split and merge thresholds.
The choice of approach is determined by the task. If you only need entrance traffic and a "walked past — came in" estimate, a line is enough. If you need a heat map, time at the shelf and conversion by department, you cannot do without object tracking.
In practice the methods are combined: the line at the entrance filters out street traffic and serves as the reference point, while trajectories inside the floor describe behaviour.
The crossing event is tied to a track, so entrance figures and in-store analytics reconcile, and any discrepancy between them immediately shows where data was lost.
Technical doubts worth resolving before the start
It is better to work through awkward questions before the start, not once the system is already counting traffic.
Below are the things usually checked on the client side: robustness at peak hours, sensitivity to light, compatibility with existing optics and how video recordings are handled.
What happens in dense traffic when people occlude one another?
The tracker follows a person along a trajectory and, during occlusions, relies on motion prediction and silhouette features.
At peak hours some tracks merge, so we count entries and exits by the line and separately measure the merge rate: this shows the real error on recordings from your store.
How sensitive is the system to changes in lighting?
Backlight at the entrance, evening light, lamps being switched on — the image changes more than it seems.
We tune thresholds using several days' worth of recordings and update the reference background; if the entrance is overexposed, a second angle or illumination in the invisible spectrum helps.
Will this work with the cameras already installed?
Most often yes: we collect events from the optics you already have.
We look at the angle, mounting height and how distinguishable silhouettes are in real traffic — a test connection of one or two cameras shows the share of confident tracks and immediately answers whether the current optics are sufficient.
How do you distinguish staff from shoppers, and what do you do with recordings?
We identify staff by a combination of features: zone and route, shift times, clothing. Exclusion rules are configured explicitly and validated on a control day so that staff do not end up in customer metrics.
We do not accumulate video: only anonymised events go to storage, while frames for debugging live for a limited period with restricted access and automatic deletion.
Let's discuss the task and come back with an estimate and a work plan
For the estimate to be concrete rather than a rough guess, we just need initial inputs about your site — we will clarify the rest ourselves on a call. The more specific the input, the more precise the scope of work and timelines in the implementation plan.
- A sales floor plan or photos of the zones: entrance, fitting rooms, checkout line, promo displays.
- Several frames from each camera — to see the angle, occlusions and lighting at peak hours.
- How many streams need to run simultaneously and which zones we consider key for tracking.
- Which metrics are needed in the report: entrance-to-purchase conversion, queues, time in zone, heat maps.
- Privacy requirements: whether video is stored, whether frames are anonymised, where the data must reside.
- What already exists in the infrastructure: cameras, recorder, the accounting system the figures need to be linked to.
- Who on your side accepts the result and by what criteria we consider the test run successful.
With this set we come back with a project estimate, a camera layout scheme and a stage-by-stage work plan — from scene marking and model training to delivering metrics in a report for the manager. Describe the task in two or three paragraphs, and we will continue concretely.
