Real-time vs historical people counting, the difference
Real-time people counting answers a question about right now: how many people are inside this minute, how long is the queue at the till, is the venue near its capacity cap. Historical people counting answers a question about the past: how did footfall move week over week, did the campaign lift entries, what is the conversion trend across the quarter. Before either reading is useful, it helps to be precise about what footfall actually counts, because occupancy and visit totals are not the same number. They feel like two different products, and many buyers shop for them as if they were. They are not. They are two readings of the same visitor stream, one taken live and one settled and stored. The practical question is not which technology you need but which decisions you want to make, because the answer usually turns out to be both. This guide separates the two use cases, shows where each one earns its place, names the trade-offs honestly, and explains how people counting can serve both from a single deployment.
Where real-time wins
Real-time data is worth paying for when a decision has to be made inside the same trading day, or even the same minute, and a number that arrives tomorrow is useless. These are the situations where a live feed changes what happens, not just what you know later.
Live capacity and occupancy caps
If a site has a posted occupancy limit, whether for safety, comfort, or a regulatory cap, you need a current count of how many people are inside, not yesterday's total. A live occupancy figure comes from netting entries against exits in the moment: every inward crossing adds one, every outward crossing subtracts one, and the running balance is the people in the building right now. That number can drive a door policy, a one-in-one-out queue, or a simple staff alert when occupancy approaches the cap.
Queue and wait-time alerts
A queue building at a checkout or a service desk is a problem you can only fix while it is happening. A live count of people waiting in a zone can trigger an alert so a manager opens another till or moves staff to the bottleneck before customers abandon the line. The value here is entirely in the timing: the same data delivered as an end-of-day report tells you that you lost sales yesterday, which is interesting but not actionable.
In-day staffing nudges
Most staffing decisions are made days ahead from historical patterns, and that is correct. But the day rarely matches the plan exactly. A live traffic feed lets a duty manager react when an afternoon runs unexpectedly busy or quiet, pulling a colleague from the stockroom to the floor, or sending someone home early when a forecast peak does not arrive. Real-time data turns the rota from a fixed plan into something a manager can correct on the fly.
Member and visitor apps showing how busy it is
Gyms, libraries, leisure centres, and public venues increasingly show a live busyness indicator in their app or on a screen at the door. A member checks how full the gym is before leaving home; a visitor sees that the museum is quiet right now. That feature only works on a live count fed continuously to the app. It is one of the clearest cases where the value of the data is its freshness, because a busyness reading even an hour old would mislead the user.
Where historical wins
For most of the value people counting creates, the live feed is not the point. The decisions that move a business, how to plan, where to invest, whether something worked, are made by reading a settled record over time. That is also where the analysis pays off, once you turn the data into decisions. Historical data wins whenever the question is about a pattern rather than a moment.
- Trend analysis. Footfall this week against last week, this month against last year, this branch against the chain average. Trends only exist across time, so they are inherently a historical reading, and a clean stored series is what makes them trustworthy.
- ROI and planning. Justifying a refit, a new opening hour, or a staffing model needs a baseline and an after, both drawn from the historical record. A live number cannot tell you whether the change paid off; only the before-and-after series can.
- Conversion over time. Conversion is transactions divided by visitors, and it is most useful as a trend: is the store turning more of its traffic into sales this quarter than last. That calculation leans on accumulated entry counts matched to sales data, not on the count at any single instant.
- Benchmarking. Comparing sites, formats, or time periods fairly needs a consistent stored history with the same metric definitions throughout. Benchmarking against a moving live number is meaningless; benchmarking against a settled record is the whole point.
The trade-offs
The reason real-time and historical feel like different products is that they make opposite trade-offs, and understanding the trade-off is what stops a buyer from over-specifying.
The first trade-off is latency. A live feed is only useful if it is genuinely current, so it favours speed of delivery over completeness. A historical series favours the opposite: it can wait for late-arriving data, reconciliation, and corrections, because nobody is acting on it this second. Asking a live feed to also be perfectly settled, or asking a historical series to also be instantaneous, fights the nature of each.
The second trade-off is the accuracy of an instantaneous number versus a settled count. A real-time occupancy figure is a best estimate at a moment, and moments are noisy: a cluster of people crossing a wide entrance at once, a group lingering in the doorway, a re-entry that has not yet been reconciled, all add momentary uncertainty. A settled historical count has had time to resolve those: late data lands, double-reads are reconciled, trajectories are completed. So the same visitor stream can legitimately show a live occupancy of, say, 312 in the moment (an illustrative figure, not measured) and a settled count for that same interval that differs slightly once everything reconciles. Neither is wrong. They are answering different questions at different points in their lifecycle.
The practical takeaway: use the live number for in-the-moment decisions where being roughly right now beats being exactly right later, and use the settled historical number for anything you will plan, report, or defend.
How Ariadne delivers both
The mistake is treating real-time and historical as two systems to buy. With Ariadne they are two outputs of one. Ariadne measures this with Hybrid Fusion, its patented camera-free method. Time-of-Flight depth sensing counts every visitor at the entrances, capturing geometry rather than images, while patented phone signal sensing follows movement through the interior, detecting the signals a phone emits even in airplane mode. The sensor streams both feeds to Ariadne, where Hybrid Fusion combines them into one trajectory per visit and computes counts, dwell, and paths. The streams carry no identifier: no MAC address, no device ID, no biometric data, and no camera is involved. Identifiers are stored only when a visitor explicitly opts in, which keeps the method GDPR-friendly and outside biometric territory.
Because that fusion happens centrally in Ariadne, the central layer is the single place where both readings are produced. Time-of-Flight depth sensing at the entries gives a device-independent body count with direction, so netting inward against outward crossings yields live occupancy. Patented signal sensing across the interior triangulates each phone to roughly 30 cm and resolves individuals and the per-visit trajectory. The central fusion layer emits the live feed as those streams arrive, and it stores the same streams as the settled historical series. One deployment, one set of sensors, one visitor stream, two readings: the live feed for the moment and the historical record for the trend. You are not choosing between real-time and historical counting; you are getting both from the same source, which is also why the two readings stay consistent with each other rather than drifting apart as they would across two separate systems.
From there, the live feed and the historical series can flow into the tools a team already runs. The platform integrations connect counts and occupancy to BI, scheduling, and alerting systems, and the sensor lineup covers the units that feed both readings from a single mounting.
FAQ
Do I need to choose between real-time and historical people counting?
Usually not. They are two readings of the same visitor stream, so a deployment that produces a live feed also produces the historical record. Choose based on the decisions you want to make: live occupancy and queue alerts need real-time, while trend, ROI, and conversion analysis need the settled history, and most operations want both.
How current is a real-time occupancy number?
A live occupancy figure is a best estimate for the current moment, netted from inward and outward crossings as they happen. It favours freshness over perfect reconciliation, so it can differ slightly from the settled count for the same interval once late data and re-entries are resolved. That is expected: the live number is for acting now, the historical number is for reporting later.
Do you need cameras for real-time counting?
No. Ariadne counts with Hybrid Fusion: Time-of-Flight depth sensing plus patented phone signal sensing, never cameras. Time-of-Flight captures geometry rather than images, and signal sensing captures no MAC address by default, so the measurement involves no video, no faces, and no biometric data.
