Why People Counting Reports Differ

A people counting sensor’s interface may show 1,250 entries while the central report shows 1,180. This difference does not always mean that the counting algorithm is wrong. It may originate in data transfer, time alignment or record processing between the sensor and the report.

The data chain in a people counting project typically has four stages: detecting a crossing → creating a periodic device record → transferring the data → processing and reporting it on the platform. Unless each stage is validated separately, “the device works” can be confused with “the report is correct”.

Why can the report show fewer or more counts than the device?

Symptom: The latest hour is missing from the report
Possible explanation: Internet outage or data processing delay
First check: Does the device hold a record, and when was it transferred?
Symptom: An hour shows zero
Possible explanation: The value may be missing, provisional or incorrect rather than a genuine zero
First check: Device event/record history and connection logs
Symptom: The report shows double the count
Possible explanation: The same file or event may have been processed again
First check: Record keys and reprocessing logs
Symptom: Hourly intervals are shifted
Possible explanation: Different time zones, clock synchronisation or interval-end rules
First check: Device/platform clock settings and the data dictionary
Symptom: Daily totals differ
Possible explanation: Missing hours, mixed-up directions or corrections
First check: Hour-by-hour reconciliation between device and platform

Does counting always stop when the internet connection fails?

No. Some sensors continue counting locally without a connection and upload buffered records when connectivity returns. Retention time and data capacity depend on the model, software version and configuration. On some models, restarts, power failures or storage limits may cause data loss. It is therefore unsafe to assume that an offline device will always fill every historical gap.

For example, some manufacturers describe mechanisms for storing data on the device during internet outages and uploading it after reconnection. This capability is not available with the same scope or retention period on every model; the specific product documentation and field testing should be the reference.

What should you check in XML or API records?

Some integrations use XML; others use CSV/JSON or API events. The format alone does not determine reliability. What matters is being able to identify unambiguously which device reported how many crossings, for which interval, in which direction and under which record version.

For example, if a device creates an empty XML file or a provisional zero value for an hour after restarting, the system should not automatically accept it as a final “0 visitors”. The actual hourly record arriving later should be processed appropriately. Likewise, receiving the same file twice must not double the total. Where possible, software should define a deduplication rule based on device, measurement point, time interval, direction and record version.

Zero counts and missing data are not the same

This distinction is one of the most important quality rules for a management report:

Genuine zero: The device has a valid, complete record of “0 crossings” for the relevant hour.
Missing data: There is no validated record for that hour, so no conclusion can be drawn about traffic.
Delayed data: The period has ended, but the record has not yet reached the platform.
Data awaiting correction: An initial record has arrived but may later change or be recalculated.

Filling a missing hour with zero can create the false impression of a decline, particularly in staffing, campaign and store conversion reports.

A reconciliation test between device and platform

For a practical check, select one sensor and a sample day. Export the device’s hourly entry/exit records and place the platform’s data for the same period and direction alongside them. Align time zones and interval definitions. For each differing row, ask whether a device record exists, whether there is a transfer record, whether it was processed and whether it was resent. Being able to trace correction history is as important as being able to correct the data.

In multi-store deployments, these checks should be built into central reporting design from the outset. The Video Intelligence Platform page introduces the approach to centralised data and analysis; the availability of any specific error alert or reprocessing function must be confirmed for the individual project.

Conclusion

Reliable people counting reports require data continuity and traceability as well as accurate counts. CS Otomasyon can help compare device records, transfer methods and reporting results over the same time period to establish whether a problem lies in the sensor, network or data processing layer.