如果目标是让手机、平板、电脑等设备在完成咨询动作时少做重复计算,前提是先把“算过什么”从设备本地移到可共享的标记层:同一访客在不同设备上触发同一咨询动作时,只认一个完成标记,其余设备只读状态、不重算归因和去重逻辑。这个结论成立的条件是你能拿到跨设备标识或至少一个可传递的匿名键;如果只能拿到单设备数据,强行合并会把两个真实访客误判成一个,结论随即失效。
咨询路径上的重复计算,多数不是发生在广告点击那一刻,而是发生在“点击之后到咨询完成”这段。常见有三层:设备本地去重、服务端归因、咨询表单或对话工具自身的重复提交判断。三层各自维护一套计数,设备一换,前两层就可能把同一个人的同一动作重新算一遍。
能区分原因的证据是:同一时间窗内,广告后台的点击去重结果与咨询工具的完成记录对不上,而服务端日志显示同一匿名键被多个设备各写了一次完成事件。若只是某台设备时间不准或缓存未清,通常表现为单设备重复,而不是跨设备成对出现。
一个可执行的最小动作是:给咨询完成事件加一个可跨设备传递的匿名键,写入共享存储,写入前先读一次是否已存在。伪代码层面近似于:
if (!seen(key)) { mark(key); countOnce(); }
这个动作的结果是,后到的设备只读到“已完成”,不再触发归因重算和计数。它影响下一步的地方在于:只有共享层可读,你才能把“设备数”和“访客数”分开看;如果共享层不可写,这个动作无法落地,应退回单设备口径,不要假装做了跨设备去重。
缺少跨设备标识或后台权限时,仍可执行的最小动作是:在咨询入口记录一个由设备指纹之外的显式参数(例如从落地页带过来的活动参数)生成的临时键,只用于同一会话内的短时去重。它能减少同一设备短时间内的重复提交,但不能推出跨设备的真实访客数,也不能据此判断某个渠道的咨询成本。
需要说明的是,请求量、抓取量或某项统计归零,并不能单独证明去重处理正确。它也可能是参数丢失、埋点未触发或权限变更导致的漏记,这几种解释需要分别用日志和参数回传核对。
假设某 sem公司 的咨询路径允许用户在未登录状态下先提交手机号,再在另一台设备上凭同一手机号继续。如果系统只按设备写入完成标记,而不校验手机号是否已存在,那么两台设备会各算一次完成。此时“共享层去重”这个结论失效,因为共享键选错了对象——应该用手机号这类业务标识,而不是设备层标识。
这个反例说明:去重键必须对应你真正想数的对象。数“咨询动作”就用动作标识,数“人”就用可稳定关联到人的标识,两者混用会同时产生多算和漏算。
下一步先做一件事:列出当前咨询路径上所有会写“完成”的位置,标出各自使用的键。然后只保留一个共享键作为写入依据,其余位置改为只读。判断是否有效的依据是,同一匿名键在多个设备上只产生一条完成记录,且该记录能对应到一次真实咨询。
如果做不到这一点,就明确当前口径只覆盖单设备,并在解读咨询数据时保留这个限制,不把单设备去重结果当作跨设备结论使用。