WiFi客流统计系统实战：从探针选型到随机MAC去重

刚到展馆现场主办方的运营总监把我拉到中控室指着大屏说“我不要那种一天结束才出来的总人数我想知道现在这个时刻每个馆里到底有多少人、观众都在哪一片区域停留、哪几个展台人气最旺。”那是我第一次认真做展会客流统计的客流统计系统也是我第一次意识到会展场景和零售门店的客流统计根本是两码事。后来项目做完走的时候他在门口跟我说了一句话“这三天数据比我们过去用人工估算的准确多了。”今天这篇就围绕这套WiFi客流统计系统把技术选型、系统架构、部署踩坑和数据处理细节完整梳理一遍给准备在展会、场馆、园区这类开放场景落地客流统计的朋友做个参考。1. 为什么展会现场的客流统计最后选了WiFi方案1.1 展会场景和零售门店的本质区别商场、连锁店做客流统计通常是在门口装红外对射或摄像头因为顾客进出动线相对固定单向门框宽度也就一两米设备覆盖范围好控制。但展会是完全不同的物理空间一个展馆动辄几千上万平米出入口数量多、宽度大馆内展位密集观众不会按固定路线走。更麻烦的是展会有明显的潮汐特征——开幕式前后人流爆发午休时段骤减撤展时有大量工作人员和物流车辆混入。这种场景下任何“固定点位的计数设备”都很难给出全局准确的数据。我当时的需求其实很明确主办方要的不是“门禁计数”而是在场人数、停留时长、区域分布、时段趋势这四类指标。这就决定了不能只看入口必须覆盖馆内全区域。1.2 几种客流统计技术路线的横向对比在定方案前我认真把市面上几种客流统计方式都过了一遍这里直接给对比结果。技术路线能否识别重复是否需用户配合能否做轨迹隐私敏感度部署成本展会场合适配度红外对射不能否不能低很低适合门宽固定、单通道场景展会基本不合适摄像头视觉部分能否能单摄像头内高含人脸信息高受遮挡、逆光、密集遮挡影响大布点数量要求高手机信令/基站能否能粗粒度高极高需运营商合作精度不足且拿不到实时数据Beacon/iBeacon能必须开蓝牙且有App能中中观众不一定会开蓝牙或装AppWiFi探针能否手机默认开WiFi即可能多点联动中低只收MAC低覆盖半径大、无需配合、适合开阔空间WiFi探针的原理简单说就是手机只要开启了WiFi即使没有连接任何热点也会周期性地向周围发送“探测请求帧”Probe Request相当于在问“附近有没有WiFi网络”。这个帧里携带设备的MAC地址虽然是随机化的后面会详说以及信号强度RSSI。我们在展馆里布设探针设备被动接收这些帧就能感知到附近有设备“存在”。整个过程用户无感知不需要连接WiFi更不需要安装App。选型的时候还有一个重要考量成本。当时报了摄像头方案的预算客户看到价格后明显犹豫了。WiFi探针方案倒是很轻松——单台探针设备成本远低于一台带客流统计功能的摄像头而且布点灵活一个标准展位区域放一台就能覆盖大片空间整个展馆几十台设备就能跑起来。1.3 也不要神化WiFi方案它有一个物理天花板必须说清楚一个工程层面的限制一颗WiFi探针在同一时刻只能监听一个信道。2.4GHz频段有13个信道探针如果要监听全部信道就得不停地轮询切换每个信道只能分到一小段时间窗口。而手机发Probe Request本身也是间歇性的有时几秒发一次有时几十秒才发一次。两者叠加单颗探针在单位时间内一定会漏掉一部分帧。所以业内对WiFi客流统计的定位是趋势准确、相对量准确绝对量是估算值。做项目时不能向客户承诺“100%精确到每一个人”但要能通过合理的部署密度和算法补偿把误差控制在可接受范围。我们后面在现场校准环节做到了和人工计数误差在5%~8%左右这个量级在大型展会上已经完全够用了。2. WiFi客流统计的三层系统拆解从空中的探测帧到展馆大屏数字2.1 采集端探针硬件形态与监听参数探针的硬件并不神秘。一套典型的探针设备就是一个嵌入式主机我用的工控机/开发板都能跑加一块支持监听模式的WiFi网卡。关键是把网卡切到monitor模式监听模式此时网卡不连接任何网络只接收空中所有802.11管理帧。可以把它想象成一条只听不说的无线电频道。采集端要关心的核心参数有三个信道轮询策略默认轮询2.4GHz全部13个信道。但我在项目里发现展馆现场2.4GHz频段异常拥堵WiFi AP、蓝牙、无线麦克风混在一起干扰很大。后来采购设备时专门选了支持2.4GHz和5GHz双频同时监听的型号5GHz频段虽然手机Probe发送频率低一些但胜在信道干净能有效补充2.4GHz被干扰时的丢帧。扫描周期设备每隔1~3秒扫描一次周边环境信号。这个间隔再长就会严重影响短线移动人群的捕捉。RSSI门限信号强度用dBm表示越接近0信号越强。我通常设置-75dBm以内才算有效信号。信号更弱的设备可能离得太远或者隔了几堵墙统计进来反而干扰判断。原始数据记录长这样简化的字段示意{ timestamp: 2025-09-18 10:30:12, probe_id: P-EXPO-03, mac: 8a:3c:1b:5e:00:4f, rssi: -58, channel: 6, ssid: ChinaExpo_5G }那个ssid字段后面会提到是关键的技术机会点先埋个伏笔。2.2 数据管道事件流的上报、缓冲与存储探针采集端只负责产生和上报数据真正的计算都在后端。一个现场可能几十台探针同时在工作数据是每秒都在产生的流式数据。我按“上报→缓冲→清洗→存储→计算”的链路搭了一套管道探针设备通过有线或4G网络把原始事件实时上报到中心服务器。局域网内用MQTT或UDP跨网段用HTTP接口。考虑到展馆网络经常不稳定上报协议必须支持本地缓存、断点续传。中心服务收到事件后先落缓冲队列我用Redis做短期缓冲后端消费进程逐条清洗。清洗要做的事包括过滤掉广播MAC和组播MAC这类地址不是真实设备、丢弃明显异常的RSSI值、对同一探针重复上报的相同事件做幂等去重。清洗后的事件分两条路走一条写入明细存储用来做深度分析和轨迹回溯另一条进入实时计算模块维护在场设备的滑动窗口状态。数据量其实没有想象中那么大。我做过一次粗算展会峰值5000人同时在馆每台手机平均每分钟发3~5个Probe Request算下来每分钟原始事件约1.5万~2.5万条一天8小时大概700万~1200万条。这个量级用MySQL存明细也能扛但我后来还是把明细放进了Elasticsearch因为要支持按MAC、按探针、按时间范围的快速组合查询ES的索引能力比关系库强太多。报表汇总结果则落到MySQL供大屏和后台查询。2.3 应用层实时看板、趋势曲线与停留时长应用层直接面对最终用户。我交付的看板包含几个核心视图实时在场人数当前这一刻全馆总人数以及分展馆人数。大屏每30秒刷新一次观众一眼就能看到“现在人多不多”。分时段趋势曲线以小时为单位展示全天客流走势可以回放某一天哪个时段是高峰。展台热度排行按探针点位统计周边区域设备数量圈出人气最高的展台。平均停留时长依据设备在探针覆盖范围内“出现→消失在→再出现”的时间差统计观众在展馆内的平均停留时长时间。这里有个实现细节判断“离开”不能靠一次收不到帧就判定因为手机Probe发送是间歇性的。我设置了一个失联超时窗口默认10分钟。超过10分钟没再出现才算关闭这个设备ID的“在场会话”以此避免一杯水的时间就误判离场。3. 最难的不是装设备而是“同一台手机怎么认”随机MAC与去重策略3.1 随机MAC地址WiFi客流统计的最大天敌如果还是十年前这个系统会简单很多每台手机的WiFi网卡出厂时写死一个全球唯一的MAC地址探针收到MacA一天后又收到MacA就能断定同一台设备来过。可现在主流手机系统在发送Probe Request时普遍使用随机MAC地址。同一台手机可能每次亮屏、每次系统刷新网络时都会换一个新的随机地址间隔可能只有几分钟。这意味着什么如果按“一个MAC地址等于一台设备”的简单逻辑去重同一台手机在一天展会上可能被算成几十台甚至上百台设备统计结果彻底失真。这就是当年WiFi探针技术被很多人唱衰的直接原因——不是原理错了是识别手段失效了。3.2 实际有效的识别策略不追求精确对应做概率匹配我没有试图恢复“MAC唯一识别设备”这个目标而是和团队一起做了多特征融合的概率匹配。核心思路是把“物理设备”拆成几个可观测的指纹维度随机MAC的局部特征很多手机虽然会随机化MAC但随机算法有规律可循。比如某些厂商只在本地管理位和单播位上做改动厂商段落OUI前24位保持不变。这可以帮我们区分设备品牌甚至识别出哪些MAC是“伪随机”。携带的SSID偏好Probe Request帧里有个字段叫SSID有些手机会携带它之前连接过的WiFi网络名称。这是一个非常强的辅助指纹——同一个手机关联过一次某个SSID后这个信息会保留在设备里之后它发的探测请求可能多次携带同一个SSID。我在实际数据里看到过某区域有两个不同MAC连续携带着“ZhangSan_HomeWiFi”这个SSID出现间隔很短、信号强度变化曲线又一致基本可以判定是同一台设备。信号强度RSSI时间序列设备在空间里移动时探针收到的信号强度会有连续变化轨迹。把每个MAC的RSSI随时间变化画成曲线如果两个MAC的曲线形状高度相似且时间轴重合它们大概率是同一台设备。多探针协同出现模式一个人从A展台走到B展台会依次被A点探针、中间探针、B点探针捕获。如果两个不同MAC在这三颗探针上的出现顺序和时间差完全一致也能辅助判断是同一人。这些特征单独拿出来都有噪声但组合成一个评分模型后识别可靠性大幅提升。比如当“OUI相同 携带SSID相同 RSSI曲线相似度过80%以上”三个条件同时满足可以以较高置信度把两个MAC归属为同一台设备。3.3 落地去重滑动窗口、空间网格与动态权重具体实现上我设计了一套分层次去重流程第一层单探针时间窗口去重。每台探针本地维护一个滑动窗口窗口内出现频率极高、RSSI波动很小的MAC比如连续10次探测在同一位置判定为长时间静止设备归并为一个虚拟会话。第二层跨探针空间网格去重。把展馆空间划成5米×5米的虚拟网格同一MAC若在极短时间内比如5秒内出现在相邻两颗探针的上报列表里只保留RSSI较强的一次避免中间状态的重复计数。第三层指纹归并。按上面提到的多特征融合模型周期性地对不同MAC做相似度匹配输出“合并候选人”列表交给离线任务做最终归并。对于实在无法归并的随机化设备我在最终统计时给它们打了动态权重。怎么理解我先通过校准阶段的对照组估算出一个“随机化导致的多计比例”比如30%然后对无法归并的设备数做一个整体折扣使汇总数字向真实值收敛。这个办法不完美但非常实用校准后的误差能稳定在可接受范围。3.4 “每时每客”到底怎么交付回到这篇的标题“WiFi客流每时每客”。有人说这是营销话术我反而觉得它描述了一个真实可达的产品目标时间粒度做到“每时”空间粒度做到“每客所在的区域”。系统不精确知道“你是谁”但能高置信度地知道“现在有多少人在展馆、这些人分布在什么位置、停留了多久”。当把“识别设备”的目标降级为“统计在场量级判断移动趋势”之后随机MAC的破坏力就被大大稀释了。这也是任何WiFi客流产品能做“分钟级在场人数”而非“准点打卡式人数”的技术基础。4. 展馆部署实测点位、高度、信道与离线兜底4.1 点位选择两个要命的教训第一次做部署时我按“均匀分布”的直觉在展馆里平板铺了一批探针结果数据出来完全不对相邻展台区域人数明显重复两个展台中间的空地人数高得离谱。后来总结了两个教训。教训一探针间距不能太密。一颗探针的覆盖半径实际能达到30~50米如果两颗探针间距小于30米它们的覆盖范围会严重重叠同一个人会被两颗探针同时、以相近的信号强度捕获跨探针去重又很难精准合并。所以后来布点策略改成了“主通道出入口覆盖 展区分区代表点覆盖”点间距至少30米宁可少布也不密布。教训二点位覆盖要跟着人流动线走而不是跟着展位布局走。后来我把探针主要放在这几类位置出入口通道用于入馆总人数统计、主通道交叉口用于主流量监测、有独立围挡的特装展位用于展台人气统计、餐饮休息区出入口用于停留时长分析。不再追求“每个展台都有一台”而是用点位之间的联动关系推算区域流量。4.2 安装高度、天线方向与信号衰减部署参数直接决定数据质量。我整理了常用的安装规范直接给表参数推荐值原因安装高度2.5~3米太高信号覆盖太广、区分度低太低被观众身体阻挡严重天线朝向垂直向下或斜45度保证覆盖展位周边区域避免穿楼板干扰楼上与金属结构距离大于1米金属桁架、铁皮围挡会反射/吸收信号产生多径干扰点位间距不小于30米降低同一设备被多点重复捕获的概率供电链路PoE或有线供电展会现场电力波动大避免用质量差的充电头顺便提一个很多人会忽略的问题人体本身会吸收2.4GHz信号。当展会人潮密集时大量观众身体会遮挡和吸收无线信号导致探针收到的整体RSSI普遍下降。所以高峰期统计出的设备数往往偏低而这个“偏低”在不同时段、不同人流量下还不是线性关系。为了补偿我在数据处理里引入了一个“人流密度补偿系数”根据时段和该区域历史人流密度动态调整信号阈值。这个系数不是拍脑袋定的是通过人工计数校准反推出来的。4.3 现场干扰与信道轮询的妥协展会现场的电磁环境非常恶劣几十上百个品牌方的WiFi AP、蓝牙音箱、无线麦克风、甚至无线讲解耳机全挤在2.4GHz频段。探针在轮询信道时遇到拥堵的信道会明显丢帧。我的处理方式有几个优先选用支持双频段同时监听的设备5GHz频段作为主要兜底。调整信道停留时间默认均匀轮询改为动态调度对设备量较多的信道通常是1、6、11三个主用信道多停留一些时间。尽量把探针设备本身的联网通信从2.4GHz无线转移到有线或5GHz频段避免“自己人干扰自己人”。4.4 网络异常时的本地缓存与补传机制展馆的网络条件是最不可控的变量。现场人多、墙体多、基站在峰值时也经常挤爆探针和服务器之间的链路随时可能中断。我遇到过最极端的情况开展第一天上午展馆内网大范围瘫痪整批探针离线了将近一个小时。如果没有兜底机制上午的数据就永久丢失了。解决方案是给每个探针增加本地双层缓存事件先写入本地队列同时定期落盘到文件网络恢复后按时间戳顺序补传。补传时要额外处理一个问题服务端必须做幂等同一事件不能因为TCP重试被重复入库两次。数据量上单台探针本地存储按“每天50万事件每条约300字节”估算一天的原始数据撑死15MB本地放一周完全没压力。部署时还要注意时间同步。探针设备没有RTC电池时断电重启后时间会回到出厂值导致补传的数据时间戳错乱。我后来在所有探针上强制开启NTP同步并做了一层“服务端时间修正”当探针上报的时间与服务端时间偏差超过2分钟时直接以服务端时间为准。5. 客流数字出来之后怎么用主办方、参展商和场馆的三种视角5.1 主办方视角实时人流预警与分时段运营决策客流数据对主办方最大的价值不是“事后统计”而是即时运营调度。开展期间主办方最怕两件事入口堵塞、展馆内局部拥挤。我用客流系统做了个“实时拥挤度预警”模块把每个展馆的当前在场人数和该展馆的安全承载人数做对比超过阈值就在中控大屏弹预警通知现场工作人员去疏导。数据另一个用处是分时段运营决策。展会第二天结束后我发现某个参展商集中的馆在下午两点到四点有明显的客流低谷和主办方一沟通才知道那个时段安排了多场同期论坛把观众引流走了。第三天主舞台的暖场时间调整后该馆低峰期明显改善。这种“用数据调整活动编排”的案例比单纯一张汇总报表有价值得多。5.2 参展商视角停留时长比“路过人数”更值钱参展商在展会上是有经营目标的——收集销售线索、洽谈意向客户。所以他们对“展台人气”的定义和主办方完全不同。主办方关心的是“有多少人经过这个区域”展商关心的是“有多少人在我展台前停下并逗留”。我在展台热度分析里做了个“有效停留”口径设备在展台探针覆盖范围内连续出现超过2分钟才视为一次有效到访。这个指标对展商极其受用。有个做工业设备的展商展位摆了两台大型样机第一天光看进来的人很多但他们拿到的有效线索很少。用我们的数据一分析发现大部分观众在展台前停留不超过1分钟说明展品陈列和讲解流程有问题。第二天他们在展台前增加了演示环节平均停留时长从1分20秒涨到3分40秒有效线索量直接翻倍。5.3 场馆运营视角餐饮区、休息区与下一届的展位定价馆方和运营方同样能从数据里发现商机。餐饮休息区的客流高峰和展区客流高峰往往并不同步通过数据可以合理安排餐饮服务人员的排班和备餐量。区域热力数据积累几届之后还有一个隐藏价值为下一届展会展位定价提供依据。哪些位置人气旺、哪些位置客流少数据说话比口头议价更有说服力。5.4 交付时最容易踩的坑别拿首日数据当准确数据这点我必须专门提醒系统上线第一天跑出的数据往往会明显偏离预期这不是系统坏了而是数据还没“热起来”。原因很有趣开展首日很多参展商的工作人员、搭建商、保洁人员在布展阶段就已经在场这些“非观众”设备的MAC会被系统当成正常客流的一部分。而且首日设备的指纹库还是空的随机MAC归并模型还没有足够多的样本做校准。我现在的标准流程是展前布展期先跑一到两天数据建立基础的设备指纹库和信号环境基线开展后前24小时的数据只做参考不做最终决策依据第二天开始数据才逐步进入可信区间。项目交付以后我每次复盘都会过一遍从探头选型到数据校准的完整链路这里给出几个典型的现场问题排查经验现象可能原因排查/处理办法某个点位数据全天为0探针网卡未切到监听模式、供电异常、天线松动远程检查进程状态、网卡模式、系统日志数据整体虚高有固定设备展商电脑/路由器/电视持续发送信号将连续多日、全天候在线、RSSI无波动的MAC加入静态名单相邻两个点位数据同时暴涨两台探针间距太近、覆盖重叠严重调整点位或减少其中一台的监听功率断网恢复后数据重复补传逻辑未做幂等服务端按事件唯一ID去重早间客流高峰比人工计数低人员密集导致信号衰减、手机Probe间隔变长调高人流密度补偿系数、适当放宽RSSI阈值回到标题那句“展会客流统计的客流统计系统WiFi客流每时每客”。我做了几个类似项目之后最大的体会是这类系统的成败不是看算法模型有没有多先进而是看你对现场物理环境、设备约束、数据特征有没有足够的敬畏。随机MAC是不可逆的信号衰减是物理定律展会现场的网络永远不会稳定——把这些变量都当成常态去设计系统才能从“demo能跑”变成“现场能扛”。最后再分享一个实操小技巧正式开展前一定要做一次“布展期基线采集”让探针在空场环境下跑一晚上。第二天看数据时你会看到全场探针的噪声底数和固定设备清单这两样东西在开展后数据清洗时非常值钱。很多项目上线翻车不是因为设备不行是因为没有留出这个“建立环境基线”的步骤。