涨粉战役最怕只看关注数、看不到「扫了码却没进菜单」的流失。公众号营销把每一次外链扫码落成触达行，菜单成功核验后再回写，运营可以按批次看漏斗，而不是凭感觉调文案。
为什么统计只认触达表
Redis 凭证有 TTL，过期即删，不适合做报表。正确做法是：外链扫码同步插入触达记录；菜单核验成功后再把对应行标成已核验。码明细上的「是否已扫码 / 是否已核验」便于筛选单码，但一码多次扫会被压扁，漏斗应以触达行为准。
建议关注的四口径
- 扫码触达次数：外链命中公众号营销批次并成功落库的次数；
- 待核验量：已触达但尚未在菜单完成核验；
- 已核验量：菜单命中凭证并完成验真主链路；
- 核验转化率：已核验 / 扫码触达，衡量「扫码 → 关注/点菜单」效率。
怎么用来调运营
转化率低：优先检查菜单链接是否指向正确 /verify、二维码是否可扫、提示文案是否说清「点菜单防伪验真」。待核验堆积且临近活动结束：可缩短从开箱到关注的路径，或在包装副文案强调公众号名称。已核验高但领奖低：问题在权益玩法，不在公众号入口。
和其它玩法指标并列看
公众号营销解决入口与私域；现金红包、积分、券解决激励。复盘时应并列查看，避免把「没领奖」误判成「菜单难用」。相关动销讨论见 扫码现金红包怎么做才不超发。
能看见漏斗，才能决定是改菜单、改文案，还是改奖品——否则公众号营销只会沦为又一次「感觉不错」的活动。
常见问题
关注数能不能代替核验转化？
不能。关注未必来自本次扫码；触达→核验才对应本次开箱链路。
需要定时任务汇总吗？
不需要。触达表即时可查，Redis 不作统计源。
关停玩法后历史数据还在吗？
触达与核验记录保留，便于活动复盘；新扫码不再走该链路。
