百度广告查询，设备之间完成咨询的路径怎样减少重复计算
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /80e3a0eaa664.html
📄
百度广告查询，设备之间完成咨询的路径怎样减少重复计算
核心做法是：把“用户是谁”和“这次咨询算不算新”这两件事，从设备端上移到服务端统一判定。设备端只负责把可用的标识和事件发出去，服务端按同一套规则去重、归因、落库。只要设备之间对“同一个人、同一次咨询”的判断不一致，重复计算就会在规模化后集中暴露。
先分清两种条件下的不同选择
是否值得改造成服务端统一判定，取决于你的业务对“咨询”的定义是否稳定。
- 条件一：咨询动作单一且可强标识。比如只在落地页提交表单，且提交后必须经过服务端写入。此时应把去重键放在服务端，设备端传原始标识，服务端用手机号、表单提交ID或登录态生成唯一键。设备端不自行判断“是否新增”。
- 条件二：咨询动作多入口且弱标识。比如电话、在线会话、微信跳转并存，部分入口拿不到稳定标识。此时不能强行在设备端合并，而应按入口分别记录原始事件，再由服务端做“同一时间窗内同手机号/同会话ID”的合并，合并结果只作为线索归并，不直接改写原始计数。
判断依据不是设备数量，而是“同一次咨询能否在服务端被唯一描述”。能，就上移判定；不能，就先保留原始事件，只做有限合并。
重复计算通常来自三处，而不是设备本身
规模化后出现例外，常见原因不是手机和电脑各算一次，而是下面三类差异叠加。
- 标识口径不同。设备A用设备ID，设备B用登录账号，服务端又用手机号，三者对“同一个人”的覆盖范围不一样。
- 时间窗不同。设备端按会话结束算一次，服务端按天算一次，跨天咨询就会被算两次。
- 状态回传顺序不同。设备先记为“已咨询”，服务端稍后判定为重复并标记无效，如果报表直接读设备计数，就会把无效项也算进去。
可区分证据是：同一批咨询在原始事件表里的条数，与去重后线索表的条数是否一致。若不一致，先查去重键，再查时间窗，最后查状态回传。不要只看总咨询量归零或下降就认定处理正确，那也可能是采集失败、页面未触发或服务端写入中断造成的。
一个可执行动作：先统一事件写入，再谈去重
实际动作是：让所有设备端只上报原始事件，由服务端统一写入一张事件表，并给每条事件打上来源设备、入口类型、发生时间和可用标识。
这个动作的结果会直接影响下一步：如果事件表里同一手机号在短时间内出现多条不同设备来源，说明去重键应选手机号或登录态；如果同一设备反复出现相同事件，说明问题在触发层，不该靠服务端去重掩盖。只有先看清原始事件，才能决定去重放在哪一层。
假设一个短例子：某天10:00手机端提交表单，10:02电脑端又提交同一手机号。若服务端按“手机号+24小时”去重，线索表记1条，事件表记2条。若报表直接读事件表，就会显示2条咨询。这个例子只说明比较方法，不代表任何真实账户数据。
不能直接照搬的边界
服务端统一判定并非所有情况都适用。当咨询入口涉及第三方平台、电话运营商或线下门店时，服务端拿不到完整原始事件，强行合并会把不同人的咨询算成同一人。此时应保留各入口独立计数，只在报表层做“已知同一人”的合并，并明确标注合并假设。
另外，广告点击与自然搜索是不同机制，投放广告不构成自然排名保证。平台当前审核规则、界面和价格需查官方，本文不虚构。去重规则一旦改动，应同步检查报表口径和线索交接口径，否则设备端减少了重复，报表端仍可能重复。
落地时先定三件事
- 去重键：优先选手机号或登录态，弱标识场景选会话ID加时间窗。
- 判定位置：能拿到稳定标识就放服务端；拿不到就只做报表层合并。
- 例外处理：跨天、跨入口、跨设备的咨询单独标记，不直接覆盖原始事件。
把这三件事写进同一份事件规范后，设备之间完成咨询的路径才有统一依据，重复计算也才有可核对的出口。
