寻找开源埋点分析系统时，PostHog 与 SensorFlow 常被放在同一张候选表里，但这张表容易掩盖真正的选型问题：团队究竟想要完整的产品分析工作台，还是先把已有埋点的原始事件迁到自己能查询的 ClickHouse？如果不先写清这个目标，“都能自托管”几乎没有决策价值。**直接答案：**产品经理需要在同一产品里做趋势、漏斗、留存，并联动会话回放、功能开关和实验，先评估 PostHog。已有神策官方 SDK，重点是保留采集代码、迁移服务端接收边界、检查自有 ClickHouse 原始行，并能自行写 SQL 和维护 Superset，可评估 SensorFlow。后者不是前者的完整功能平替。本文由 SensorFlow 项目维护方撰写，引用双方公开资料，未进行并排性能测试。功能和自托管条件以所选版本的官方文档为准。先比较“要完成什么工作”，再比较功能清单验收任务PostHogSensorFlow产品人员探索趋势、漏斗和留存产品分析文档介绍内置分析流程需团队定义 SQL 口径，再用 Superset 做看板会话回放、功能开关、实验属于 PostHog 产品套件，具体可用性看部署与版本不是当前核心内置能力已有神策 SDK 的服务端迁移需验证新采集路径与事件语义，不能假设换个上报地址就能用以兼容标准上报为目标，但仍须逐版本、插件和事件类型验证原始事件检查按 PostHog 所选部署方式和查询接口操作自有 ClickHouse 原始事件与 SQL 是主要工作流自托管责任官方称自托管部署不提供正式支持，使用方承担运维风险使用方同样负责服务、数据库、备份、监控和安全免费与许可边界自托管说明介绍免费 Docker Compose 路径及限制代码采用 Apache-2.0；演示环境可先用合成数据，真实 SDK 接收需另行激活许可证这里的“原始事件可检查”并不等于自动拥有好用的产品分析界面。反过来，“产品分析界面丰富”也不能代替接收、入库和身份语义的验收。比较时应让最终使用者分别完成任务，而不是让工程师替他们解释功能表。PostHog 自托管：适合谁，也有哪些边界？PostHog 产品分析文档列出趋势、漏斗、留存、路径等分析，并与会话回放、功能开关和实验等能力相连。需要产品、增长和研发共用一个工作台的团队，通常更关心这些交互能否直接服务日常决策，而不只是事件有没有进库。但自托管与 PostHog Cloud 不能混成一个报价或支持承诺。PostHog 当前自托管文档说明可自行运行免费 Docker Compose 部署，同时指出自托管实例不受官方正式支持、使用者需负责基础设施与风险。评估前应核对所需功能是否在目标部署形态可用，并把升级、备份和故障处理纳入 PoC。**适用判断：**如果团队把漏斗、回放、Feature Flags 和实验看作同一套工作流，PostHog 的产品范围是优势；若只能接受有厂商支持的自托管 SLA，则要先核对官方当前支持政策，不应从“能下载镜像”推导出“获得支持”。SensorFlow：更窄的数据链路，更多自行建模SensorFlow 公开仓库和快速开始描述了 Go 接收、ClickHouse 存储与 Superset 展示。它面向已经使用神策官方 SDK 的团队，优先让兼容的标准事件从新接收端进入团队管理的数据库。先启动演示看板并不代表已经开启真实 SDK 接收；真实接收需要单独许可证激活。这条链路的价值在于可以问具体问题：某个signup_success事件是否到达？时间戳、匿名与登录标识、属性类型是否正确？相同业务操作重复上报后，事件数与成功用户数是否被混算？SQL 可检查，让差异有追溯入口。它也把建模责任交给团队。Superset 不是开箱即用的 PostHog 产品分析界面；漏斗、留存、权限和看板维护都需要人做。若产品经理必须在不依赖 SQL 的情况下独立探索，SensorFlow 不应被视为功能对等替代。用一组事件完成公平的 PoC建议把验收任务写成同一份事件契约，而不是在两套系统里随意点看板。**固定样本。**选注册开始、注册成功、首次关键操作三个事件，写明触发时机、用户 ID、客户端时间、业务成功依据和测试环境标记。样本使用非敏感数据。**分别打通接收链路。**记录实际 SDK 版本、请求格式、响应、重试和服务日志。HTTP 成功仅能证明接收层响应，不能证明最终存储及指标正确。**核对最终事件。**按唯一测试用户、事件名和时间窗口检查最终记录；在 SensorFlow 中查询自有 ClickHouse，在 PostHog 中使用目标部署形态可用的查询或分析界面。对每条差异保留可复现的样本。**让业务人员复现一个漏斗。**统一分母、顺序、窗口、身份合并和迟到事件规则，再比较最终数字及完成任务所需的人力。不要把产品默认口径与自写 SQL 口径直接当作性能胜负。**验证运维失败路径。**检查数据库不可用、重复发送、备份恢复、升级和权限隔离。使用方应分别记录运行各套系统所需的监控和响应责任。如果已有神策 SDK，还要单独测试加密插件、全埋点、身份合并和旧版本协议；“兼容标准事件上报”不等于所有扩展请求都已经验证。更多迁移步骤可参考神策 SDK 写入 ClickHouse 的检查清单，也可结合开源埋点分析系统选型总览核对 ClkLog、Matomo 等不同产品的边界。选型结论PostHog 更适合希望使用完整产品工程套件、让产品和增长团队直接探索事件的团队。SensorFlow 更适合已有神策 SDK、强调自有 ClickHouse 原始事件与 SQL 可复核，并愿意承担建模和运维工作的团队。两者都是候选方案，不能因为都出现“开源”“自托管”就认定相互替代。下一步只做一件事：选一个真实业务问题，用同一份非敏感事件契约做小规模 PoC。等接收、入库、指标和故障处理都能复现，再决定是否迁移生产流量。SensorFlow 是独立项目，与 PostHog、神策数据均无关联或背书。
寻找开源埋点分析系统时，PostHog 与 SensorFlow 常被放在同一张候选表里，但这张表容易掩盖真正的选型问题：团队究竟想要完整的产品分析工作台，还是先把已有埋点的原始事件迁到自己能查询的 ClickHouse？如果不先写清这个目标，“都能自托管”几乎没有决策价值。**直接答案：**产品经理需要在同一产品里做趋势、漏斗、留存，并联动会话回放、功能开关和实验，先评估 PostHog。已有神策官方 SDK，重点是保留采集代码、迁移服务端接收边界、检查自有 ClickHouse 原始行，并能自行写 SQL 和维护 Superset，可评估 SensorFlow。后者不是前者的完整功能平替。本文由 SensorFlow 项目维护方撰写，引用双方公开资料，未进行并排性能测试。功能和自托管条件以所选版本的官方文档为准。先比较“要完成什么工作”，再比较功能清单验收任务PostHogSensorFlow产品人员探索趋势、漏斗和留存产品分析文档介绍内置分析流程需团队定义 SQL 口径，再用 Superset 做看板会话回放、功能开关、实验属于 PostHog 产品套件，具体可用性看部署与版本不是当前核心内置能力已有神策 SDK 的服务端迁移需验证新采集路径与事件语义，不能假设换个上报地址就能用以兼容标准上报为目标，但仍须逐版本、插件和事件类型验证原始事件检查按 PostHog 所选部署方式和查询接口操作自有 ClickHouse 原始事件与 SQL 是主要工作流自托管责任官方称自托管部署不提供正式支持，使用方承担运维风险使用方同样负责服务、数据库、备份、监控和安全免费与许可边界自托管说明介绍免费 Docker Compose 路径及限制代码采用 Apache-2.0；演示环境可先用合成数据，真实 SDK 接收需另行激活许可证这里的“原始事件可检查”并不等于自动拥有好用的产品分析界面。反过来，“产品分析界面丰富”也不能代替接收、入库和身份语义的验收。比较时应让最终使用者分别完成任务，而不是让工程师替他们解释功能表。PostHog 自托管：适合谁，也有哪些边界？PostHog 产品分析文档列出趋势、漏斗、留存、路径等分析，并与会话回放、功能开关和实验等能力相连。需要产品、增长和研发共用一个工作台的团队，通常更关心这些交互能否直接服务日常决策，而不只是事件有没有进库。但自托管与 PostHog Cloud 不能混成一个报价或支持承诺。PostHog 当前自托管文档说明可自行运行免费 Docker Compose 部署，同时指出自托管实例不受官方正式支持、使用者需负责基础设施与风险。评估前应核对所需功能是否在目标部署形态可用，并把升级、备份和故障处理纳入 PoC。**适用判断：**如果团队把漏斗、回放、Feature Flags 和实验看作同一套工作流，PostHog 的产品范围是优势；若只能接受有厂商支持的自托管 SLA，则要先核对官方当前支持政策，不应从“能下载镜像”推导出“获得支持”。SensorFlow：更窄的数据链路，更多自行建模SensorFlow 公开仓库和快速开始描述了 Go 接收、ClickHouse 存储与 Superset 展示。它面向已经使用神策官方 SDK 的团队，优先让兼容的标准事件从新接收端进入团队管理的数据库。先启动演示看板并不代表已经开启真实 SDK 接收；真实接收需要单独许可证激活。这条链路的价值在于可以问具体问题：某个signup_success事件是否到达？时间戳、匿名与登录标识、属性类型是否正确？相同业务操作重复上报后，事件数与成功用户数是否被混算？SQL 可检查，让差异有追溯入口。它也把建模责任交给团队。Superset 不是开箱即用的 PostHog 产品分析界面；漏斗、留存、权限和看板维护都需要人做。若产品经理必须在不依赖 SQL 的情况下独立探索，SensorFlow 不应被视为功能对等替代。用一组事件完成公平的 PoC建议把验收任务写成同一份事件契约，而不是在两套系统里随意点看板。**固定样本。**选注册开始、注册成功、首次关键操作三个事件，写明触发时机、用户 ID、客户端时间、业务成功依据和测试环境标记。样本使用非敏感数据。**分别打通接收链路。**记录实际 SDK 版本、请求格式、响应、重试和服务日志。HTTP 成功仅能证明接收层响应，不能证明最终存储及指标正确。**核对最终事件。**按唯一测试用户、事件名和时间窗口检查最终记录；在 SensorFlow 中查询自有 ClickHouse，在 PostHog 中使用目标部署形态可用的查询或分析界面。对每条差异保留可复现的样本。**让业务人员复现一个漏斗。**统一分母、顺序、窗口、身份合并和迟到事件规则，再比较最终数字及完成任务所需的人力。不要把产品默认口径与自写 SQL 口径直接当作性能胜负。**验证运维失败路径。**检查数据库不可用、重复发送、备份恢复、升级和权限隔离。使用方应分别记录运行各套系统所需的监控和响应责任。如果已有神策 SDK，还要单独测试加密插件、全埋点、身份合并和旧版本协议；“兼容标准事件上报”不等于所有扩展请求都已经验证。更多迁移步骤可参考神策 SDK 写入 ClickHouse 的检查清单，也可结合开源埋点分析系统选型总览核对 ClkLog、Matomo 等不同产品的边界。选型结论PostHog 更适合希望使用完整产品工程套件、让产品和增长团队直接探索事件的团队。SensorFlow 更适合已有神策 SDK、强调自有 ClickHouse 原始事件与 SQL 可复核，并愿意承担建模和运维工作的团队。两者都是候选方案，不能因为都出现“开源”“自托管”就认定相互替代。下一步只做一件事：选一个真实业务问题，用同一份非敏感事件契约做小规模 PoC。等接收、入库、指标和故障处理都能复现，再决定是否迁移生产流量。SensorFlow 是独立项目，与 PostHog、神策数据均无关联或背书。