你要问我在谷歌斗篷投放里，哪件事最容易被大家不当回事，我的答案大概率是埋点对账。埋点本身倒没什么难的，真正麻烦的是点击侧和放行侧的数据一旦对不齐，你后面所有的优化判断就全歪了。你看着像是规则命中率掉了，其实是埋点中间丢了一段；你怀疑流量质量变差，搞半天是时间戳错位把归因给串了。这篇我不打算铺那种大而全的埋点规范，就顺着风险信号的路径来讲：对账的时候看到什么信号、这个信号为什么值得警惕、具体怎么查、查到什么程度就该停手别放量了。
对账先看差在哪一段：点击侧与放行侧的三个常见断点
做全链路对账，一上来别急着比总数。先把链路切成能互相对比的段落，这才是有意义的起点。用户从点击广告到规则判定放行，中间至少有三个数据落点：广告平台那边的点击上报、跳转服务的请求入口、还有规则引擎的放行决策。这三段数据有损耗是天然的，关键看损耗是不是还在你能解释的范围内。
断点一：点击上报和请求入口之间的落差
广告平台记的点击数，跟跳转服务实际收到的请求数，一般不会严丝合缝地相等。差个千分之几到百分之几，都算正常，网络重传、用户中途把页面关了、客户端拦截，这些都会造成损耗。可要是这个落差忽然从平时的百分之一二蹦到百分之七八，那就不能当正常损耗看了。
怎么查？把最近七天的小时级点击数和请求数拉出来，按小时做差值曲线。正常情况下的落差曲线应该有一条稳定的基线在波动，突然往上窜，往往对应着某次配置变更，或者某个地区的网络出了状况。这里盯的是变化率和持续时间，单点抖一下不用紧张，连着三个小时以上偏离基线，那才值得动手查。
这一段是自查的重头戏，因为它完全在你自己能控制的范围内。请求明明进来了，规则引擎却没吐出判定结果，常见的原因大概三类：请求在预处理阶段就被扔掉了，比如参数校验没过；规则加载失败，压根走不到判定逻辑；再就是判定超时，被上游给掐断了。 验证的办法是在请求入口和规则判定之间加一个中间埋点，把请求ID和进入判定逻辑的时间都记下来。要是请求入口有记录、判定侧找不到对应的ID，那就说明丢在预处理或者规则加载环节了。顺着去看规则引擎的加载日志和预处理阶段的错误计数，很快就能定位到是哪一类。
断点三：判定结果和实际跳转之间的不一致
规则判定说放行，用户实际看到的却是另一个页面；或者判定说拦截，用户照样正常访问了目标页。这类不一致通常不是数据本身的问题，多半是缓存、斗篷系统和CDN节点调度冲突时，链路分段定位该从哪一层开始查？">CDN边缘节点没同步、或者客户端本地缓存闹的。它不会直接体现在数量对账上，但会让你的放行数据失真。 检查方法是抽一批判定为放行的请求，拿请求ID去反查实际返回的页面版本和缓存命中状态。要是发现同一批判定结果对应了两种不同的实际返回，那就得去看缓存刷新策略和边缘节点的配置同步时间了。
对账锚点怎么选：哪些字段能串起全链路
对账这件事能不能做起来，说到底取决于有没有一个字段能从点击一路串到放行。我见过不少团队埋点埋了一大堆，结果对账的时候发现字段对不上，各段各记各的，最后只能比总数，比来比去也比不出个所以然。
请求ID是基础锚点，但要注意生成时机
请求ID最好在广告点击落地的那一刻就生成，然后随跳转请求一路带下去。要是在跳转服务入口才生成，那点击侧和请求入口之间的落差就没法用ID对齐了，只能靠时间窗口模糊匹配，精度差很多。
还有个限制条件：请求ID得保证唯一，同时长度要可控。我见过有团队拿UUID加时间戳加随机数拼了很长一串，结果在URL透传的时候被某些中间层截断了，反而制造出新的对账断点。建议控制在32位以内，时间戳加序列加节点标识就够用了。
时间戳要对齐到同一个时钟源
各段埋点的时间戳要是来自不同的服务器时钟，对账时就会冒出来“点击发生在放行之后”这种逻辑上根本不可能的数据。偏差在几百毫秒以内还能靠时间窗口容忍，超过一秒，窗口匹配就变得不可靠了。
检查方法：定期抽查各段服务器的时间同步状态，NTP偏差超过500毫秒就得处理。对账时如果发现大量记录的时间顺序是颠倒的，先查时钟，再查业务逻辑，按这个顺序来能省不少时间。
这两个状态在很多系统里被合并成一个字段了，结果对账的时候分不清到底是规则判了放行但执行失败，还是规则本身就判了拦截。建议在埋点里分开记：判定结果（pass/block）、执行结果（success/fail），再加上失败原因码。
验证方法是拿一批判定为pass但执行fail的请求，去看失败原因码的分布。要是集中在一两个原因上，那说明是某个环节的稳定性问题；要是散得很开，可能是链路本身有结构性的脆弱点。
异常信号的阈值怎么定：从基线到触发动作
对账清单要是没有阈值和动作，那它就是一张表，没什么用。真正有价值的是：看到什么信号、到了什么程度、触发什么动作。
差异率本身没那么吓人，吓人的是它偏离了你自己建立的基线。基线怎么建？把过去两周到四周的正常数据拉出来，按小时或者按天算出差异率的均值和波动范围。日常波动在基线上下一定范围内，都算正常。
触发条件是这么定的：差异率连续三个统计周期超出基线波动范围，或者单周期超出基线两倍以上。前者说明有持续性的问题，后者说明有突发性的事件。 动作上，连续偏离先去查最近的配置变更记录，突发偏离先去查流量来源和地区分布。要是配置没动、流量来源也没变，那就升级到链路层排查，查网络和中间件。
规则没改，放行率却掉了，这种情况通常说明输入的数据变了，问题不在规则本身。常见的原因是流量特征分布发生了变化，比如某个地区的流量占比突然升高，或者某个设备类型的请求特征跟之前不一样了。 检查方法：把放行率按地区、设备、流量来源拆开看。如果整体放行率下降但各分组的放行率没怎么变，那是流量结构变了；如果某个分组的放行率明显下降，那是那个分组的特征跟规则不匹配了。
停止条件也得说清楚：放行率下降超过基线的一定比例，并且持续超过半天，建议先暂停该渠道的放量，把原因查清楚再说。继续放量只会让异常数据污染你的判断。
无法归因指的是有放行记录但找不到对应的点击记录，或者有点击记录但全链路都找不到后续。少量无法归因是正常的，比例高了就说明链路有断裂。
检查方法：抽一批无法归因的记录，看它们的时间分布和来源分布。集中在某个时间段，就查那个时间的链路状态；集中在某个来源，就查那个来源的接入配置。 升级条件是这样：无法归因比例超过总量的百分之几，而且还在持续增长，那就不只是埋点问题了，得考虑是不是有链路节点在静默失败。这时候该拉上运维一起看中间件和网络层。
实战复盘：一个家居流量团队的对账排查过程
上个月有个做家居流量站的团队找到我，他们的谷歌斗篷投放跑了一个多月，量不算大，日均一千二三百的点击，服务器是两台4核8G的机器加一个CDN。麻烦在于对账一直对不上：点击侧记录的数量和放行侧差了百分之五点几，而且这个差距还在慢慢扩大。
他们一开始怀疑是规则命中率的问题，调了两轮规则参数，没什么效果。后来把链路切开看，发现请求入口收到的数量和点击侧只差百分之一出头，属于正常范围。问题出在请求入口和规则判定之间——有将近百分之四的请求进来了，但没有产生判定记录。
继续往下查，中间埋点显示这些请求在预处理阶段就被丢弃了，原因是参数校验不通过。再查参数校验的逻辑，发现他们最近加了一个新的参数校验规则，对某个字段做了格式限制，而部分流量来源传过来的这个字段格式跟预期不一致，直接就被拒了。
调整过程不复杂：把参数校验从硬拒绝改成软降级，格式不匹配的时候用默认值继续走判定流程，同时记录一条校验异常的埋点。改完之后差异率从百分之五点几降到了百分之一以内，而且这个校验异常的埋点让他们能持续观察到哪些来源的参数格式有偏差。
最终状态是对账差异率稳定在正常范围，他们把这个校验异常的埋点加进了日常对账清单，作为信号之一。用他们自己的话说，以前对账是月底算总账，现在是每天看几个关键信号，有问题当天就能发现。
对账清单的收束：日常该盯哪几个检查项
如果你不想搞得太复杂，至少把下面这几个检查项放进日常流程里。不用每天都全查一遍，但得有节奏地看，并且明确每个检查项对应的触发动作。
- 点击侧与请求入口的差异率：按小时看曲线，连续三个小时偏离基线就去查配置变更记录。
- 请求入口与规则判定的请求ID匹配率： 按天看，匹配率低于日常水平就查预处理和规则加载日志。
- 放行标记的判定与执行一致性： 按天抽样，发现不一致先查缓存和边缘节点同步状态。
- 无法归因记录的比例和趋势： 按天看，比例上升就按时间和来源拆开排查。
- 各段服务器时钟偏差： 按周抽查，偏差超过500毫秒就处理同步。
这几个检查项有个共同点：都是你自己可控范围内的信号，不依赖外部平台的数据回传。对账的核心不在于比总数，而在于通过自己链路里的信号，快速定位问题出在哪一段。外部数据的延迟和口径差异你控制不了，但自己链路的完整性是可以保证的。
最后提一句升级处理的原则：要是连续两个检查周期都发现同一个信号异常，而且按检查方法查下去没找到明确原因，就别继续在埋点层面打转了，升级到链路层排查。埋点对账能告诉你哪里对不上，但它解释不了为什么对不上——那需要网络、中间件、服务器层面的信息。把这两个层次分清楚，排查效率会高很多。
