最近在做一个客流统计类项目时遇到一个比较典型的问题系统上线前几周数据看起来很正常。但运行几个月后发现趋势开始不对劲客流持续增长高峰越来越夸张多入口数据差异变大最开始以为是设备误检后来排查发现问题根本不在采集而在数据治理。尤其是长期数据沉淀没有做好。这篇文章主要聊几个实际项目里比较容易踩坑的问题。1. 为什么客流统计的数据会“越跑越偏”很多系统初版逻辑很简单if detect_person: count 1逻辑没问题。但问题在于人不是一次性经过的。真实场景里进入门口 停顿 转身 再次经过可能会触发多次。结果1个人 → 3次统计短期影响不明显。长期会让趋势整体失真。2. 一个最常见的坑重复计数项目里最容易被忽略的就是时间重复例如10:01 进入 10:02 再次经过其实还是同一个访问行为。但如果没有时间窗口count count 2空间重复尤其多入口Gate_A Gate_B Gate_C同一用户被不同设备识别。最后变成visitor_01 visitor_02 visitor_03但实际same user3. 一个更合理的思路Session 化后来改了统计逻辑。从直接统计 Event改成Event → Session → VisitorEvent原始检测事件{ track_id: T1001, timestamp: 1748323012, direction: in }Session一次完整访问例如进入时间09:01 离开时间09:16生成{ session_id:S1001, duration:900 }Visitor最终唯一访客。这样才能做去重停留时长回访分析转化统计4. 时间窗口去重实际项目里一个比较简单的方法比如300 秒窗口逻辑if now-last_seen 300: ignore()意思5分钟内重复进入不重复统计。简单但有效。5. 数据表怎么拆后来我们拆成三张表。原始事件表traffic_event字段event_id track_id device_id timestamp direction会话表visitor_session字段visitor_id enter_time leave_time duration聚合表daily_traffic_stats做日报 趋势分析 同比避免每次扫全量。6. 一个容易忽略的问题员工数据污染这个在商场和门店特别明显。例如营业员来回进出 安保巡检 补货人员如果直接统计员工会抬高客流基线。后来做法是建立staff whitelist命中后exclude()效果会稳定很多。7. 最后的经验客流统计系统本质不是数人数而是做长期一致的数据系统。真正难的地方通常不是识别而是去重 Session 化 规则统一 历史兼容否则时间越长数据误差越明显。
