UBA RESEARCHBEHAVIOR / SYSTEMS / DECISIONS
下载研究报告
CHAPTER 11 · DECISION / TCO / ROADMAP

选型与落地:买什么、建什么、先做什么

选型不是选功能最多的,而是选“事件语义、数据主权、退出能力”最匹配的;90 天也不是上线所有看板,而是用两个真实决策证明数据可信。

6,167 字 24 分钟 30 条引用

这一章不给“买哪一家”的答案,而给一套可复核的排除顺序:先过红线,再打分,再算三年 TCO,最后用 RFP 与 90 天路线验证。它不替代商务谈判,也不替代法务与安全评审;它只保证一件事:不会在错误的问题上比较正确的产品。

如果你只要一个结论,先看 11.4.1 的条件表;如果要走完整采购流程,按 11.1 → 11.5 → 11.6 的顺序读。评分卡、TCO 与 RFP 都是可改的工具,不是行业标准。

11.1 先画缺口图,再谈功能#

选型失败通常不是买错了产品,而是在错误的问题上比较了正确的产品。三家厂商都能做漏斗,真正的差异在:事件是谁定义的,身份怎么合并,数据在哪里计算,洞察之后谁执行,三年后能不能带走。把这五个问题画成一张缺口图,比拿一张 200 项的功能表打勾有用得多。

先过五条红线。任何一条不满足,后面的功能分都没有意义:

红线 要问的问题 不合格的信号
数据区域 生产、备份、日志、AI 推理分别在哪里?跨境路径是什么? 只写“支持 EU/US”,不写备份与子处理者
原始事件导出 能否导出原始明细、事件 schema、属性类型、owner 与版本? 只能导出聚合报表,或导出要另收“数据出口费”
删除与保留 能否按用户、按事件、按时间删除?备份何时删除?有无证明? 只承诺“会删除”,没有 SLA 与验证报告
权限与审计 是否支持 SSO/SCIM、行级权限、导出审计、管理操作日志? 企业版才给 SSO,审计日志不可导出
身份“不合并” 共享设备、家庭账号、一人多账号时,能否选择不合并或回滚? 默认合并,且没有拆分工具

判断:这五条不是“高级需求”,是 UBA 的基础卫生。红线不过,功能越多,未来迁移越贵。 功能表会骗人,通常通过三个机制。第一,把“支持”当成“可用”:文档里有这个功能,但默认关闭、要加钱、只在企业版可用,或者需要专业服务实施。第二,把“能看”当成“能信”:图表能跑出来,但口径不透明、样本被采样、身份合并错了。第三,把“现在能用”当成“三年后还能用”:厂商被收购、计价单位变更、产品线收缩,都会让今天的演示失效。采购要问的不是“有没有”,而是“默认值是什么、证据在哪里、退出时怎么办”。

11.2 十条选型原则#

第一,从决策反推数据,不从工具反推场景。 先写清楚“今年必须回答的三个业务问题”,再倒推需要的事件、维度和时间窗口。没有决策场景的选型,最后一定变成“买了工具再找问题”。

第二,事件模型比查询界面重要。 界面可以换,事件命名、属性类型、身份规则和指标口径很难重来。要求厂商演示“如何管理一次 breaking change”,比演示“如何做一张漏斗图”更能看出功底。

第三,身份解析要问“不合并”。 所有平台都会讲跨端识别,少数能讲清楚“什么时候不该合并”。PostHog 对两个已 identify 的档案直接拒绝合并,Snowplow 在唯一标识冲突时新建匿名 ID,Amplitude 承认标准项目无法回溯合并两个已确立的 user_id 来源 来源 来源。不能处理“不合并”的系统,最终一定会制造无法解释的重复用户。

第四,warehouse-native 要分清下推、导入、导出。 Amplitude 的 Snowflake Native 把查询下推到客户仓库,数据不出域;Mixpanel 的 Warehouse Connectors 把仓库数据导入 Mixpanel;Heap Connect、Pendo Data Sync 是导出 来源 来源。三种架构的成本、延迟与退出方式完全不同。采购时让厂商画出数据流,不要只听“我们支持 Snowflake”。

第五,按“量随什么增长”选计价单位。 事件量随版本发布增长,MAU 随投放增长,会话随回放与移动端增长。选错计价单位,旺季账单会替你做决定。合同要锁三件事:计价单位、超量单价、续约涨幅上限。

第六,把回放留存当成第二条价格曲线。 “12 个月回放”通常不是默认能力:PostHog 免费层 1 个月、付费层 90 天,12 个月要买 Boost/Scale;Mixpanel Free/Growth 只有 30 天,7–365 天要进 Enterprise;Amplitude 默认 1 个月,延长是加购 来源 来源 来源。回放留存通常是单独加购项,且与录制量分开计价,报价单里常写成“高级功能”。

第七,AI 功能按“读、解释、建议、写”四级评估。 能读表、能解释图表、能建议动作、能直接写回人群/实验/配置,是四种风险等级。前三级的错误可以纠正,第四级的错误会直接改变用户看到的东西。要求厂商演示“谁批准、怎么回滚、日志在哪里”。

第八,开源不是“免费版 SaaS”。 开源省 license,不省 SRE、升级、备份、安全与合规。PostHog 官方把自托管列为“不支持”,Snowplow 自 2024 年起改用 Limited Use License,生产高可用要商业许可 来源 来源。选择开源,要先有平台团队,再有产品。

第九,采购合同要写“退出演练”。 在签约前做一次小规模导出:原始事件、事件定义、人群、查询、实验记录、权限。导出后做一次校验,确认行数、时间范围、身份映射与口径一致。不能带走的资产,等于没有。

第十,评分卡不替代 POC。 评分卡防止“演示很漂亮、合同签完才发现不能用”;POC 防止“文档很完整、真实数据跑不通”。两者都要,而且 POC 必须用客户自己的事件表与指标。

11.3 加权评分卡#

默认权重如下。它不是行业标准,而是一个可改的起点;权重必须随场景调整。

维度 权重 5 分的证据 1 分的信号
语义治理 22 taxonomy 有版本、owner、审批、血缘;breaking change 可拦截 只有一张 Excel 命名规范
身份与会话 18 合并可解释、可回滚;会话定义可版本化重算 默认合并,无法拆分;会话写死在 SQL
分析与可复现 15 同一问题可复算;口径、过滤、时间窗可导出 只能看预设看板,口径不透明
行动与实验 12 人群、实验、引导共用身份与曝光;权限分离 只能导出 CSV,行动在另一个系统
数据主权与合规 13 区域、DPA、删除、审计、AI 训练开关齐全 只有 trust center 徽章,合同不写细节
计价与 TCO 12 单位写死、涨幅上限、超量告警、账单封顶 纯询价,单位可单方变更
退出与迁移 8 原始明细 + 元数据 + 查询 + 人群可导出 只能导出聚合报表

计算方式:总分 = Σ(权重 × 得分 / 5),满分 100。先过红线,再打分;不要给“AI 功能”单独权重,把它放进“分析与可复现”和“行动与实验”里评分。

权重变体:

公司类型 权重调整 主要矛盾
10–50 人 SaaS 分析 20、TCO 18、身份 15、行动 15、治理 12、主权 12、退出 8 先活下来;治理可以晚一年,但语义要一开始就对
中大型 B2C 身份 22、分析 18、治理 16、行动 14、主权 12、TCO 10、退出 8 跨端身份是主要矛盾;事件量随版本膨胀
金融 / 政务 主权 25、治理 22、身份 18、分析 12、行动 8、TCO 8、退出 7 数据在哪里比功能多一项更重要;审计与可举证优先

评分时至少两人独立打分:数据平台与业务方各一次。分歧超过 1 分的维度,就是合同里要写清楚的地方。

11.4 三条路线与三年 TCO#

自建、采购、开源不是意识形态,是规模与约束的函数。统一公式:

三年 TCO = 3 ×(订阅/许可 + 基础设施 + 人力)+ 一次性实施 + 迁移摊销 + 隐形成本。

隐形成本包括回放留存、SSO/SCIM、超量、区域存储、AI 用量、专业服务与数据出口。人力按美国软件开发者 2025 年中位年薪 135,980 美元 × 1.3 加载系数 ≈ 176,774 美元/年折算,人民币按 7.1 折算,仅作量级比较 来源。

场景 采购(SaaS) 开源自建 私有化/中国项目制
1,000 万事件/月、20 席位 15–20 万美元/3 年 18–26 万美元/3 年 15–30 万美元/3 年
1 亿事件/月、30 席位 35–76 万美元/3 年 40–80 万美元/3 年 30–70 万美元/3 年
10 亿事件/月、30 席位 130–250 万美元/3 年 100–200 万美元/3 年 80–180 万美元/3 年

这些区间是量级估算,不是报价。三个关键事实:

  • 1,000 万事件/月,SaaS 软件费通常低于 0.25 个 FTE。 PostHog 产品分析约 324 美元/月、Mixpanel 1,000 万事件约 840 美元/月、Amplitude Plus 第三方读数约 576 美元/月(年付、1,000 万事件/月;官方页只写 Plus 从 0 美元起);加上回放与平台包,年订阅约 0.7–2.0 万美元 来源 来源 来源。三年 TCO 的大头是人力,不是软件。
  • 10 亿事件/月,软件费与 1 个 FTE 同量级。 PostHog 产品分析约 1.16 万美元/月,加 1,000 万条录制约 1.52 万美元/月;自建软件成本接近零,但 1–2 个 FTE 加基础设施通常不低于 40 万美元/年。此时“买还是建”取决于数据主权与差异化,不取决于 license。
  • 中国的项目制不能按事件单价横比。 2023 年深交所采购神策一年期授权,含每年 10 亿事件、2 个项目、智能运营 2 亿事件,含税成交 28 万元;2026 年中国大地保险为 GrowingIO v3.5 采购永久授权,含税最高限价 36 万元 来源 来源。它们对应私有化、有限项目数与一年服务,不能直接换算成国际 SaaS 的“每百万事件价”。

判断:自建真正省的不是软件费,而是“把数据主权与差异化握在手里”的可能性;如果团队没有 3 年以上平台经验,省下的 license 会以 2–3 倍的人力还回去。

11.4.1 什么情况下选哪条#

条件 优先采购 优先开源 优先私有化/项目制
事件量 < 5,000 万/月 是 仅在已有平台团队时 否
事件量 > 10 亿/月 企业合同 是,若团队能扛运维 视合规而定
数据不能出域 仅有区域版时 是 是
需要行业实体模型(游戏角色、金融适当性) 通用产品 + 二次开发 自建模型 行业厂商
需要快速上线、无平台团队 是 否 否
需要深度定制 UI / 嵌入产品 嵌入式分析 是 是
三年内可能被并购/重组 合同加控制权条款 代码可留存 主体风险更高

采购的适用条件是“时间比钱贵、需求标准化、数据可出境”。开源的适用条件是“有 3 人以上平台团队、事件模型是差异化资产、数据主权不可谈判”。私有化的适用条件是“合规一票否决、行业实体模型特殊、愿意为交付付费”。三条路线都可能正确,也都有可能失败;失败通常不是选错路线,而是用一条路线的前提去套另一条。

11.4.2 三种失败模式#

采购失败:把工具当能力。 买了最贵的套件,却没有 taxonomy、owner 与验收,最后得到一堆互相矛盾的看板。补救成本通常高于软件费,因为要重新定义事件、清洗历史数据、重建身份图。

开源失败:把代码当产品。 以为 fork 下来就能用,忽略了升级、备份、监控、权限、审计与安全补丁。半年后集群还在跑,但没人敢升级;一年后原始作者已经改了三版 schema,自己的 fork 无法合并。

私有化失败:把部署当合规。 数据进了自己的机房,但没有行级权限、审计日志、密钥管理和删除验证。合规检查时能拿出等保证书,却回答不了“谁在什么时候导出了哪个用户的行为数据”。

11.5 RFP 二十问#

数据与模型

  1. 原始事件保留多久?能否按天分区导出?导出格式与字段是什么?
  2. 事件 schema 是否支持版本、owner、废弃状态与 breaking change 拦截?
  3. 属性类型是否强校验?新增属性是否需要发版?
  4. 是否支持虚拟事件/派生属性?口径变更是否留痕?

身份与会话

  1. 匿名 ID、登录 ID、设备 ID、账户 ID 的合并顺序是什么?
  2. 共享设备、家庭账号、一人多账号时,如何选择不合并?能否回滚?
  3. 会话超时、前后台、跨天、深链的默认规则是什么?能否版本化重算?
  4. 登出、撤回同意、删除用户后,身份图如何更新?

分析与行动

  1. 漏斗的有序/无序、窗口、排除、分组默认值是什么?能否导出查询定义?
  2. 留存的 cohort、N-day/unbounded/rolling 口径是什么?右删失怎么处理?
  3. 人群规模、更新频率、身份覆盖率是多少?能否下发到实验/引导/CRM?
  4. 实验曝光是否与分析事件共用同一身份与时间线?能否做 holdout?

治理与合规

  1. 数据区域有哪些?备份、日志、AI 推理分别在哪里?
  2. 是否支持行级权限、SSO/SCIM、导出审计、管理操作日志?
  3. 删除请求的 SLA 是什么?备份何时删除?能否提供证明?
  4. 客户数据是否用于训练模型?能否关闭?关闭后功能有何变化?

商业与退出

  1. 计价单位是什么?超量单价、续约涨幅上限、账单封顶能否写进合同?
  2. 回放留存、SSO、审计、区域存储、AI 用量是否另收费?
  3. 控制权变更时,客户是否有终止权?迁移支持期多长?
  4. 能否在签约前做一次完整导出演练?迁移费用谁承担?

11.5.1 怎么读 RFP 的答案#

不要接受“支持”这种单词回答。每个答案至少要有三类证据:官方文档的链接、默认配置的截图、以及一次用客户数据做的演示。比如“支持行级权限”,要追问:权限是按用户、角色还是属性?跨租户查询如何隔离?导出时是否继承权限?管理员能否绕过?没有这三层,答案只是销售话术。

对“待核实”要宽容,对“都能做”要警惕。一个诚实的厂商会说“这个版本不支持,路线图在 Q3,但不确定”,这比“都可以”更可信。把每个“待核实”写进合同附件,约定验证时间与不达标的退出条款。

价格问题要问三遍:第一遍问公开价,第二遍问“我们这个量、这个模块、这个区域”的报价,第三遍问“三年后续约、超量 2 倍、加 50 个席位”的价格。三遍答案的差异,就是合同里要锁的变量。

11.5.2 合同必须写的六个条款#

条款 写法 不写的后果
数据导出 原始事件、schema、身份映射、人群、查询、实验记录;格式与频率 续费时发现只能导出聚合报表
计价锁定 计价单位、超量单价、续约涨幅上限、账单封顶 厂商换计价单位,预算失控
控制权变更 被收购/重组时客户可终止,按比例退款 产品线被整合,迁移没人管
SLA 采集可用性、查询 p95、数据延迟、丢失率、赔付 出故障只有“抱歉”,没有补偿
AI 训练 客户数据是否用于训练、能否关闭、关闭后的功能差异 数据被用于模型,法务事后才发现
迁移支持 支持期、导出协助、迁移费用、删除证明 合同到期即失联,历史数据成人质

这六个条款不需要都写成长篇法律文本,但必须写进主合同或 DPA,而不是销售邮件。采购可以把它们做成一张附件,要求厂商逐条确认;不愿意确认的条款,就是未来最可能出问题的地方。

RFP 之外再加两问,不计入 20 问:过去 24 个月,股权、控制权或产品线归属是否发生变化?支持团队、实施伙伴与区域服务能力是否可转移?中国市场的采购尤其要问,因为产品停更可以没有任何公告,合同主体却可能已经换了两次。

11.6 90 天落地路线#

90 天不是“上线所有看板”,而是“用两个真实决策证明这套数据可信”。

阶段 时间 交付物 出口条件 负责人
定义 0–30 天 两个业务问题、tracking plan v1、身份规则、隐私边界、验收标准 业务与数据共同签字;事件字典冻结两周 产品 + 数据平台
打通 31–60 天 采集、管道、存储、核心看板、POC 评分 端到端延迟与丢失率达标;三个核心指标可复算 数据平台
治理 61–90 天 指标目录、owner、审批流、权限矩阵、复盘 指标口径无争议;两个决策被数据改变 数据治理委员会

0–30 天:先定义,不选工具。 选两个必须回答的问题(例如“新用户首周激活的瓶颈在哪”“哪个渠道带来的留存最高”),写 20–30 个核心事件,确定身份规则与隐私边界。事件字典要有冻结期,否则第二周就会被改成“先上都埋”。

31–60 天:用真实数据做 POC。 选覆盖率达 80% 的端,跑通采集、管道、存储、三个核心看板。要求每家厂商用客户自己的事件表与指标演示,记录口径差异。POC 的出口不是“演示成功”,而是“三个指标能对上”。

61–90 天:做治理,不做扩张。 建指标目录、owner、审批流、权限矩阵;做一次复盘,确认两个决策是否被数据改变。第 90 天的交付物不是“全公司推广”,而是“一套可复制的模板 + 一份 12 个月路线图”。

90 天最容易失败的三个点:第 2 周事件字典被业务改成“先上都埋”;第 6 周发现客户端版本覆盖不足;第 9 周没有人愿意当指标 owner。对应的预防动作是:字典变更有冻结期;POC 先选覆盖率达 80% 的端;指标 owner 写进绩效,而不是口头指定。

11.6.1 从 90 天到 12 个月#

阶段 时间 重点 退出条件
试点 0–90 天 两个决策、20–30 个核心事件、三个指标对账 指标可复算;业务愿意用
扩展 3–6 个月 多端覆盖、身份图、权限、指标目录、第二个业务线 事件复用率 ≥ 50%;口径争议下降
平台化 6–12 个月 成本核算、SLA、实验/人群/引导打通、数据契约 单位成本可解释;迁移演练通过

第 4–6 个月最容易出现“第二套口径”:新业务线带着自己的事件命名进来,绕过既有 taxonomy。治理动作不是“禁止”,而是“提供更快的合规路径”:模板、自动校验、预置指标、审批 SLA。治理如果比绕过更慢,所有人都会绕过。

11.7 组织、反模式与成功度量#

组织。 埋点平台不是数据部门一个团队的事。建议的 RACI:

角色 负责 咨询 知会
产品/业务 定义决策问题、事件语义、指标 owner 数据平台 管理层
数据平台 采集、管道、存储、权限、SLA 安全/法务 业务
数据分析 指标口径、看板、复盘 产品/数据平台 管理层
安全/法务 数据区域、DPA、PII、删除 数据平台 采购
采购/财务 合同、计价、续约 数据平台/法务 管理层

为什么组织失败多于工具失败。 埋点平台的每一次错误,几乎都能追溯到“没有人对这件事负责”:事件没有 owner,所以没人敢删;指标没有审批,所以出现两个“活跃用户”;权限没有边界,所以分析师能导出全量明细;合同没有退出条款,所以续约时只能接受涨价。工具能提供能力,但不能替代责任分配。一个没有数据治理委员会的公司,换任何工具都会回到同一个问题。

六个反模式:

反模式 症状 后果 替代做法
先买工具后定指标 演示很漂亮,上线后没人用 工具变成报表仓库 先写三个决策问题
全埋点替代设计 “先都采,以后再定义” 事件爆炸、口径混乱 核心事件手动定义,长尾再 autocapture
只看 DAU 所有汇报只有一个数 无法解释增长质量 激活、留存、付费、负反馈一起看
把 CDP 当分析 能发人群,但说不清为什么 行动没有依据 分析与激活分工,共用身份
把回放当证据 看几个 session 就下结论 个案代替总体 回放用于生成假设,用数据验证
AI 自动结论 不看口径、不看样本 更快地生产错误 结论必须可溯源到事件与查询

成功度量:

指标 定义 90 天目标
核心事件覆盖率 已验收的核心事件 / 计划核心事件 ≥ 90%
验收通过率 一次验收通过的事件 / 提交验收的事件 ≥ 80%
事件复用率 被 2 个以上看板/团队使用的事件占比 ≥ 50%
指标口径争议数 每季度需要重新定义的指标数 下降 50%
查询采用率 周活跃分析用户 / 目标用户 ≥ 40%
洞察到行动周期 从结论到人群/实验/引导上线的时间 ≤ 2 周
数据延迟 核心事件从产生到可查询的 p95 按 SLA 达标
成本/事件 月度总成本 / 有效事件数 季度下降 10%
图 11-1 · 控制力—分析深度矩阵:位置为示意,不是厂商评分
图 11-1 · 控制力—分析深度矩阵:位置为示意,不是厂商评分

判断:选型的终点不是“选了谁”,而是“组织是否具备了持续定义、验收、复盘事件的能力”。工具可以换,这套能力换不掉。

11.8 季度复盘:让选型变成持续动作#

选型不是一次性采购,而是每季度一次的复盘。建议固定四个问题:第一,过去 90 天有哪些决策是因为数据改变或加速的?第二,哪些指标被重新定义过,为什么?第三,哪些事件没有人用,能否下线?第四,账单与事件量的关系是否可解释?四个问题都答不上来,说明平台正在退化成报表仓库。

复盘要有输出:下季度要下线的事件清单、要补的验收规则、要谈的合同条款、要做的迁移演练。没有输出的复盘,会变成“大家辛苦了”的例会。

把“退出演练”放进年度计划:每年选一个非核心业务,尝试把事件、身份、人群、查询迁移到备选方案,记录时间、成本与数据差异。演练不是为了真的换厂商,而是为了知道换的时候会发生什么。不能带走的资产,在合同签字那天就已经失去了。

UBA RESEARCH / 11查看全部引用 ↗