HTTP 200 只能证明请求到达服务，不能证明埋点已经正确进入分析链路。字段类型、客户端时间、重试去重和身份关联都需要继续核对。
一套可靠的验收流程应覆盖：接收日志、ClickHouse 原始记录、字段语义、聚合 SQL，以及 Superset 看板结果。
1. 先发送可唯一定位的测试事件
发送名为 integration_test 的事件，加入测试批次、环境、平台、SDK 版本和合成用户 ID，并保留原始载荷作为后续逐字段比较的预期结果。
2. 验证接收层
保存 HTTP 状态、响应正文、请求时间、目标地址和请求 ID。在服务日志中确认请求进入正确环境、协议解析成功、存储操作完成，而不是只进入重试队列。
3. 查询 ClickHouse 原始事件
SELECT event, distinct_id, event_time, received_at, properties
FROM sensors.event
WHERE event = 'integration_test'
AND properties['validation_run'] = '2026-09-17-a'
ORDER BY received_at DESC
LIMIT 10;
查不到记录，说明问题位于接收到存储之间；出现多条记录，则需要判断是否发生重试，以及系统采用什么去重策略。找到记录后继续核对事件名、身份模型、客户端时间、接收时间、属性类型和环境。
4. 用确定批次验证聚合结果
发送结果已知的小批次，例如三个合成用户共十条事件：
SELECT
event,
count() AS event_count,
uniqExact(distinct_id) AS exact_users
FROM sensors.event
WHERE event = 'integration_test'
AND properties['validation_run'] = '2026-09-17-b'
GROUP BY event;
验收阶段使用精确函数更容易判断结果。生产环境是否换用其他聚合函数，应根据准确度、数据规模和成本明确决定。
5. 在 Superset 重现同一结果
先在 SQL Lab 执行已经验证的 SQL，确认与 ClickHouse 客户端结果一致，再保存数据集和图表。若结果不同，应依次检查虚拟数据集、过滤器、时间字段与时区、缓存、行级权限以及用户去重口径。
截图不能替代验收记录，因为截图通常不包含 SQL、过滤条件和刷新时间。验证 SQL 与指标定义应一起版本化。
6. 测试故障路径
至少覆盖重复请求、非法字段、数据库短暂不可用、接收服务重启和移动端延迟上报。团队需要明确系统是至多一次、至少一次，还是通过幂等键实现近似的有效一次。
7. 灰度迁移与对账
条件允许时使用双写、流量镜像或小比例灰度，按固定时间窗口比较事件总量、用户数、属性缺失率、属性类型、延迟和重复率。目标是解释差异，而不是只让总数看起来一致。
上线检查表
- 唯一测试事件能在原始表定位；
- 身份与时间字段符合定义；
- 确定批次得到预期事件数和用户数；
- ClickHouse 与 Superset 结果一致；
- 时区、过滤器、缓存和权限已记录；
- 重试、重复、非法载荷和服务重启已测试；
- 回滚、备份和恢复流程明确。
开源实现参考
SensorFlow 是 Apache-2.0 开源、自托管实现：标准事件进入 Go 接收服务，写入 ClickHouse，再通过 Apache Superset 查询和展示。它适合愿意维护 Docker、ClickHouse 和 SQL 指标的工程团队，不等同于包含会话回放、实验和大量无代码分析流程的完整商业套件。
GitHub：https://github.com/data-analyze-bi/sensorFlow
实践指南：https://sensorflow.site/use-cases/clickhouse-superset-analytics
迁移指南：https://sensorflow.site/use-cases/sensors-sdk-to-clickhouse
可靠的埋点数据来自可追溯的验证链路，而不是一个绿色状态码。
