DetectCustomer

Overview

DetectCustomer counts people in retail environments that span multiple locations. Video from store cameras is processed on site, and each location reports structured count events to a shared backend. Operators watch all stores from one dashboard. Most of the engineering sits around the model: stream handling, event quality, unattended operation.

Problem

Retail operators want consistent footfall information across every store. Existing store cameras already expose continuous RTSP Video feeds, but raw detections are not counts. A detection runs per frame, so one person in view produces many detections for one visit. Shipping video off site is not an option: bandwidth is limited, and the useful output is a small stream of events, not continuous footage. Networks drop, cameras restart, and processing has to keep working.

Solution

Each location runs a local service that pulls the RTSP Video feed from its cameras. Detection runs on incoming frames, and Tracking maintains the identity of each person across frames so an individual is counted once when crossing a defined boundary in the scene. Event Processing turns those crossings into count events with a timestamp and a direction, and drops spurious detections that never become coherent tracks. Events, not video, leave the store. A Central API accepts events from every location and exposes them to the Dashboard, the surface for Central Monitoring.

Architecture

Camera
  ↓
Video Stream
  ↓
Detection
  ↓
Tracking
  ↓
Event Processing
  ↓
Local Service
  ↓
Central API
  ↓
Dashboard

Engineering Challenges

Counting without double counting

The unit of output is a visit, not a detection. Tracking has to hold onto people through occlusion, crowding near entrances, and brief exits from the frame, while rejecting noise that would inflate it. The line-crossing logic and track lifecycle are tuned for doorways and queue areas.

Streaming that survives the store

RTSP Video sources stall, restart, and change state without warning. The ingestion layer is built to notice a broken stream and recover on its own, because nobody is watching the processing host.

Site autonomy and central visibility

Local processing continues when the uplink is unavailable: events are produced on site and forwarded to the Central API when connectivity returns, so Central Monitoring reflects what happened, not what arrived in time. Deployment is designed for repeated rollout across locations, with each site failing independently of the others.

Technology

Object Detection identifies people in each frame of the incoming video. Tracking links those detections over time and gives the counting logic a stable identity. RTSP Video is the ingestion layer that connects to existing store cameras. Event Processing sits between tracks and the network, shaping raw motion into count events. Central Monitoring is the aggregation and visualization side, and Deployment covers running the pipeline across locations.

Results

The deployed system ingests live camera video at each retail location, counts people locally, and publishes count events to the central service without shipping footage off site. Operators monitor multiple stores from one dashboard and compare locations on the same basis, since counting logic is shared. Stores keep producing events through network interruptions, and the monitoring view reflects those events once connectivity returns. Because video handling, detection, tracking, and event shaping are separate stages, each can be improved and rolled out independently.