腾讯视频aso优化数据分析报告：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Safari/605.1.15 (Applebot/0.1; +http://www.apple.com/go/applebot)
🔗 /addaa0bbfb2f.html
📄
腾讯视频aso优化数据分析报告：访客被分配到不同版本时怎样识别样本污染
先给结论：如果同一时间段内，一部分访客看到A版本、另一部分看到B版本，而你又把两拨人的行为数据合并成一张报表，那么这张报表里的任何差异都可能是版本差异和人群差异混在一起的结果，不能直接归因于某个版本。识别样本污染的关键动作是先把分流日志和埋点数据对齐，确认每个访客实际进入的是哪个版本，再决定是拆分对比还是丢弃受污染样本。
先确认分流是否真的随机
很多团队默认分流是随机的，但实际执行时经常出现偏差。你需要拿到的第一份证据是分流日志：每个访客ID、进入时间、被分配到的版本、分配依据（如设备号、账号、随机数）。把这份日志和埋点事件表按访客ID做一次关联，检查三件事。
- 同一个访客在观察期内是否只进入过一个版本。如果同一ID先后出现在A、B两组，说明分流规则可能被缓存、登录状态切换或客户端版本更新打断。
- 两组的进入时间分布是否接近。如果A版本集中在上午、B版本集中在晚间，那么后续的播放完成率差异可能来自时段而非版本。
- 两组的设备或渠道构成是否接近。如果B版本恰好覆盖了更多新装机用户，留存差异就不能只归给版本。
假设你发现B版本的晚间进入占比明显高于A版本，那么下一步不是直接比较两组的播放时长，而是先按进入时段分层，再看同层内两版本是否还有差异。这一步的结果会决定你后面是继续做分层对比，还是直接判定这批数据不可用于版本结论。
区分“分流污染”和“埋点污染”
样本污染不一定来自分流本身。埋点上报错误也会造成同样的表象：报表里某个版本的数据看起来异常，实际是该版本的埋点根本没上报完整。两种情况的处理方式不同，需要分开判断。
分流污染的特征：分流日志和埋点事件对不上，比如日志显示访客被分到A版本，但埋点里带的是B版本标识；或者一部分访客在埋点中完全没有版本字段。
埋点污染的特征：分流日志正常，但某个版本的事件量明显偏低，且低得集中在特定页面或特定事件类型上。这通常意味着该版本的埋点代码没有正确触发，而不是访客真的没产生行为。
实际动作是：先按版本统计事件总量，再按页面或事件类型拆开看。如果某个版本在所有事件上都均匀偏低，更可能是分流或样本构成问题；如果只在个别事件上偏低，优先检查该版本的埋点实现。这个区分结果直接影响你下一步是修分流逻辑，还是修埋点代码。
两种处理方式的取舍：剔除还是分层
确认存在污染后，通常有两种做法，选择哪种取决于污染的比例和你需要的结论精度。
- 剔除受污染样本。适用于污染比例较低、且被污染的部分和整体差异明显的情况。代价是样本量减少，如果原本样本就不大，剔除后可能不足以支撑版本对比。
- 分层后再对比。适用于污染集中在某个可识别维度（如时段、渠道、设备）的情况。把该维度作为分层变量，在各层内比较版本差异。代价是分析复杂度上升，且需要每层都有足够样本。
判断条件可以这样用：如果被污染的样本在总样本中占比很小，且污染原因和你要观察的指标没有直接关系，剔除更简单。如果污染集中在某个渠道，而该渠道恰好是你关心的重点，剔除会丢掉关键信息，此时分层更合适。假设你发现某个版本的污染主要来自一个特定渠道，而该渠道用户的行为模式和其他渠道明显不同，那么分层对比比直接剔除更能保留有效信息。
用一份可核查的证据链收尾
无论选择哪种处理方式，最终的报告里应该留下一条可核查的证据链，而不是只给一个结论。这条链至少包含：分流日志的覆盖范围、埋点事件与分流日志的关联率、被判定为污染的样本量和判定依据、以及处理后各组的样本构成。
需要提醒的是，第三方估算的流量数据、平台后台的统计口径和你自己埋点得到的数据，三者本来就可能不一致。这种不一致本身不能证明样本污染，也不能单独用来还原分配逻辑。只有当分流日志和埋点数据在同一访客层面出现矛盾时，才构成样本污染的可靠证据。把这些证据写进报告，读者才能自己判断你的处理是否合理，也才能在下一轮分析中复用同样的判断方法。
