搜狗竞价推广：设备之间完成咨询的路径怎样减少重复计算
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9a658c8d006f.html
📄
搜狗竞价推广：设备之间完成咨询的路径怎样减少重复计算
结论先说：减少重复计算的关键，不是把统计代码再装一遍，而是先确认“咨询完成”这件事由哪一端负责记录。如果手机端和电脑端各自记一次、客服系统再记一次，同一通咨询就会在报表里变成多条。可行的做法是只保留一个判定点，其余环节只做传递，不做二次判定。
两种条件下该选哪条路径
先分两种情况，判断依据是咨询是否在页面内完成。
- 情况一：咨询在页面内完成（表单提交、页面内对话框发出消息）。此时把“完成”判定放在页面端，由页面在提交成功后触发一次记录，再把同一个标识传给后端。电脑端和手机端共用同一套判定逻辑，只是触发载体不同。
- 情况二：咨询跳出页面完成（跳转到聊天工具、拨打电话、加好友后沟通）。此时页面端无法确认对方是否真的回应，判定点必须后移到客服侧，页面只负责把来源标识带过去。
两种情况的取舍标准只有一条：谁最先确知“这次咨询真实发生”，判定权就交给谁。两边都想判定，就是重复计算的来源。
先找那个被漏掉的传递环节
常规排查通常停在“代码装没装、事件有没有触发”。如果这一步已经确认没问题，问题多半出在标识没有跨设备、跨系统传下去。可以按下面的顺序验证。
- 在手机端和电脑端各发起一次测试咨询，记录页面生成的标识值。
- 在客服侧或后端日志里查找同一个标识值，确认它是否完整到达。
- 如果标识在中途丢失，检查跳转链接、表单隐藏字段、会话保持方式这三处，通常断点在其中之一。
实际动作是：把标识补进跳转参数或隐藏字段，然后重新走一遍测试。如果后端能读到同一个标识，说明重复计算的根因是判定点重复；如果仍然读不到，说明是传递断链，此时改判定点没有意义，要先修传递。
判定点收敛后的具体改法
确认传递通畅后，只保留一个判定点，其余位置降级为“记录来源，不记录完成”。
- 页面端：只上报“发起咨询”这一动作，不上报“咨询完成”。
- 客服侧：以真实对话或通话建立为完成信号，并回写同一个标识。
- 报表侧：以标识去重，而不是以设备或会话去重。
这样做的结果是，同一用户在手机和电脑各发起一次但只完成一次咨询时，报表里只出现一条完成记录，而发起次数仍保留两条。下一步的优化判断就建立在“完成数”上，而不是被放大的总数上。
一个假设例子说明去重口径
假设某天手机端上报完成 10 次、电脑端上报完成 6 次、客服侧记录完成 12 次。如果三处都算完成，总数是 28；如果以客服侧为准并按标识去重，总数接近 12。这个差距不代表哪一方“算错了”，而是判定口径不同。选择以客服侧为准的前提是：客服侧能稳定拿到标识，且完成信号确实由人工或系统真实触发。若不满足这个前提，应退回页面端判定，并接受它无法覆盖跳出页面咨询的局限。
什么情况下不该强行统一
有两种例外。第一，手机端和电脑端用的是完全独立的业务系统，标识无法打通，此时强行统一会引入错误匹配，更稳妥的做法是分别统计、在汇总层明确标注口径。第二，咨询完成依赖线下确认（例如回电后才算有效），页面端和客服侧都无法即时判定，此时判定点应放在线下确认环节，前两处只记录来源。
判断是否属于例外，看一个信号：补上标识后，完成数是否出现无法解释的跳变。如果跳变来自匹配错误而非真实去重，说明当前条件还不适合统一判定点，应先解决标识唯一性问题，再谈减少重复计算。
