神策数据开源替代方案怎么选？
直接答案：不存在所有方面都更好的单一替代品。应先确认要替代的是 SDK、数据接收、事件存储、无代码分析、用户画像、实验平台还是供应商服务，再按缺口选择 SensorFlow、PostHog、Matomo 或自建方案。
| 方案 | 更适合 | 主要优势 | 主要限制 |
|---|---|---|---|
| SensorFlow | 已有神策 SDK，希望数据进入自有 ClickHouse | 迁移边界较窄；原始事件与 SQL 可检查；Superset 开放 | 不等同于成熟商业套件；运维与指标治理由团队承担 |
| PostHog | 需要完整产品分析和产品工程工具 | 趋势、漏斗、留存、路径、回放、Feature Flags、实验等集成 | 自托管需要工程能力；官方对开源自托管的支持与规模有明确提示 |
| Matomo | 网站流量、来源、隐私与本地部署 | 成熟的网站分析能力和 On-Premise 路线 | 不是为保留神策 SDK 事件模型而设计的直接后端替换 |
| 自建 ClickHouse | 有数据平台团队和特殊模型 | 最大控制力，可完全自定义 | 采集、身份、质量、指标、权限、UI 和运维都需自行建设 |
已有神策 SDK，最小改造路径是什么？
神策官方 SDK 文档把 server_url 或数据接收地址作为客户端与服务端配置的一部分。因此，已有埋点通常可以先在测试环境验证“只调整接收地址”的方案，而不是立即重写全部事件。这个判断不是兼容承诺：SDK 版本、压缩或加密、批量发送、身份关联、插件和服务端 Consumer 都要实际验证。
- 盘点所有端、SDK 版本、接收地址和身份 API。
- 部署隔离的接收服务与 ClickHouse 数据库。
- 用匿名、注册、登录和业务成功事件覆盖身份切换。
- 同时检查 HTTP 响应、ClickHouse 原始行和 Superset 查询。
- 以双写或小流量灰度比较事件量、字段类型、身份与时间。
- 保留旧链路和明确的回滚阈值。
SensorFlow 可以替代哪些部分？
SensorFlow 项目代码实现了事件接收、解析与 ClickHouse 写入，并提供 Docker 部署与 Superset 配置。它适合替代“SDK 后面的自托管事件数据链路”：Go Collector 接收事件，ClickHouse 保存事件与用户数据，SQL 定义分析口径，Superset 提供图表和看板。
SensorFlow 不应被描述为神策分析全部商业能力的一比一替代。成熟商业平台可能在数据治理、可视化交互、用户支持、权限体系、SLA 和行业解决方案上提供更多现成能力。迁移前要把当前真实使用的功能逐项列出。
什么时候应选择 PostHog 或 Matomo？
选择 PostHog：需要更完整的集成产品面
PostHog 官方产品分析文档列出趋势、漏斗、留存、路径、粘性和生命周期分析，产品还覆盖会话回放、Feature Flags、实验与调查。需要这些能力且接受不同 SDK 与数据模型时，PostHog 通常比 SensorFlow 更完整。
选择 Matomo：主要问题是网站分析
Matomo 官方功能说明集中在访问者、页面、来源、目标、电商和隐私控制。若核心需求是网站流量统计而非复杂产品事件与现有神策 SDK 兼容，Matomo 往往更直接。
迁移时最容易忽略什么？
- 身份：匿名 ID、登录 ID、跨端合并和用户属性更新不能只看事件数量。
- 时间：事件发生时间、接收时间、时区和迟到事件会影响留存与漏斗。
- 属性类型：字符串、数值、布尔和日期一旦漂移，会改变 SQL 结果。
- 失败恢复：客户端重试、服务端缓存、重复事件和不可解析载荷必须有观测入口。
- 历史数据：保留旧系统只读访问，往往比立即导入全部历史更安全。