需要现成的用户行为分析产品，还是需要把已有 SDK 事件写入自己的 ClickHouse？这是比较诸葛 IO 与 SensorFlow 时最重要的问题。诸葛 IO 有 SaaS 和私有化 PaaS 方案，面向业务分析、用户洞察与数据治理；SensorFlow 聚焦兼容事件的接收与自托管 ClickHouse 数据链路。两者都不应被描述为对方的功能等价替代。
**简短结论：**产品、运营、市场需要在一个系统里完成增长、留存、广告或用户分析，先评估诸葛 IO 的具体方案。已有神策 SDK 埋点、团队更看重 ClickHouse 原始事件和 SQL 定义权，才值得测试 SensorFlow。SensorFlow Demo 可先运行，但真实 SDK 接收需要许可证；诸葛 IO 的价格、部署和功能也应按实际合同与版本核对。
公开资料能确认什么？
诸葛 IO 的 SaaS 产品页列出增长场景、广告监测、产品迭代和多端数据接入；私有化 PaaS 页面描述业务分析、埋点管理、数据仓库、API、用户打通和实施服务。这说明“诸葛 IO 只能 SaaS、不能私有化”是不准确的。
诸葛开放平台文档还列出原始数据导出、SQL 查询导出、查询 API、Kafka 订阅以及私有化版本的数据仓库接口。因此也不能宣称“选择诸葛 IO 就完全拿不到原始数据”。真正要问的是：所购买的版本允许什么访问方式、什么延迟、什么字段、什么配额，以及数据导出或订阅是否需要额外实施。
SensorFlow 公开仓库说明其主链路是兼容神策 SDK 流量 → Go 接收 → ClickHouse → Apache Superset。这里的 SQL 和原始行访问是默认工作方式，不是成熟业务界面的附加导出选项。但这也意味着指标口径、看板、权限、备份和运维需要使用团队自己负责。
| 维度 | 诸葛 IO | SensorFlow |
|---|---|---|
| 定位 | SaaS/私有化的用户行为分析和数据服务 | 自托管事件接收与 ClickHouse 分析数据路径 |
| 业务界面 | 官方提供增长、留存、广告和用户分析场景 | Superset 看板与 SQL，需自行建模 |
| 原始数据 | 官方开放文档列出导出、API、Kafka 与私有化仓库接口；以方案为准 | 团队直接查询自有 ClickHouse |
| 客户端迁移 | 需核对诸葛 SDK 或现有埋点的接入改造 | 针对兼容神策 SDK 标准上报做接收端验证 |
| 运维 | SaaS 或私有化方案不同 | 使用团队自托管、监控、备份、升级 |
| 授权 | 按具体方案与合同核对 | 演示阶段与真实接收许可证分开 |
诸葛 IO 更适合什么情况？
如果业务用户要自己建漏斗、看留存、分析广告投放，产品化界面和实施服务价值很高。诸葛 IO 产品页描述了漏斗和留存分析；私有化页面还列出场景分析、用户洞察和运维交付。一个没有专门数据工程师的团队，把这些工作转为自建 SQL 和 Superset 看板，可能会增加总成本而非减少。
已有诸葛 IO 深度集成的组织更应注意迁移范围：用户身份合并、历史数据、权限、场景模板、营销链路都不是把接收地址改成另一个 URL 就能复制的。即使 SensorFlow 能接收某些事件，也不代表它替代了完整诸葛 IO 产品。
SensorFlow 更适合什么情况？
如果团队已经有神策官方 SDK 事件，主要诉求是改变接收与存储边界，而非购买一套新的业务分析界面，SensorFlow 的范围更清晰：先运行演示栈，在 ClickHouse 中检查 Demo 事件；需要真实接收时安装许可证、执行激活，再拿实际 SDK 版本发送唯一测试事件。部署顺序见快速开始文档。
这不是“零改造保证”。加密插件、复杂身份规则、可视化全埋点、历史数据迁移和特殊发送模式都需独立测试。也不能把开源仓库等同于无限制免费真实埋点：README 明确区分无许可证演示与需许可证的真实接收。
公平的选型 PoC
选定一个真实问题，例如按渠道拆分的注册转化，不要只看官网截图。
- 固定事件名称、用户标识、时间字段和关键属性；列出当前 SDK 版本。
- 用测试用户产生同一组非敏感事件，核验 HTTP 响应、队列/处理结果、最终落库记录。
- 分别让业务用户完成漏斗和留存任务，并记录是否需要工程师写 SQL。
- 检查原始数据访问：诸葛方案的导出/API/Kafka/仓库权限，或 SensorFlow 的 ClickHouse 表权限与备份。
- 核对失败重试、身份关联、时区和重复事件；最后才用代表性负载测成本和性能。
若要计算成本，应该把软件授权、实施服务、基础设施、备份、SQL 指标维护和业务用户培训放在一张账单上。本文没有双方当前合同报价，也没有并排性能测试，因此不写“更便宜”“更快”的结论。
诸葛 IO 更像面向业务部门的完整分析与数据服务方案；SensorFlow 更像针对已有兼容 SDK 埋点的 ClickHouse 数据链路。前者的私有化和原始数据开放能力应被认真评估，后者的许可证和 SQL 运维成本也必须写进方案。最终选型取决于团队要替换的是“分析产品”还是“事件接收与存储边界”。
SensorFlow 是独立项目，与诸葛 IO、神策数据不存在关联、认证或背书。