Cách hoạt động thực tế của phân tích đếm người và lượng người chiếm chỗ

Most people-counting projects go wrong before any sensor is chosen, because "how many people" is four different measurements and teams specify the wrong one. Entries over a day, people present right now, how long each stayed, and how many are waiting in a queue require different sensing, different placement and different accuracy. A system that counts entries accurately can report occupancy badly, and a system tuned for occupancy may miss short entries entirely.

This guide separates those measurements, compares the sensing methods honestly (WiFi and BLE, infrared beams, time-of-flight, thermal, stereo and camera-based vision) and covers both the products worth buying and how teams build camera-based counting themselves with Ultralytics YOLO models.

Four measurements, not one#

Occupancy is the one that surprises teams. Deriving it from entries minus exits means every counting error compounds: a small directional error, repeated across every movement through the door, leaves the count meaningfully wrong by closing time. Systems that need reliable occupancy either sense the whole area directly or reset the count on a known-empty condition, typically overnight.

Sensing methods compared#

The genuine trade-off is context versus simplicity. A ToF sensor over a door does one job extremely well and tells you nothing else. Camera-based vision gives you direction, zones, dwell, queues and object classes from the same stream, and takes on lighting, occlusion and compute problems in exchange.

For a single entrance where only entries matter, overhead ToF is usually the better engineering answer and the easier privacy conversation. For multi-zone analysis, queues, or counting that must combine with other detections, vision is the method that scales to the requirement.

What actually degrades a count#

Vendor accuracy figures are quoted under conditions that rarely resemble a real deployment. The factors that move real-world accuracy:

• Groups and abreast walking. Two people shoulder to shoulder through a wide door are the classic undercount. Doorway width relative to sensor coverage matters more than the sensor's rated accuracy.
• Occlusion. Trolleys, umbrellas, luggage, tall displays and dense crowd s hide people from any method that needs a clear view.
• Camera angle. Overhead is far more accurate than oblique for counting, because oblique views stack people behind each other. A repurposed security camera at a shallow angle is the most common reason a vision count disappoints.
• Lighting. Backlit entrances at sunrise and sunset are the hardest case for vision, as are reflective floors and glass doors.
• Loitering at the threshold. Someone standing in a doorway talking can generate repeated crossings without a persistence rule.
• Who counts as a visitor. Staff, cleaners, deliveries and passers-through are usually the largest single source of disagreement between a system and a manual audit, and it is a definition problem rather than a sensing one.
• Multi-camera double counting. Overlapping fields of view count the same person twice unless zones are defined to be mutually exclusive or tracks are handed off between cameras.

Whatever you deploy, validate against a manual count on your worst conditions: busiest hour, worst lighting, widest entrance. Accuracy under those conditions is the number that matters.

Products worth shortlisting if you are buying#

If the goal is footfall reporting, occupancy dashboards or retail conversion analytics, these are mature products and buying is usually the right call. Ultralytics is not an alternative to them.

Xovis. Overhead stereo-vision sensors with strong accuracy for entrance counting, queue management and zone analytics, widely deployed in airports and large retail. Best fit for environments where counting accuracy is operationally critical. Trade-off: sensor hardware per coverage area, so wide or numerous entrances add cost.

V-Count. People counting and analytics aimed squarely at retail, with a platform layer covering footfall, occupancy and conversion reporting. Best fit for multi-site retail estates wanting reporting out of the box. Trade-off: retail-shaped analytics translate less naturally to industrial or campus settings.

Density. Workplace-focused occupancy measurement using its own anonymous depth sensors, positioned around real-estate and space-utilization decisions. Best fit for corporate portfolios optimizing office space. Trade-off: built for workplace questions rather than retail conversion.

FootfallCam. Counting hardware plus analytics with broad retail coverage and a wide range of sensor options. Best fit for retailers wanting hardware and reporting from one supplier. Trade-off: range of models requires care in specification.

RetailNext. In-store analytics platform where counting feeds a broader merchandising and shopper-behaviour product. Best fit for retailers whose question is store performance, not just traffic. Trade-off: platform scope well beyond counting, priced accordingly.

Sensormatic ShopperTrak. Long-established retail traffic counting and benchmarking with substantial market data behind it. Best fit for retailers valuing comparative benchmarks. Trade-off: enterprise retail orientation.

Axis. Counting applications running on Axis cameras, useful where an Axis estate already exists and additional hardware is unwelcome. Best fit for organizations standardized on Axis. Trade-off: tied to that camera ecosystem.

Cisco Spaces. Occupancy and location insight derived from existing network infrastructure. Best fit for large campuses wanting occupancy without new sensors. Trade-off: device-based sensing, with the precision limits that implies.

Building camera-based counting#

Counting is one of the more approachable vision builds, which is why it is a common first project. It is worth building when counting is a component of a larger system (a machine, a robot, a site platform, a product you ship) when the count must combine with detections no product offers, or when footage cannot leave the premises.

The pipeline is well-established.

Detect people per frame. Ultralytics YOLO models (YOLOv8, YOLO11 and YOLO26) handle person detection, and the same model can detect other classes you care about in the same pass: vehicles, trolleys, forklifts.

Track across frames. Counting requires knowing that the person in frame 200 is the person from frame 199. Ultralytics models support tracking, which assigns persistent identity-free IDs across a sequence, and the quality of tracking through occlusion determines the quality of the count far more than detection accuracy does.

Define the counting geometry. A line for directional entry and exit counting, or a polygon for occupancy in a region. Direction comes from which side of the line a track crosses from. Where multiple cameras cover adjacent areas, define zones to be mutually exclusive so a person is never counted twice.

Add persistence and debouncing. Require a track to be established for N frames before it counts, and prevent a single loiterer at a threshold from generating repeated crossings. This layer, not the model, is where most accuracy improvement comes from.

Choose the deployment target early. Continuous inference over several streams is a real capacity question. Most counting does not need every frame: set the frame rate from how fast someone can cross the line, not from what the camera can deliver. Ultralytics models export to formats including ONNX and TensorRT for edge hardware next to the camera, which also keeps video local.

Train on your own footage. A general model handles people well; your specific entrance at sunrise, with glass doors and a reflective floor, is what decides production accuracy. Ultralytics Platform can annotate that footage with SAM-based Smart Annotation and train on it in the same workflow.

Validate against manual counts at the busiest hour and worst lighting, and re-validate after any camera move.

If counting goes into a commercial product or proprietary system, note that Ultralytics YOLO models are offered under AGPL-3.0 and such deployments generally require an Ultralytics Enterprise licence, which also covers private deployment. Settle that before a pilot becomes a shipped feature.

Privacy: counting should not identify anyone#

Counting is one of the few camera applications that can be made genuinely privacy-preserving by design, and doing so removes most objections before they are raised.

No method described here needs to identify individuals. Entries, occupancy, dwell and queue length all work on anonymous detections and identity-free tracks that exist only while a person is in frame. Ultralytics does not offer its models for facial recognition, and building identification into a counting system adds substantial legal exposure while improving none of these measurements.

Design choices that keep it that way:

• Process locally and keep only counts. If the output is a number per interval, retain the number and discard the frames. - Do not persist track IDs beyond the field of view. A track that ends at the frame edge should end. Re-identifying the same person across cameras or across visits is a materially different system with materially different obligations. - Aggregate over intervals rather than logging individual events, where the use case allows. - Post notice, and where the setting is a workplace, consult worker representatives: a requirement in much of the EU, and good practice everywhere. - Prefer inherently anonymous sensing where only a count is needed. If ToF or thermal answers the question, it is the easier conversation. - Document purpose per camera, which makes a data-protection assessment straightforward.

Note that "no cameras" does not automatically mean "more private". WiFi and BLE counting works from device identifiers, which are personal data under GDPR in many circumstances, while a thermal sensor producing only a count is not processing personal data at all. Judge the method by what it retains, not by whether it involves a lens.