测试事件出现在正式日活、转化率里，通常不只是"忘了给测试账号加过滤条件"。数据可能在写入时就进入了正式环境，也可能已被标记为测试，但旧看板仍按原口径查询。排查时应分别确认 写到哪里、如何识别、查询是否排除。这三个问题的答案不能互相替代。
本文由 SensorFlow 项目维护方整理，AI 辅助起草。下文是通用验收方法，不表示 SensorFlow 已内置文中提到的环境或测试用户过滤功能。
测试埋点应该怎样隔离？
优先让开发、预发与生产使用不同的写入目标；确实需要在同一数据集测试时，再给合成事件或受控测试账号加明确标记，并在每一张正式报表里验证排除条件。最后用同一时间窗分别查询原始事件、测试事件和正式指标，检查三者的差额是否符合预期。
第一层：写入目标先隔离
PostHog 的多环境教程建议为不同环境使用不同项目，避免开发和预发流量污染生产项目。Segment 的环境配置文档则建议在同一工作区内为不同环境建立不同 Source，各自使用 Write Key。两者产品模型不同，但共同点是：把环境区分落实到实际写入入口 ，不能只靠事件名中的 test 字样。
迁移或灰度时，先列出每个环境使用的接收地址、项目标识或写入密钥，检查构建产物与运行环境是否匹配。再从开发、预发、生产各发送一条合成事件，逐一核对目标数据集；不要用真实用户资料验证。若开发事件已写进生产，后续在报表上隐藏它，仍不能说原始数据没有被污染。
第二层：标记测试身份，但别把标记当隔离
有些测试必须经过生产链路，此时可以为受控测试账号和合成事件设置稳定标记，并规定谁能创建这些标记、何时清理。PostHog 的内部与测试用户文档指出，设置过滤规则本身不会自动打开每个洞察的过滤开关；新洞察的默认设置也不会自动改动已有洞察。它还明确区分"从分析里过滤"和"阻止采集"：前者的事件仍可能出现在 Activity 中。
因此验收不能只看一张新建图表。至少抽查已有看板、新建看板、SQL 查询和导出结果，确认它们使用同一测试身份定义。若账号标记会在登录后变化，还要检查匿名事件和登录后事件是否都能被识别；无法确定的记录单列为"待判断"，不要悄悄归到正式用户。
第三层：明确过滤是永久排除还是报表口径
Google Analytics 的开发者流量过滤说明允许在启用调试模式时识别开发者流量，也提醒启用排除过滤器后，被排除的数据不会进入 Analytics 的处理结果。数据过滤器文档进一步说明，过滤器只影响创建后的数据，不会追溯修改历史数据。这个例子说明：采集前拦截、数据处理时排除、查询时隐藏，对追溯和排障的影响不同。
自托管方案也要写清自己的策略。比如使用 ClickHouse 原始事件表和 SQL 看板时，工程团队应明确测试标记是写入时拒绝、单独落表，还是写入后由查询条件排除。这是实施建议，不是 SensorFlow 当前默认行为。若选择查询时排除，要给正式指标查询保存可审计的条件，并在修改后重新跑历史时间窗；否则"今天过滤了测试账号"不代表昨天的报表已经重算。
一份可执行的验收清单
- 目标检查：开发、预发、生产各发一条合成事件，记录每条最终进入的数据集。
- 身份检查：使用合成测试账号分别在匿名和登录状态发送事件，核对标记与身份关联。
- 查询检查：同一时间窗查询原始事件总数、测试事件数和正式指标；解释差额，不只看一张图。
- 旧报表检查：逐一检查已有看板、SQL、导出和下游消费是否沿用同一排除口径。
- 回滚检查：临时关闭过滤时，记录哪些历史数据仍可恢复、哪些在处理前已被永久排除。
测试埋点隔离的验收结果应是一组可复查的目标、标记和查询证据，而不是一句"测试流量已过滤"。如果团队采用 SensorFlow 这类可查看原始事件并自行定义 SQL 指标的自托管链路，上述第三层尤其需要由实施团队自己落实和复核。