# UBA RESEARCH · 埋点分析平台全景研究 > 30+ 商业平台、15+ 中国公司、14 个开源项目；埋点、行为分析与用户经营平台的产品、方案、核心模块与中国实践深度研究。 > > OCT 2026 · 深度版 · 数据截至 2026-10-18 > 97,771 字 · 384 条引用 · 12 章 --- # 00 · 执行摘要：埋点分析的第二次分层 > 埋点平台正在从“事件工具”变成“行为数据基础设施”。真正的分水岭不是图表多少，而是事件语义、身份解析与数据主权归谁。 ## 0.1 一句话结论 **埋点分析平台已经从“页面与事件工具”演化为“行为数据基础设施”。** 2023–2026 年的并购、涨价与架构迁移证明：只做图表的工具会被套件吞掉，只做采集的管道会被仓库替代，只做 SaaS 的平台会被数据主权挡在门外。真正稀缺的能力不是“能看漏斗”，而是**可信的事件语义、可解释的身份解析、能落地的行动能力，以及退出时能带走的资产**。 ## 0.2 十个判断 **判断一：市场没有全能冠军，只有三种交付形态。** SaaS 套装、warehouse-native/composable、私有化/自建，各自解决不同约束：前者卖开箱即用，中者卖数据不出域与指标复用，后者卖控制力与合规。用一张功能表横向打勾，会把交付方式、数据主权和三年总成本全部遮掉。先画“缺口图”，再选产品。 **判断二：产品分析的护城河，正在从查询界面转向事件语义与行动能力。** 当每家都能做漏斗、留存和路径，差异就落到 taxonomy 能否治理、身份能否合并、洞察能否直接变成人群、实验和应用内引导。Amplitude 在 2023–2026 年连续收购 Command AI、Kraftful、InfiniGrow，并接手 Statsig 的品牌与客户，买的都不是“更多图表”，而是行动端与实验入口 [来源](https://amplitude.com/blog/amplitude-and-statsig-partnership)。Contentsquare 把 Heap 收进体验分析套件，也是同一逻辑 [来源](https://contentsquare.com/press/contentsquare-completes-acquisition-heap/)。 **判断三：Warehouse-native 不是架构时尚，是数据主权与口径统一的交易。** 真正的 warehouse-native 把指标计算下推到客户数仓，数据不出域；而“仓库连接器”只是把数据导入厂商平台，两者架构、成本与退出方式完全不同。Amplitude 的 Snowflake Native 与 Mixpanel 的 Warehouse Connectors 常被混为一谈，但前者是计算下推，后者是数据搬运 [来源](https://amplitude.com/releases/warehouse-native-ga) [来源](https://docs.mixpanel.com/docs/tracking-methods/warehouse-connectors)。没有数仓口径的公司，上 warehouse-native 是空中楼阁。 **判断四：全埋点降低了采集成本，却把成本转移到治理。** autocapture 能快速覆盖点击与页面浏览，但无法自动产生业务语义。事件越多，命名、去重、废弃、血缘和验收的负担越重。字节、B 站、网易云音乐的公开实践都指向同一件事：真正难的不是“把事件收上来”，而是“让每条事件有 owner、有版本、有成本” [来源](https://zhuanlan.zhihu.com/p/644137017)。埋点治理不是规范文档，是平台能力。 **判断五：身份解析是 UBA 最容易被低估的失败点。** 匿名 ID 与登录 ID 的合并顺序、跨端、家庭/企业账号、登出与隐私选择，都会改变漏斗和留存。很多“数据不准”不是采集丢失，而是身份合并错了，且不可回滚。平台应该把合并规则、置信度和回滚能力暴露给使用者，而不是藏在 SDK 里。身份图不是技术细节，是分析结论的一部分。 **判断六：中国市场的竞争单位是“交付 + 行业模板 + 私有化”，不是功能。** 神策、GrowingIO、火山引擎 DataFinder、阿里云 Quick Tracking 的差异，往往不在图表，而在部署方式、行业 know-how、数据合规与服务能力。据公开融资记录，2022 年之后未发现同量级的大额融资；这不等于没有发生，只说明公开披露稀缺。厂商叙事从“增长”转向 CDP、信创，再转向 Agent。买产品的同时，也在买母公司的存续能力与交付队伍。公开价格从神策云市场的 54 万–72 万元/年，到 Quick Tracking 标准版 880–13,500 美元/月、专家版 1,600–14,000 美元/月，计价锚点完全不同 [来源](https://market.aliyun.com/detail/cmgj00047786.html) [来源](https://www.alibabacloud.com/help/zh/quick-tracking/latest/collection-and-analysis-version-and-specifications)。 **判断七：开源的边界不是代码，而是运维、合规与规模。** PostHog、Snowplow、Matomo 能覆盖大量标准需求，但升级、备份、监控、数据保留、审计与合规责任仍然在你自己身上。开源能省 license，不会自动省人力；它把“采购问题”变成了“组织能力问题”。真正适合开源自建的，是已有平台团队、能把事件模型与权限体系当作长期资产的公司。 **判断八：CDP、实验、回放都在侵入 UBA，但不会替代分析。** 它们共享事件与身份，却服务不同决策：CDP 解决“触达谁”，实验解决“哪个更好”，回放解决“为什么”。平台整合是产品趋势，不是能力等价。把 CDP 当分析工具，最后会得到一个“能发人群、但不能解释为什么”的系统；把回放当证据，也会把个别会话误当成总体结论。 **判断九：AI 让查询更容易，也让错误答案更便宜。** NLQ、自动洞察、Agent 降低了使用门槛，但如果事件语义、指标口径和权限没有治理，AI 只会更快地生成看起来合理的错误结论。2026 年各家都在讲 Agent 与 MCP：Amplitude、Mixpanel、Pendo、Contentsquare 都试图让行为数据成为 Agent 的默认上下文。真正的竞争不是“谁的模型更强”，而是“谁的数据语义更可信、权限更细、溯源更完整”。 **判断十：选型的核心是退出能力，不是功能清单。** 事件元数据、历史查询、人群定义、实验记录和原始明细能否导出，决定了你三年后是被锁定，还是能换一条路线。合同要写清：数据导出范围、迁移支持期、控制权变更终止权、AI 训练条款、数据区域与删除机制。不能带走的资产，等于没有。 > **判断**：未来三年，UBA 市场不会出现一个“统一所有场景”的赢家。更可能的格局是：少数平台占据事件语义与行动层，数仓承担计算与治理，开源/私有化方案吃掉对数据主权敏感的长尾。 ### 2023–2026 的五个结构性变化 **第一，整合发生在“行动端”，不是“图表端”。** Amplitude 买 Command AI、Kraftful、InfiniGrow，接手 Statsig 的品牌与客户；Pendo 买 Zelta、Forwrd、Chisel；Contentsquare 买 Heap 与 Loris；Mixpanel 买 DoubleLoop。买方要的是引导、反馈、实验、归因、指标树这些能改变用户行为的能力，而不是再做一个漏斗图。结果是“产品分析”与“增长工具”的边界越来越模糊，纯分析工具的议价权越来越弱。 **第二，计价单位从 MAU/MTU 迁移到事件量，再迁移到“结果”。** Mixpanel 2025 年 2 月后把 Growth 套餐改为事件计价；Amplitude 取消席位费、按事件量收费；Pendo 仍按 MAU；Heap/Contentsquare 按会话。到 2026 年，厂商又开始卖“Agent 订阅”“AI 工作量”。计价单位的变化会直接改变客户行为：按事件收费会抑制全埋点，按会话收费会鼓励回放，按 MAU 收费会把收入绑在客户的活跃用户上。 **第三，架构从“单引擎”走向“多引擎 + 湖仓”。** 快手把百 PB、200+ 集群从 ClickHouse 迁到 Doris/Bleem；小红书用 Iceberg + StarRocks 替换自研存算分离 ClickHouse；京东用 Hudi 收拢 Lambda 双链路。ClickHouse 没有消失，而是退到“明细加速层”；Doris/StarRocks 承担高并发与 Join；湖仓承担长期归档与多引擎复用。选型问题从“哪个引擎最快”变成“哪类负载放在哪一层”。 **第四，中国市场的默认交付从 SaaS 变成私有化。** 数数官方称 80% 客户选择私有化；DataFinder 的云托管模式“相比私有化便宜 20% 左右”；Quick Tracking 国际站公开按事件量计价，但国内项目仍以询价与部署方案为主。PIPL、数据出境规则与等保把“数据在哪里”变成一票否决项，SaaS 的规模效应在中国没有跑通。 **第五，AI 从“问答”走向“代理”，但可验证性没有同步提升。** 2026 年，Amplitude、Mixpanel、Pendo、Contentsquare、PostHog 都在做 MCP 或 Agent；能力从“解释图表”扩展到“定时监控、生成看板、建人群、发起实验”。但 Agent 的每一步都依赖事件语义、指标口径、权限与审计。没有这些，Agent 只是把错误答案的生产速度提高了一个数量级。 ## 0.3 三个反常识 **反常识一：开源不一定更便宜。** 软件许可可以降到零，但升级、备份、监控、权限、审计、合规与故障响应都要自己承担。按 1 个平台工程师年成本约 17.7 万美元估算，3 人团队一年约 53 万美元，通常已经超过中型公司三年的 SaaS 订阅 [来源](https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm)。开源适合“把省下的钱变成长期能力”的公司，不适合“只想省 license”的公司。 **反常识二：私有化不一定更安全。** 私有化解决的是“数据在哪里”，不解决“谁能看、谁能改、谁能导出”。没有行级权限、审计日志、密钥管理和删除验证的私有化集群，只是把风险从厂商机房搬到了自己的机房。安全评估要看控制，不看部署位置。 **反常识三：免费不一定总成本低。** GA4 免费，但采样、阈值、留存上限与 BigQuery 导出限制会改变你能回答的问题；友盟、百度统计免费，但数据导出、迁移与二次使用受限。免费产品的成本往往以“能力边界”和“数据主权”支付，而不是以账单支付。 ## 0.4 给三类读者的建议 **给 CEO / 产品负责人：** - 不要把“看板数量”或“事件数量”当 KPI。把“有决策的分析占比”“洞察到行动的周期”“埋点验收通过率”当 KPI。 - 先选一个业务做 90 天试点，用真实指标验证“可信度”，再谈全公司推广。不要先买最贵的套件，再补数据治理。 - 预算按三年 TCO 算：license 只是第一行，实施、数仓、回放留存、合规、迁移和人力才是大头。 **给数据 / 平台负责人：** - 先建事件 taxonomy、身份规则、会话口径和验收机制，再选分析工具。工具可以换，语义资产不能重来。 - 把“事件定义”从代码注释里拿出来，变成有 owner、有版本、有血缘的元数据。没有 metadata 的埋点平台，只是一个更贵的日志查询器。 - 对 AI 功能保持“可溯源”要求：每个结论要能回到事件、口径、时间窗口和权限边界。 **给架构师 / 技术选型：** - 先分清“数据在哪里计算”：厂商 SaaS、客户数仓、私有化集群，还是混合。架构选择要服从数据主权，不服从 benchmark。 - 不要默认实时。把 SLA 分成秒级、分钟级、T+1 三档，只有真正影响决策的链路才值得付实时成本。 - 为退出设计：原始明细、事件元数据、查询历史、人群定义、实验记录都要有导出格式和校验方法。 ### 采购的五个红线 1. **数据区域写进合同，不写进 FAQ。** 包括生产、备份、日志、AI 推理与子处理者所在区域；跨境路径要能画出来。 2. **事件元数据必须可导出。** 不只是原始明细，还包括事件定义、属性类型、owner、版本、废弃状态与血缘。 3. **身份合并规则必须可解释、可回滚。** 至少要能回答“这两个 ID 为什么被合并”“合并后如何拆分”。 4. **AI 训练条款单独确认。** 客户数据是否用于训练、是否可关闭、关闭后是否影响功能，必须白纸黑字。 5. **退出演练。** 在签约前做一次小规模导出与校验，确认人群、查询、实验记录和权限能迁移。 ## 0.5 推荐路线 | 公司阶段 | 典型约束 | 推荐形态 | 先做什么 | 不要做什么 | |---|---|---|---|---| | 初创 / 小团队 | 预算低、无数据平台 | SaaS 套装或轻量开源 | 统一 20–30 个核心事件、周报与漏斗 | 自建管道、上重型 CDP | | 成长期 / 已有数仓 | 口径混乱、跨端身份 | warehouse-native + 轻量采集 | 事件契约、身份图、指标语义层 | 先买 AI 功能、后补治理 | | 中大型 / 数据敏感 | 合规、私有化、多业务线 | 私有化或混合架构 | 权限、审计、数据区域、成本核算 | 把 SaaS 当默认、把实时当标配 | | 平台型 / 超大规模 | 成本、SLA、多租户 | 多引擎 + 湖仓 + 自建语义层 | 成本货币化、分级存储、数据契约 | 单引擎押注、无退出设计 | **最务实的组合**：统一事件模型与身份层 + 可替换的采集 SDK + 数仓/OLAP 承担计算 + 分析体验按团队成熟度选择。不要试图用一个产品解决“采集、存储、分析、行动、治理”五件事；能解耦的尽量解耦，不能解耦的（事件语义、身份、权限）必须自己掌握。 ## 0.6 本报告的局限 - 厂商架构与定价多为商业机密，本报告只能核实“官方是否公开 + 文档是否给方法”，不能替代真实数据压测与合同谈判。 - 价格是公开样本或量级估算，不是报价。中国厂商的成交价与公开标价往往相差很大。 - 中国大厂内部平台的公开资料高度不均，部分平台名、架构与数字来自演讲、专利或二手整理，报告逐条标注证据等级。 - AI 功能变化极快，本报告只描述截至 2026-10-18 的公开状态，不预测路线图。 - 本报告不是法律意见。涉及 GDPR、PIPL、数据出境与行业监管时，应由法务与安全团队做最终判断。 ## 阅读路径 - 只想决策：读第 00、11 章。 - 做产品选型：读第 01–07 章与第 11 章。 - 做技术方案：读第 07–10 章。 - 看中国市场：读第 04–05 章。 ## 参考来源 - [BLS — Software Developers](https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm) - [Amplitude — Q2 2026 Financial Results](https://investors.amplitude.com/news-releases/news-release-details/amplitude-announces-second-quarter-2026-financial-results) - [Amplitude — Amplitude and Statsig](https://amplitude.com/blog/amplitude-and-statsig-partnership) - [Contentsquare — Completes Acquisition of Heap](https://contentsquare.com/press/contentsquare-completes-acquisition-heap/) - [Amplitude — Warehouse Native GA](https://amplitude.com/releases/warehouse-native-ga) - [Mixpanel — Warehouse Connectors](https://docs.mixpanel.com/docs/tracking-methods/warehouse-connectors) - [Mixpanel — Pricing](https://docs.mixpanel.com/docs/pricing) - [Heap — Pricing](https://www.heap.io/pricing) - [Pendo — Pricing](https://www.pendo.io/pricing/) - [B 站 — 埋点分析平台的构建之路](https://zhuanlan.zhihu.com/p/644137017) - [神策数据 — 阿里云云市场](https://market.aliyun.com/detail/cmgj00047786.html) - [阿里云 — Quick Tracking 版本规格](https://www.alibabacloud.com/help/zh/quick-tracking/latest/collection-and-analysis-version-and-specifications) - [火山引擎 — DataFinder 计费规则](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/VolcanoEngineGrowthAnalysis-ProductServiceBillingSettlementRules?lang=zh) - [GrowingIO — 公司介绍](https://www.growingio.com/about) - [ThinkingAI — 品牌升级](https://www.thinkingai.cn/blog/b8e1a4f6/) - [PostHog — GitHub](https://github.com/PostHog/posthog) - [Snowplow — Documentation](https://docs.snowplow.io/) - [Matomo — Documentation](https://matomo.org/docs/) - [ClickHouse — Documentation](https://clickhouse.com/docs) - [Apache Doris — Documentation](https://doris.apache.org/docs/) - [StarRocks — Documentation](https://docs.starrocks.io/) - [PIPL 全文](https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm) - [促进和规范数据跨境流动规定](https://www.cac.gov.cn/2024-03/22/c_1712776611775634.htm) --- # 01 · 市场地图：谁在卖“看见用户”的能力 > 七类玩家、三种交付形态、一个共同瓶颈：事件语义、身份与数据主权，正在决定谁能留下。 2026 年 10 月，把 Amplitude、Mixpanel、Heap、Pendo、FullStory、PostHog、神策、ThinkingAI 放进同一张功能表，仍能得到一张看起来合理的对比图。这张图会误导采购。 不是功能写得不准，而是它们已经不在同一个市场里卖同一种东西。Amplitude 卖“事件语义 + 实验 + 引导”的平台，Mixpanel 卖“分析师当天就能查出答案”，Heap 卖“不改代码先收数据”，FullStory 卖“可回放的会话记录”，神策卖“私有化系统 + 一年服务”，PostHog 卖“按量计价的开源栈”。同样的漏斗图，背后是不同的数据模型、账单与签字人。 > **判断**：2026 年的 UBA 已经不是“一个市场”，而是三个不相通的交付市场叠在一起：SaaS 套装、warehouse-native/composable、私有化/自建。把它们放进同一张功能表比价，是当前最常见的采购错误。分水岭不是功能数量，而是事件语义、身份与数据主权归谁。 本章做七件事：划清 UBA 与相邻品类的边界；说明证据规则；画出七类玩家；列出 2023–2026 的五个结构性变化；解释为什么没有一个可信的市场规模数字；拆开买家与预算归属；给出全书的判断框架。后面十章都在这张地图上展开。 ## 1.1 定义与边界：事件是单位，不是页面 **UBA 的最小单位是事件，不是页面，也不是用户。** 一条可用的事件至少有四部分：谁（身份）、在什么上下文（设备、渠道、会话、实验组）、做了什么（事件名与属性）、之后发生了什么（后续事件序列）。缺一项，分析就会退化成“页面点击统计”。 本报告把 UBA 当伞形概念：包含以事件分析为核心的产品分析（Amplitude、Mixpanel、Pendo 等），也包含以会话回放与体验度量为核心的体验分析（FullStory、Contentsquare 等）。单独说“产品分析”时，指前者；说“体验分析”时，指后者。全埋点（autocapture）指客户端自动采集，无埋点（tagless）多指网络层采集；身份解析（identity resolution）是 canonical 术语，ID-Mapping、OneID、Identity Graph 是不同厂商的别名。术语统一后，再看产品差异。 这条定义把 UBA 与四个邻居分开。 | 概念 | 回答的问题 | 最小单位 | 代表产品 | 与本报告的关系 | |---|---|---|---|---| | UBA | 谁在什么上下文做了什么，之后发生了什么 | 事件序列 + 身份 | Amplitude、Mixpanel、Heap、Pendo、PostHog、神策 | 研究对象 | | 测量云 | 流量从哪来、转化到哪、广告是否有效 | 会话、事件、server call、数据行 | GA4/360、Firebase、Adobe Analytics/CJA | 采集入口与归因，常被误当全量事件层 | | CDP 与管道 | 身份如何合并、事件送到哪些系统 | 身份与目的地 | Segment、RudderStack、Snowplow、Jitsu | 上游或下游，不是分析替代品 | | BI 与指标平台 | 指标是多少、为什么变 | 指标、维度、报表 | 企业 BI 套件、指标平台 | 在指标层汇合，事件层不重合 | | UEBA | 哪个账号、设备或实体的行为像风险 | 实体与风险分 | 安全运营套件中的 UEBA 模块 | 边界外，不共享数据模型与买单人 | **测量云是采集入口，不是分析终点。** GA4 免费，但标准版留存只有 2 或 14 个月，单次探索查询上限 1,000 万事件，BigQuery 每日导出上限 100 万事件（[留存说明](https://support.google.com/analytics/answer/7667196?hl=en)、[采样说明](https://support.google.com/analytics/answer/13331292?hl=en)、[BigQuery 导出](https://support.google.com/analytics/answer/9358801?hl=en)）。它更像“采样后的样本仓库”。360 官网不挂报价，第三方在 2022 年给出的口径是起价 5 万美元/年、含 2,500 万事件/月，只能当量级参考（[360 计价说明](https://www.cardinalpath.com/blog/ua-360-vs-ga4-360-pricing-model)）。Adobe 把测量做成合同：Analytics 按 server call 卖，CJA 按数据行卖，Foundation Pack 自 2024 年 1 月 1 日起不再销售、升级或续约（[AA 产品说明](https://helpx.adobe.com/legal/product-descriptions/adobe-analytics.html)、[CJA 产品说明](https://helpx.adobe.com/legal/product-descriptions/customer-journey-analytics.html)）。 **CDP 的主键是身份与目的地，不是行为序列。** 它解决“这个人是谁、事件该送到哪”，不解决“为什么转化率掉了”。Segment 不做漏斗与留存；在 Twilio 2026 年二季度电话会里，主角已经是通信与 AI，Segment 不在可见叙述中（[财报电话会](https://www.fool.com/earnings/call-transcripts/2026/08/13/twilio-twlo-q2-2026-earnings-call-transcript/)）。反方向也在发生：Mixpanel 的 Warehouse Connectors 把 Snowflake、BigQuery、Databricks、Redshift 的数据导入分析平台（[连接器文档](https://docs.mixpanel.com/docs/tracking-methods/warehouse-connectors)）。管道与分析互相借用入口，但账本仍然分开。 **BI 的主键是指标，UBA 的主键是事件。** BI 回答“这个数是多少、为什么变”，UBA 回答“谁做的、在什么路径上做的、下一步对谁做什么”。两者在指标层汇合：IDC 统计的 2024 年中国商业智能与分析软件市场为 10.6 亿美元，2024 年下半年本地部署占 85.9%、同期公有云 14.1%（[IDC 口径](https://www.secrss.com/articles/81495)）。这个数字常被拿来当“中国 UBA 市场”，但它的类目是 BI 与分析软件，不是埋点分析订阅。 **UEBA 是另一个学科。** 它以账号、设备、实体为对象，输出风险评分，服务于安全运营；UBA 以产品行为为对象，输出是转化、留存与人群。两者共享“行为”这个词，不共享数据模型、买单人与合规边界。本报告不把 UEBA 计入市场。 边界不是永久的。体验分析在往行动端走：FullStory 2025 年底收购 Usetiful，第一次并购，买的就是“引导”（[收购](https://markets.businessinsider.com/news/stocks/fullstory-acquires-usetiful-turning-digital-insights-into-decisive-actions-1035476979)）；Contentsquare 2026 年 10 月发布 AI-first 平台，把回放、旅程、对话与实验装进同一套界面（[平台发布](https://contentsquare.com/press/new-ai-first-experience-platform/)）。测量云也在扩边界：GA4 在 2026 年 5 月 13 日新增 AI Assistant 流量渠道，把 ChatGPT、Gemini、Claude 的引荐流量单列（[GA4 更新](https://support.google.com/analytics/answer/9164320?hl=en)）。品类名越来越不能用来做短名单，场景与交付形态才可以。这也是为什么本报告不按行业切市场地图：同一串事件在电商的主键是订单，在 SaaS 是账户，在游戏是角色，在金融是客户；主键不同，对事件模型、身份与合规的要求也不同。 ## 1.2 研究方法与证据等级 **证据等级不是学术装饰，它决定一句话能不能进预算。** 本报告把来源分三层：A 级是官方定价页、产品文档、财报、监管原文、招标原文；B 级是官方新闻稿、官方博客、厂商案例；C 级是第三方读数、二手转述与公开资料不足。价格抓取窗口为 2026 年 10 月 13 日至 18 日，所有“当前”判断以 2026 年 10 月 18 日为界。金额未注明均为美元，人民币按 1 美元 ≈ 7.1 元折算，仅用于量级比较。 | 等级 | 定义 | 本报告怎么用 | 典型样本 | |---|---|---|---| | A | 官方定价、文档、财报、监管或招标原文 | 直接引用数字与条款，可复算 | 深交所成交公示、Amplitude 财报 | | B | 官方新闻稿、官方博客、厂商案例 | 引用事件、日期与产品状态，不引用效果数字 | 收购公告、AI 功能发布 | | C | 第三方读数、二手转述、资料不足 | 只作量级与方向，或标“待核实” | 118 亿美元、576 美元/月、DataFinder 单价 | 四条处理规则，贯穿全书。 **第一，官方口径与第三方口径并列，不取平均。** 同一份 Contentsquare 交割公告里，Heap 的客户数一处写“超过 10,000 家公司”，另一处写“超过 1,000 家企业”（[交割公告](https://contentsquare.com/press/contentsquare-completes-acquisition-heap/)）。Amplitude 的客户数至少有三个口径：FY2025 财报 4,700+、2026-01 收购稿 4,500+、安全页 2,000+（未标日期，疑为旧口径，[FY2025 财报](https://amplitude.gcs-web.com/news-releases/news-release-details/amplitude-announces-fourth-quarter-and-fiscal-year-2025)）；TalkingData 的接入 App 数在 45 万与 10 万之间差 4.5 倍。这些数字只能判断“这家公司还在服务大客户”，不能用于份额。 **第二，价格只当锚点，不当报价。** 第三方样本仍有时间错位：Vendr 对 Amplitude 的说明仍按 MTU 分段，而官网已经改回事件计价；对 Pendo 的页面仍用 Starter/Growth/Portfolio 的旧套餐名，官网已卖 Base/Core/Ultimate（[Vendr Amplitude](https://www.vendr.com/marketplace/amplitude)、[Vendr Pendo](https://www.vendr.com/marketplace/pendo)）。第三方中位数是谈判起点，不是预算。 **第三，状态必须带日期。** 易观方舟没有停服公告，但站点版权停在 2022 年，独立域名在 2026 年 10 月已无法解析，只能标“待核实”（[易观数科](https://www.analysysdata.com/)）。Contentsquare 的公开文档没有列明数据区域，Quantum Metric 的定价与留存不公开，火山引擎 DataFinder 的单价页在本次抓取中被 403 拦截，三处都写“待核实”，不用推测补全（[Contentsquare 信任中心](https://trust.contentsquare.com/)、[DataFinder 计费](https://www.volcengine.com/docs/84129/1261816)）。 **第四，不做四件事。** 不引用未读到的付费报告全文；不做客户访谈；不做统一压测；不拿经销商折扣当公开价。因此本报告给规模区间而不给单点，给价格锚点而不给“到手价”，给状态日期而不给“长期有效”。这不是谨慎，是边界：越过大样本的结论，在采购桌上会立刻失效。 证据等级会改变结论。只看 P&S 的 118 亿美元，会得出“市场足够大、独立厂商有空间”；把六家商业 UBA 厂商的收入底向上加总，只有 11–15 亿美元，结论就变成“头部靠并购扩 ARR，长尾靠区域与私有化”。同一组事实，两种战略含义。第 1.5 节展开这笔账。 ## 1.3 七类玩家：核心资产、买单人与计价锚点 分类标准不是“产品像不像”，而是三件事是否一致：核心资产是什么、谁签字、按什么收费。三者一致，才是一类玩家；不一致，就只是同一张导航栏下的不同生意。 | 类别 | 代表 | 核心资产 | 买单人 | 计价锚点 | 2026 状态 | |---|---|---|---|---|---| | 国际产品分析 | Amplitude、Mixpanel、Heap/Contentsquare、Pendo | 事件语义、实验、引导、回放 | 产品、增长、数据；中大型企业 | 事件、会话、MAU | 平台化完成，靠并购补行动端；Amplitude 2026 Q2 [ARR 4.10 亿美元](https://investors.amplitude.com/news-releases/news-release-details/amplitude-announces-second-quarter-2026-financial-results)、同比 22% | | 体验分析 | FullStory、LogRocket、Glassbox、Quantum Metric | 会话重建、前端上下文、可举证记录 | 产品、UX、工程、客服、合规 | 会话、留存、模块 | 向行动层与 Agent 扩；私有化与单租户构成差异 | | 测量云 | GA4/360、Firebase、Adobe AA/CJA | 采集入口、广告归因、AEP 身份 | 市场、电商、企业数据 | 免费、事件、server call、行 | GA4 免费换生态；AA 合同性退场，CJA 接棒 | | CDP 与管道 | Segment、RudderStack、Snowplow、Jitsu | 事件管道、身份图、目的地 | 数据平台、增长工程 | MTU、事件、许可 | 管道同质化，被通信云与 UBA 两头挤压 | | 开源一体化 | PostHog、Matomo、Plausible、Countly、OpenReplay | 代码、可自托管、透明计价 | 工程、产品、预算敏感组织 | 事件、录制、许可 | PostHog 2025 年两轮融资；license 分化 | | 中国商业化 | 神策、GrowingIO、诸葛、ThinkingAI、TalkingData、DataFinder、Quick Tracking、友盟、百度统计 | 私有化交付、行业模板、合规资质 | 中大型企业数据与业务部门；中小开发者 | 项目、事件、MTU、免费 | 独立厂商叙事转向 Agent；云厂商配套化 | | 大厂自建 | 字节流量平台、阿里 UT/SPM、腾讯灯塔、美团指标平台、滴滴、小红书、B 站、快手、京东、网易 | 埋点元数据、成本治理、指标语义 | 内部业务线 | 内部结算、成本分摊 | 离开 ClickHouse 单引擎；指标层吸收事件分析 | ![图 1-1 · UBA 市场七类玩家](/assets/diagrams/market-map.svg) 图 1-1 把七类玩家排成七张卡片，中间放着同一个资产：事件、身份与语义。它不回答“哪家最好”，只提醒一件事：七类玩家卖的表层能力不同，争夺的底层资产相同——谁能定义这三件事，谁就掌握解释权。 读这张表，有三条结论。 **第一，计价透明度与议价空间成反比。** 事件计价的市场最透明：PostHog 公开阶梯价，Mixpanel 公开 10M 事件 840 美元/月，阿里云 Quick Tracking 公开 1 亿事件 1,500 美元/月（[PostHog 计价](https://posthog.com/product-analytics/pricing)、[Mixpanel 定价](https://mixpanel.com/pricing/)、[Quick Tracking 规格](https://www.alibabacloud.com/help/zh/quick-tracking/latest/collection-and-analysis-version-and-specifications)）。会话与 MAU 市场最不透明：FullStory、Pendo、Heap 只给“定制”。项目制市场几乎没有公开价：神策在阿里云云市场挂 54 万–72 万元/年作价格锚，页面显示近 180 天成交 0 笔（[云市场](https://market.aliyun.com/detail/cmgj00047786.html)）。越不透明，折扣空间越大，买方越需要把报价拆成“量 × 单价 × 留存 × 模块”。 **第二，三类玩家不靠 UBA 赚钱。** 测量云靠广告与云生态，GA4 免费、360 按事件量收（[360 计价](https://www.cardinalpath.com/blog/ua-360-vs-ga4-360-pricing-model)）；云厂商靠云资源，DataFinder 的云托管据官方文档比私有化便宜约 20%，且只面向部分企业开放（[云托管说明](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/IntroductiontoCloudHostingModel?lang=zh)）；大厂自建靠内部结算，不对市场报价。它们的存在把独立 UBA 的价格天花板压住了。独立厂商能守的，主要是私有化交付、行业咨询与口径治理——这些是标准化云产品不容易覆盖的部分。 **第三，同一类内部的分化，大于类与类之间。** Amplitude 与 Mixpanel 都按事件卖，一个卖实验与治理，一个卖自助体验；Glassbox 与 LogRocket 都卖回放，一个卖合规记录与本地部署，一个卖工程排障与美国 SaaS；神策与 ThinkingAI 都做私有化，一个卖“全家桶 + 陪跑”，一个卖“Agent + 游戏行业”。用类别做短名单，会漏掉这些差异；用场景做短名单，才排得对。 > **判断**：七类玩家的差别，最终落在三件事：数据主副本在哪、按什么计价、退出时能带走什么。功能表趋同不等于产品趋同；用类别做短名单，会漏掉同类的分化，也会把“不在同一张报价单上”的玩家放进同一轮 POC。 ## 1.4 2023–2026：五个结构性变化 五个变化都不是“功能更新”。它们分别改写了计价、产品边界、交付方式、合规门槛与 AI 的权限，且时间都可以核对。 **第一，计价换尺。** Amplitude 在 2023 年 9 月从事件转向 MTU，2024 年 9 月推出按 MTU 计价的 Plus，2026 年 4 月还同时列两种单位，2026 年 9 月才把 MTU 从套餐卡移除、回到纯事件计价（[第三方定价史](https://votefirst.app/en/pricing/amplitude)、[官方定价](https://amplitude.com/pricing)）。Mixpanel 把 MTU 降级为 legacy billing，2 万美元/年起，只在追踪超过 10 万用户或 500 万月事件时由销售介入（[MTU 说明](https://docs.mixpanel.com/docs/pricing/legacy-mtu-billing)）。Adobe 更彻底：Analytics 按 server call 卖，CJA 按数据行卖（[AA 产品说明](https://helpx.adobe.com/legal/product-descriptions/adobe-analytics.html)）。计价单位是收入模型，不是财务细节；换尺是买方的隐性风险，合同只写“按届时官网价续约”，厂商换单位时买方没有还手之力。 **第二，并购补行动端，不补图表。** Amplitude 买 Command AI（引导）、Kraftful（定性反馈）、InfiniGrow（营销归因），并在 2026 年 5 月接手 Statsig 的品牌、产品与客户（[Command AI](https://amplitude.com/blog/amplitude-acquires-command-ai)、[Kraftful](https://amplitude.com/blog/amplitude-acquires-kraftful)、[InfiniGrow](https://www.amplitude.com/press/amplitude-acquires-infinigrow)、[Statsig 交易](https://amplitude.com/blog/amplitude-and-statsig-partnership)）。Pendo 在 18 个月内完成第四笔收购（Zelta、Forwrd、Product Collective、Chisel），2026 年 2 月买下 Chisel Labs（[Chisel 收购](https://www.pendo.io/news/pendo-acquires-chisel-labs-to-help-product-teams-build-better-and-faster-with-agentic-ai/)）。Contentsquare 把 Heap 变成产品分析模块，FullStory 买 Usetiful，Mixpanel 买 DoubleLoop 补指标树（[Heap 交割](https://contentsquare.com/press/contentsquare-completes-acquisition-heap/)、[Usetiful 收购](https://markets.businessinsider.com/news/stocks/fullstory-acquires-usetiful-turning-digital-insights-into-decisive-actions-1035476979)、[DoubleLoop](https://mixpanel.com/blog/mixpanel-acquires-doubleloop/)）。结果不是降价，是 SKU 上移：Heap Connect 在 Pro 为加购、Premier 包含；区域特定存储仅 Premier，Pendo 的 Listen 与 Orchestrate 只在 Ultimate，FullStory 的移动端与 StoryAI 仍是加购（[Heap 定价](https://www.heap.io/pricing)、[Pendo 定价](https://www.pendo.io/pricing/)、[FullStory 计划](https://www.fullstory.com/plans/)）。 中国的并购与更名解决的不是产品问题，是存续问题。容联云 2021 年完成对诸葛智能的收购，随后经历纽交所停牌、退市，2026 年 5 月签署私有化合并协议（[金杜公告](https://www.kingandwood.com/cn/zh/about-us/media-center/king-and-wood-advises-on-taking-private-of-u-s-otc-quoted-cloopen.html)）；奇点云与 GrowingIO 在 2022 年重组为 StartDT（[GrowingIO 说明](https://www.growingio.com/about)）；数数科技 2026 年 4 月更名 ThinkingAI（[更名公告](https://www.thinkingai.cn/blog/b8e1a4f6/)）。产品还在，但产品的边界由母公司决定。 **第三，交付形态三分。** “warehouse-native”在 2024–2026 被严重混用。Amplitude 的 Snowflake Native 2024 年 6 月 GA，查询下推到客户的 Snowflake，数据不出仓库（[GA 公告](https://amplitude.com/releases/warehouse-native-ga)）；Mixpanel 的 Warehouse Connectors 是把仓库数据导入平台，Mirror 模式还会把仓库的删除同步回来（[文档](https://docs.mixpanel.com/docs/tracking-methods/warehouse-connectors)）；Heap Connect 与 Pendo Data Sync 是导出，前者到 Redshift/BigQuery/Snowflake/S3，后者单向（[Heap Connect](https://www.heap.io/platform/connect)、[Pendo Data Sync](https://support.pendo.io/hc/en-us/articles/18214274061595-Overview-of-Pendo-Data-Sync)）。下推、导入、导出，三种架构、三种成本、三种退出方式。 中国把这条光谱压成另一极：私有化。ThinkingAI 官方称 80% 客户选择私有化部署（[私有化页](https://www.thinkingai.cn/product/self-hosted/)），IDC 的数据显示 2024 年下半年中国 BI 与分析软件本地部署占 85.9%、同期公有云 14.1%；2024 全年公有云占 15.4%（[IDC](https://www.secrss.com/articles/81495)）。私有化不是中国独有：Glassbox 2024 年 5 月被 Alicorn 以约 1.5 亿美元全现金收购并私有化，保留多租户云、单租户云与本地部署三种形态（[收购公告](https://www.glassbox.com/news/glassbox-to-be-acquired-by-alicorn-venture-partners/)）。交付形态不是部署选项，是三种不同的生意：SaaS 卖规模效应，warehouse-native 卖“数据不动、计算动”，私有化卖“系统 + 服务 + 数据在哪”。 **第四，数据主权从架构问题变成法律问题。** 《个人信息保护法》2021 年 11 月 1 日施行（[全文](https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm)）；2024 年 3 月 22 日的跨境新规把门槛量化：非关键信息基础设施运营者，当年累计向境外提供不满 10 万人个人信息可免申报，10 万–100 万人需标准合同或认证，100 万人以上、或 1 万人以上敏感个人信息需安全评估（[规定全文](https://www.cac.gov.cn/2024-03/22/c_1712776611775634.htm)）。用户量第一次变成合规成本的函数。国际四家产品分析厂商都没有中国大陆区域：Amplitude 只有美国与欧盟，Mixpanel 有美国、欧盟、印度，Pendo 有美国、欧盟、澳大利亚、日本，Heap 只在 Premier 提供区域存储（[Amplitude 数据文档](https://amplitude.com/docs/llms-data.txt)、[Mixpanel 欧盟驻留](https://docs.mixpanel.com/docs/privacy/eu-residency)、[Pendo 全球托管](https://support.pendo.io/hc/en-us/articles/22832528657179-Global-data-hosting)、[Heap 定价](https://www.heap.io/pricing)）。国内云产品则把“到期”写进合同：Quick Tracking 到期 15 天未续费即清空历史数据，DataFinder 停服 90 天删除（[Quick Tracking 规格](https://www.alibabacloud.com/help/zh/quick-tracking/latest/collection-and-analysis-version-and-specifications)、[DataFinder 计费规则](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/VolcanoEngineGrowthAnalysis-ProductServiceBillingSettlementRules?lang=zh)）。 **第五，AI 从问答走向写回。** Amplitude 的 MCP 可读写图表、实验、人群与 taxonomy（[Amplitude llms.txt](https://amplitude.com/llms.txt)）；Contentsquare 的 Sense 能写邮件、工单与通知，2026 年 10 月加入 agentic experimentation，能自己设计、上线并验证实验（[平台发布](https://contentsquare.com/press/new-ai-first-experience-platform/)）；Pendo 的 Novus 能读代码库、自动埋点、生成 PR，但要求人批准后才合并，仍是 beta（[Novus](https://www.pendo.io/pendo-blog/novus-open-beta/)）；Quantum Metric 的 Felix Agentic 2026 年 7 月 16 日 GA（[GA 公告](https://www.quantummetric.com/press-releases/quantum-metric-launches-next-evolution-of-enterprise-agentic-analytics)）；神策 2026 年 6 月发布 Sensors AI 1.0，把 Agent 定义为 L4 级、需要人设定目标与边界（[发布会报道](https://www.geekpark.net/news/366666)）。评估维度因此从“能不能用自然语言问数”变成四件事：能读哪些表、能写什么、谁批准、怎么回滚。 反例也要写。Amplitude 官方文档承认，Data Assistant 检测不到“登录后丢失 user_id”这类身份问题，也无法判断两个已建立的 User ID 是否该合并（[数据文档](https://amplitude.com/docs/llms-data.txt)）；Mixpanel 的 MCP Connections 仍标 BETA（[MCP 文档](https://docs.mixpanel.com/docs/mcp-connections)）。Agent 能加速查询，不能替代埋点验收。 > **判断**：五个变化里，只有计价单位是买方能直接控制的。并购、交付、合规、AI 都由厂商与监管推动。所以合同要锁计价单位与涨幅，架构要留数据出口，采购要评估母公司存续——这三件事比“今年多了哪些功能”更能决定三年后的成本。 ## 1.5 市场规模：为什么没有一个可信的统一数字 问“UBA 市场多大”，通常会得到三个数字：10.6 亿美元、118 亿美元、20–30 亿美元。三者都可以“对”，因为定义不同。把它们平均，只会得到一个不存在的市场。 **首先是四个市场叠在一起。** 产品分析（Amplitude、Mixpanel、Heap、Pendo、PostHog）、体验分析（FullStory、LogRocket、Contentsquare、Glassbox、Quantum Metric）、测量云（GA4/360、Adobe AA/CJA）、采集与仓库（Snowplow、PostHog 自托管、Matomo）。这是按品类切的四个市场；1.4 节的三种交付形态是另一条轴，两条轴交叉，才是完整的市场地图。同一家公司可以横跨三个：Amplitude 有回放与 CDP，Adobe 有 AA 与 CJA，PostHog 有分析、回放与 Feature Flag。按厂商数市场，会把同一笔收入数两遍；按品类数，又会漏掉跨类的部分。 **其次是 Gartner 与 IDC 的口径差异。** Gartner 的《Magic Quadrant for Analytics and Business Intelligence Platforms》2025 年 6 月 16 日发布，它评估的是厂商的愿景完整度与执行能力，输出象限位置，不是市场规模；公开摘要不含市场规模（[MQ 引用](https://www.nasdaq.com/press-release/oracle-named-leader-2025-gartnerr-magic-quadranttm-analytics-and-business)）。Gartner 另有一份《Market Share: Data and Analytics Software, Worldwide, 2024》，属于付费文档，正文无法核实（[文档页](https://www.gartner.com/en/documents/6504971)）。IDC 的《Worldwide Business Intelligence and Analytics Software Forecast, 2025–2029》同样只公开摘要，文档标价 7,500 美元（[IDC 文档](https://my.idc.com/getdoc.jsp?containerId=US52422625)）。 能引用的 IDC 中国数字（经二手转述，标 B）：2024 年中国商业智能与分析软件市场 10.6 亿美元；2024 年下半年本地部署占 85.9%、同期公有云 14.1%，全年公有云占 15.4%；预计 2029 年 19.3 亿美元，五年复合增长率 12.8%。同一份报告里，美国公有云占 57.7%，全球 50.0%（[IDC 中国 BI](https://www.secrss.com/articles/81495)）。这是“BI 与分析软件”的宽口径，包含报表、OLAP、分析工具，不等于 UBA 订阅，也不能直接换算成埋点平台的数量。 两家机构的差异不在谁更准，而在三处：类目边界、收入构成与区域拆分。Gartner 卖的是坐标系，IDC 卖的是市场表；一个回答“谁被看见”，一个回答“钱记在哪个类目”。具体定义在付费全文里，公开摘要不足以复算，所以“Gartner 说 X、IDC 说 Y”不能相加，也不能互相校验。 | 口径 | 发布方 | 覆盖范围 | 数字 | 证据等级 | 能否用于预算 | |---|---|---|---|---|---| | 中国 BI 与分析软件 | IDC | 中国、软件收入、含本地与公有云 | 2024 年 10.6 亿美元；2029 年 19.3 亿；CAGR 12.8% | B | 只能判断中国市场价格结构 | | 全球 BI 与分析软件 | IDC | 全球、软件收入 | 文档标价 7,500 美元，公开摘要无数字 | 待核实 | 不能 | | 全球分析与 BI 平台 | Gartner | 厂商能力象限 | 无市场规模 | A（发布）/待核实（规模） | 不能 | | 全球数据与分析软件份额 | Gartner | 全球、软件收入 | 付费文档 | 待核实 | 不能 | | 全球产品分析 | P&S | 全球、产品分析（口径偏宽） | 2025 年 118 亿美元；2032 年 337 亿；CAGR 16.2% | C | 只能做上限压力测试 | | 商业 UBA 软件（底向上） | 本报告 | 产品分析 + 体验分析 + 区域厂商 | 20–30 亿美元 | C（除 Amplitude 外为估算） | 可用于 sanity check | **底向上估一次。** 唯一有审计口径的是 Amplitude：2025 财年 ARR 3.66 亿美元（[FY2025 财报](https://amplitude.gcs-web.com/news-releases/news-release-details/amplitude-announces-fourth-quarter-and-fiscal-year-2025)）。其余私营公司不披露收入，只能按融资、员工规模与客单价反推：Pendo 2.5–3.5 亿美元、Mixpanel 1–2 亿、Heap 0.8–1.5 亿、PostHog 1–2 亿、FullStory 1.5–2.5 亿，全部标 C。六家加总约 11–15 亿美元；加上 Contentsquare、Quantum Metric、Glassbox 等体验分析厂商与区域厂商，窄口径的“商业产品分析/体验分析软件”约 20–30 亿美元。P&S 的 118 亿美元（[GII 收录报告](https://www.giiresearch.com/report/psm2112588-product-analytics-market-size-share-analysis.html)）是这个区间的 4–6 倍，差额大致对应“软件订阅”与“软件 + 服务 + 更宽分析市场”的口径差。 **为什么统一数字不可信，有六个原因。** 一是边界：含不含实施、咨询、驻场；二是计价：事件、会话、MAU、行、server call 五种单位下的收入不可比；三是交付：订阅与“永久授权 + 一年服务”的收入确认不同，大地保险 2026 年为 GrowingIO v3.5 采购永久授权、合同期一年、含税上限 36 万元，就是后一种（[招标](https://www.jinrongzhaobiao.com/news-645f2defdcce5b499ac0973746f8ed76/)）；四是披露：除 Amplitude 外均为私营；五是重复计数：云厂商把分析打包进云合同，测量云用免费换广告；六是地理：中国 2024H2 本地部署 85.9%，全球 50% 公有云，同一款软件的“市场”不在同一个物理位置。 > **判断**：市场规模的分歧不是统计误差，是定义差异。引用前必须写清“包含什么、按什么收费、是否含服务”。本报告只用区间做 sanity check，不用任何单点数字做 TAM、份额或增长率承诺。 ## 1.6 买家与预算归属：谁签字，决定买什么 同一家公司同时买两三个工具，通常不是因为厂商没做全，而是因为四条预算线各自找供应商。产品分析走产品与数据预算，回放走 UX、客服或工程预算，GA4/360 走市场预算，私有化走 IT 与合规预算。预算归属决定工具并存，而不是功能重叠。 | 预算线 | 典型采购 | 签字人 | 审批关注 | 续费动力 | |---|---|---|---|---| | 产品与数据 | Amplitude、Mixpanel、神策 | 产品负责人、CDO、数据平台负责人 | 事件口径、实验、治理、仓库集成 | 使用深度与切换成本 | | UX、客服与工程 | FullStory、LogRocket、Glassbox | UX 负责人、客服 VP、工程负责人 | 回放留存、遮罩、客诉与排障 | 排障效率与客诉处理 | | 市场 | GA4/360、Adobe AA/CJA | CMO、增长负责人 | 归因、广告联动、采样与阈值 | 广告预算绑定 | | IT 与合规 | 私有化、信创、DataFinder 云托管 | CIO、CISO、法务 | 数据区域、等保、出境、删除证明 | 合同主体与审计 | Amplitude 的财报给了一个反向证据：企业客户与多产品客户贡献 74% 的 ARR（[FY2025 财报](https://amplitude.gcs-web.com/news-releases/news-release-details/amplitude-announces-fourth-quarter-and-fiscal-year-2025)）。这说明“合并供应商”确实在大客户内部发生，但不等于中小客户只买一家。大客户合并的是合同与采购关系，不是每一个团队的使用习惯。 中国的预算归属更直接：项目制。2023 年深交所单一来源采购神策一年期授权，含每年 10 亿事件、增购 2 个项目、智能运营每年 2 亿事件与 2 个项目，含税成交 28 万元（[成交公示](https://ebs.szse.cn/cmschengjiaogg/11387.html)）。这个价格不能除以事件量变成单价，它买的是一套私有化系统与一年服务。神策在阿里云云市场挂 54 万–72 万元/年，近 180 天成交 0 笔（[云市场](https://market.aliyun.com/detail/cmgj00047786.html)）：刊例价是锚，不是成交价。 采购顺序也在变。过去先比功能、再比价格、最后过法务；现在数据区域、访问权、留存期、二次使用、出境路径、删除证明要先过，否则功能演示没有意义。 > **判断**：买单人决定计价锚点，预算归属决定工具并存。“功能最全”很少赢，因为采购不是一次技术评分，是四条预算线各自找最合适的供应商；能同时进入两条预算线的产品，才有平台化的机会。 ## 1.7 本报告的判断框架 前面六节回答“这是什么市场”，这一节回答“怎么读后面十章”。本报告不按功能打分，而是把事件从产生到消失拆成七段，看每一段谁在收费、哪里会失控。 | 环节 | 产出 | 最容易失控的点 | 谁在这里收费 | 对应章节 | |---|---|---|---|---| | 采集 | SDK、服务端 API、全埋点 | 重复上报、PII 入参、端上丢失 | 按事件、会话或流量 | 第 08 章 | | 传输接入 | 网关、消息队列、边缘节点 | 延迟、丢包、重复 | 云资源、采集 GB | 第 10 章 | | 建模 | taxonomy、身份、会话、实体 | 同名不同义、ID 合并错误 | 平台费、项目费 | 第 08 章 | | 存储计算 | 明细表、聚合表、湖仓 | 副本膨胀、留存成本 | 存储、计算、数据行 | 第 10 章 | | 分析指标 | 漏斗、留存、路径、指标层 | 口径打架、样本偏差 | 订阅、模块 | 第 09 章 | | 行动 | 人群、实验、引导、推荐 | 写错、无法回滚 | MAU、模块、加购 | 第 09 章 | | 治理计价 | 权限、审计、成本分摊、合规 | 无 owner、无账单 | 平台包、企业版 | 第 11 章 | 这张表的用法不是“每段都要买最贵的”，而是找缺口：采集强、建模弱，买再好的分析界面也会得到互相矛盾的报表；建模强、行动弱，洞察会停在看板里。七类玩家的位置，本质上是“在哪一段收费、把哪一段外包给客户”。 在此之上，有四道过滤器，顺序不能颠倒：前一道不成立，后一道的评分没有意义。 **第一道，口径。** 同一个“活跃用户”怎么定义？留存是 N-day 还是 rolling？漏斗有序还是无序？窗口多长？这些问题答不清，功能越多，错误结论传播得越快。 **第二道，语义。** taxonomy 谁维护、有没有版本、废弃事件怎么处理、能否导出？Heap 用 autocapture 把语义后置到分析时，上线最快，代价是虚拟事件与历史数据绑定在平台内，退出时语义带不走（[Heap Connect](https://www.heap.io/platform/connect)）。网易云音乐把埋点元数据做成 Git 式版本，线上错误下降 95%，这是另一种答案：语义资产要像代码一样管理（[网易云音乐实践](https://server.it168.com/a2023/0118/6786/000006786834.shtml)）。 **第三道，主权。** 数据在哪、谁能看、能否用于训练、出境走哪条路径？私有化只解决“数据在哪”，不解决“谁能看、谁能改、谁能导出”；没有 RBAC 与审计的私有化，只是把风险从厂商机房搬进自己的机房。 **第四道，退出。** 原始事件能否全量导出？语义资产有没有清单？停服或控制权变更提前多久通知？Amplitude 不能合并两个已建立的 User ID，跨项目只能用 User Mapping API；Adobe 的 Evolution 只能授权一次、不可续约（[Amplitude 数据文档](https://amplitude.com/docs/llms-data.txt)、[AA 产品说明](https://helpx.adobe.com/legal/product-descriptions/adobe-analytics.html)）。原始事件可以导出，事件命名、指标口径、看板注释、实验结论不会随 CSV 走。 > **判断**：读一家 UBA 厂商，不要先问“有多少图表”，先问四个问题：事件语义由谁定义、数据主副本在哪、按什么计价、退出时能带走什么。四个答案决定它是你的基础设施，还是你的报表工具。 全书按这条价值链展开：第 02–03 章看国际商业平台，第 04–05 章看中国商业化与自建，第 06–07 章看开源与基础设施，第 08–09 章拆采集、模型、分析与 AI，第 10 章讲架构与成本，第 11 章回到选型与 90 天落地。每一章都对应价值链上的一段，而不是一家公司的产品说明书。 本章的局限也在这里：所有判断基于公开页面与文档，没有客户访谈，没有付费报告全文，没有统一压测；中国厂商的存续判断只到“公开资料显示”，不到“合同确认”。这些缺口会在引用处标“待核实”，不用推测补全。 ## 参考来源 - [Amplitude — Pricing](https://amplitude.com/pricing) - [Amplitude — Q4/FY2025 Financial Results](https://amplitude.gcs-web.com/news-releases/news-release-details/amplitude-announces-fourth-quarter-and-fiscal-year-2025) - [Amplitude — Q2 2026 Financial Results](https://investors.amplitude.com/news-releases/news-release-details/amplitude-announces-second-quarter-2026-financial-results) - [Amplitude — LLM data docs](https://amplitude.com/docs/llms-data.txt) - [Amplitude — Warehouse Native GA](https://amplitude.com/releases/warehouse-native-ga) - [Amplitude — acquires Command AI](https://amplitude.com/blog/amplitude-acquires-command-ai) - [Amplitude — acquires Kraftful](https://amplitude.com/blog/amplitude-acquires-kraftful) - [Amplitude — acquires InfiniGrow](https://www.amplitude.com/press/amplitude-acquires-infinigrow) - [Amplitude — Statsig partnership](https://amplitude.com/blog/amplitude-and-statsig-partnership) - [Amplitude pricing history (third-party)](https://votefirst.app/en/pricing/amplitude) - [Mixpanel — Pricing](https://mixpanel.com/pricing/) - [Mixpanel — legacy MTU billing](https://docs.mixpanel.com/docs/pricing/legacy-mtu-billing) - [Mixpanel — Warehouse Connectors](https://docs.mixpanel.com/docs/tracking-methods/warehouse-connectors) - [Mixpanel — acquires DoubleLoop](https://mixpanel.com/blog/mixpanel-acquires-doubleloop/) - [PostHog — Product Analytics Pricing](https://posthog.com/product-analytics/pricing) - [Heap — Pricing](https://www.heap.io/pricing) - [Heap — Connect](https://www.heap.io/platform/connect) - [Contentsquare — completes acquisition of Heap](https://contentsquare.com/press/contentsquare-completes-acquisition-heap/) - [Contentsquare — AI-first experience platform](https://contentsquare.com/press/new-ai-first-experience-platform/) - [Pendo — Pricing](https://www.pendo.io/pricing/) - [Pendo — acquires Chisel Labs](https://www.pendo.io/news/pendo-acquires-chisel-labs-to-help-product-teams-build-better-and-faster-with-agentic-ai/) - [Pendo — Novus open beta](https://www.pendo.io/pendo-blog/novus-open-beta/) - [FullStory — acquires Usetiful](https://markets.businessinsider.com/news/stocks/fullstory-acquires-usetiful-turning-digital-insights-into-decisive-actions-1035476979) - [Glassbox — acquired by Alicorn](https://www.glassbox.com/news/glassbox-to-be-acquired-by-alicorn-venture-partners/) - [GA4 — Data retention](https://support.google.com/analytics/answer/7667196?hl=en) - [GA4 — Data sampling](https://support.google.com/analytics/answer/13331292?hl=en) - [GA4 — BigQuery Export](https://support.google.com/analytics/answer/9358801?hl=en) - [GA4 360 pricing model — Cardinal Path](https://www.cardinalpath.com/blog/ua-360-vs-ga4-360-pricing-model) - [Adobe — Analytics Product Description](https://helpx.adobe.com/legal/product-descriptions/adobe-analytics.html) - [Twilio — Q2 2026 Earnings Call](https://www.fool.com/earnings/call-transcripts/2026/08/13/twilio-twlo-q2-2026-earnings-call-transcript/) - [IDC — 中国 BI 与分析软件市场（2024）](https://www.secrss.com/articles/81495) - [Gartner — Market Share: Data and Analytics Software, Worldwide, 2024](https://www.gartner.com/en/documents/6504971) - [Gartner MQ 2025 — Oracle press release](https://www.nasdaq.com/press-release/oracle-named-leader-2025-gartnerr-magic-quadranttm-analytics-and-business) - [IDC — Worldwide BI & Analytics Software Forecast 2025–2029](https://my.idc.com/getdoc.jsp?containerId=US52422625) - [P&S/GII — Product Analytics Market](https://www.giiresearch.com/report/psm2112588-product-analytics-market-size-share-analysis.html) - [神策数据 — 云市场商品页](https://market.aliyun.com/detail/cmgj00047786.html) - [深交所 — 神策授权成交公示](https://ebs.szse.cn/cmschengjiaogg/11387.html) - [GrowingIO — 关于我们](https://www.growingio.com/about) - [中国大地保险 — 2026 埋点分析系统招标](https://www.jinrongzhaobiao.com/news-645f2defdcce5b499ac0973746f8ed76/) - [ThinkingAI — 更名公告](https://www.thinkingai.cn/blog/b8e1a4f6/) - [ThinkingAI — 私有化部署](https://www.thinkingai.cn/product/self-hosted/) - [金杜 — 容联云私有化](https://www.kingandwood.com/cn/zh/about-us/media-center/king-and-wood-advises-on-taking-private-of-u-s-otc-quoted-cloopen.html) - [易观数科 — 官网](https://www.analysysdata.com/) - [火山引擎 — DataFinder 云托管说明](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/IntroductiontoCloudHostingModel?lang=zh) - [火山引擎 — DataFinder 计费结算规则](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/VolcanoEngineGrowthAnalysis-ProductServiceBillingSettlementRules?lang=zh) - [阿里云 — Quick Tracking 版本规格](https://www.alibabacloud.com/help/zh/quick-tracking/latest/collection-and-analysis-version-and-specifications) - [网信办 — 个人信息保护法](https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm) - [网信办 — 促进和规范数据跨境流动规定](https://www.cac.gov.cn/2024-03/22/c_1712776611775634.htm) - [神策 — Sensors AI 1.0 发布会报道](https://www.geekpark.net/news/366666) - [网易云音乐 — 全链路埋点管理平台](https://server.it168.com/a2023/0118/6786/000006786834.shtml) - [Amplitude — FY2025 Results](https://amplitude.gcs-web.com/news-releases/news-release-details/amplitude-announces-fourth-quarter-and-fiscal-year-2025) --- # 02 · 商业平台（上）：产品分析的四条路线 > 四家都在卖“理解用户”，但入口、事件模型与计价单位并不相同；选错路线，功能越多，治理成本越高，退出也越难。 2026 年，这四家公司已经不在同一张“产品分析”表上竞争。Amplitude 把事件、实验、回放、引导、CDP 与 Agent 装进一个平台；Mixpanel 把“分析师当天就能查出答案”做成产品；Heap 把“先采集、后定义”做成入口；Pendo 把“让用户真的用起来”做成生意。四种入口，对应四种数据模型、四种账单，也对应四个不同的签字人。如果只用一句话概括：Amplitude 卖语义，Mixpanel 卖速度，Heap 卖采集，Pendo 卖行动。 把四家放在一起打功能分，通常会得到“Amplitude 最全，所以最值得买”的结论。这个结论跳过了三个更靠前的问题：事件语义由谁定义，数据在哪里计算，洞察之后由谁执行。功能表只能回答“有没有”，回答不了“用不用得起、带不带得走”。 本章以 2026 年 10 月抓取的官方定价页、产品文档、财报与并购公告为主。第三方价格样本只用于判断量级；客户数只当作方向性信号，因为同一家公司同一年的公开页面，客户数可以差一个数量级。 ## 2.1 四条路线 四条路线的起点不是功能，而是“第一次付费的理由”。Amplitude 卖“更深的分析，而且能立刻做实验”；Mixpanel 卖“今天就能上手”；Heap 卖“不改代码先把数据收上来”；Pendo 卖“让用户真的用起来”。 | 路线 | 代表 | 入口 | 核心资产 | 主要买单人 | 计价锚点 | 2026 状态 | |---|---|---|---|---|---|---| | 事件语义 + 实验 | Amplitude | 事件分析与增长实验 | 事件语义、Experiment、Snowflake 下推 | 产品、增长、数据平台；中大型企业 | 事件量，不限席位 | 纳斯达克上市，平台化最完整 | | 自助式事件分析 | Mixpanel | 查询体验与自助购买 | 分析体验、Lexicon、仓库导入 | 产品团队、增长团队、中小企业 | 事件量（旧合同按 MTU） | 独立私营，事件计价 | | 全埋点 + 体验分析 | Heap / Contentsquare | 先采集、后定义 | autocapture、回放、旅程 | 电商、CX、产品团队 | 会话量 | 已并入 Contentsquare，品牌仍在 | | 采用分析 + 应用内引导 | Pendo | 功能采用与用户运营 | 页面/功能模型、Guides、MAU 计费 | B2B SaaS 产品、客户成功 | MAU | 独立私营，AI 产品扩张 | 入口决定了数据模型。Amplitude 与 Mixpanel 把语义放在事件层：事件名、属性、用户、分组，先定义再分析；Heap 把语义后置到分析时，先用 autocapture 收全量，再用虚拟事件补定义；Pendo 把语义放在页面与功能层，事件只是补充。语义越靠前，治理成本越高，可复用性越强；语义越靠后，上手越快，越难回答“这个点击到底意味着什么”。 入口也决定了预算归属。Amplitude 的合同通常由产品与数据平台共同签，Mixpanel 常由产品团队用部门预算自助购买，Heap/Contentsquare 走 CX、电商或市场预算，Pendo 走客户成功与产品运营。预算归属决定了合同周期、安全审查的严格程度，以及续约时谁有动力砍掉它。 这一轮整合里，资本买的是“行动端”，不是“图表端”。Amplitude 先后买下 Command AI（应用内引导）、Kraftful（定性反馈）、InfiniGrow（营销归因），并在 2026 年 5 月接手 Statsig 的品牌、产品与客户 [Statsig 交易](https://amplitude.com/blog/amplitude-and-statsig-partnership)；Pendo 买 Zelta、Forwrd、Chisel，把反馈、预测与 PM Agent 收进采用分析 [Chisel 收购](https://www.pendo.io/news/pendo-acquires-chisel-labs-to-help-product-teams-build-better-and-faster-with-agentic-ai/)；Contentsquare 买 Heap 与 Loris，把产品分析与对话接进旅程 [Heap 交割](https://contentsquare.com/press/contentsquare-completes-acquisition-heap/)；Mixpanel 买 DoubleLoop，补指标树与业务上下文 [DoubleLoop](https://mixpanel.com/blog/mixpanel-acquires-doubleloop/)。没有一家在买“更好的漏斗图”。 计价单位也在同一时期集体迁移。Mixpanel 把 MTU 降级为 legacy billing，改为事件计价 [MTU 说明](https://docs.mixpanel.com/docs/pricing/legacy-mtu-billing)；Amplitude 在 2023–2026 年之间三次调整计价口径，最终把 MTU 从套餐卡上拿掉 [第三方定价史](https://votefirst.app/en/pricing/amplitude)；Heap 与 Contentsquare 坚持会话计价；Pendo 坚持 MAU。计价单位不是财务细节，它决定了厂商鼓励你多采集还是少采集。 数据主权则从“加分项”变成“一票否决项”。四家都没有中国大陆区域：Amplitude 只有美国与欧盟，Mixpanel 有美国、欧盟、印度，Pendo 有美国、欧盟、澳大利亚、日本，Heap 的区域存储只在 Premier 套餐。对涉及个人信息出境的企业，这是合规门槛，不是偏好问题。 > **判断**：四家的分水岭不是“有没有漏斗和留存”，而是“事件语义由谁定义、行动在哪里发生”。Amplitude 与 Mixpanel 把语义放在事件层，Heap 把语义后置到分析时，Pendo 把语义放在页面与功能层。语义层越靠前，治理成本越高，可复用性越强。 ## 2.2 Amplitude：把“分析之后”全部买回来 Amplitude 是四家里唯一把“分析—实验—引导—CDP”做成一条产品线的上市公司，也是唯一能用 SEC 口径核对收入的。它的强来自完整，它的贵也来自完整。 **公司与产品面。** 2012 年成立，纳斯达克上市（AMPL），联合创始人兼 CEO 为 Spenser Skates。2026 年 Q2 ARR 4.10 亿美元、同比增长 22%，季度收入 1.009 亿美元，年付 10 万美元以上客户 824 家、同比增长 30% [Q2 2026 财报](https://investors.amplitude.com/news-releases/news-release-details/amplitude-announces-second-quarter-2026-financial-results)。2025 财年 ARR 3.66 亿美元、营收 3.432 亿美元，客户 4,700 余家，其中 10 万美元以上 698 家、100 万美元以上 56 家，美元净留存率 105%；企业客户与多产品客户贡献 74% 的 ARR [FY2025 财报](https://amplitude.gcs-web.com/news-releases/news-release-details/amplitude-announces-fourth-quarter-and-fiscal-year-2025)。这组数字说明它已经越过“产品团队工具”的阶段，收入越来越依赖大客户的多模块采购。 产品分四层：Insights 含 Product Analytics、Session Replay、Heatmaps、Marketing Analytics；Action 含 Feature Experimentation、Web Experimentation、Feature Management、Guides & Surveys、Activation；AI 含 Agents、Assistant、AI Feedback、AI Visibility、MCP、Wave、Agent Analytics；Data 含 Amplitude Data（CDP）与 Data Governance [产品索引](https://amplitude.com/llms.txt)。四层之间是一条从“看见”到“改变”的链路：分析产生人群，人群进入实验或引导，结果再回到分析。 **事件模型。** Amplitude 以事件、用户、分组为核心。Autocapture 在 Web 端采集会话、页面浏览、点击、表单交互、文件下载、营销归因与 URL 富化；在 iOS/Android 采集安装、升级、会话与屏幕浏览 [Autocapture 文档](https://amplitude.com/docs/data/autocapture)。它也支持精确埋点、可视化圈选，以及用 Ampli 根据 tracking plan 生成强类型 SDK。身份的边界写得很直白：标准身份解析不能合并两个已经建立的 User ID，跨项目只能用 Portfolio 的 User Mapping API；官方文档还承认，Data Assistant 检测不到“登录后丢失 user_id”这类问题 [数据文档](https://amplitude.com/docs/llms-data.txt)。这条限制会在“匿名—登录—换设备—再登录”的链路里变成双 profile。AI 能加速查询，但不能替代埋点验收。 **分析与 AI。** 分段、漏斗、留存、路径、人群、公式、预测、归因都在平台内；实验支持序贯检验、T 检验、多臂老虎机、CUPED、互斥组与 holdout，客户端与服务端都可部署 [Experiment](https://amplitude.com/amplitude-experiment)。这是四家里实验能力最完整的一套，也是它区别于 Mixpanel 的核心。AI 侧，Global Agent、Specialized Agents、Wave 与 MCP 能跨图表、实验、回放解释指标变化，生成机会清单，甚至触发实验、活动与内容变更；Friction Monitor 仍标 Early Access。判断 AI 成熟度不要看演示，要看三件事：能读哪些表、能不能写回业务系统、写之前谁批准。 **部署与定价。** SaaS，美国与欧盟两个数据中心。Snowflake Native 于 2024 年 6 月 4 日 GA，把查询下推到客户自己的 Snowflake，数据不出仓库 [GA 公告](https://amplitude.com/releases/warehouse-native-ga)。这是四家里唯一真正的 warehouse-native：计算在客户仓库，平台只带 UI、语义与调度。代价是只覆盖 Snowflake，BigQuery 与 Databricks 仍要导入。 定价按事件量，席位不限。Free 永久 200 万事件/月、1 万次回放/月；Plus 从 0 美元起，前 200 万事件免费，可扩到 7,000 万事件；Growth 与 Enterprise 定制报价，回放上限分别 2 万与 5 万次/月，留存统一 1 个月，延长另购 [定价](https://amplitude.com/pricing)。融资低于 1,000 万美元、员工少于 20 人的初创公司可免费用 Growth 一年。第三方读数显示，年付 1,000 万事件约 576 美元/月，7,000 万约 4,692 美元/月 [第三方读数](https://votefirst.app/en/pricing/amplitude)。这是 C 级证据，不能直接当报价。隐藏成本在 SSO（Growth 起）、SCIM 与数据访问控制（Enterprise）、回放留存延长，以及 AI 用量。 **2025–26 的变化与限制。** 2025 年 7 月 10 日买 Kraftful [Kraftful](https://amplitude.com/blog/amplitude-acquires-kraftful)，2026 年 1 月 14 日买 InfiniGrow [InfiniGrow](https://www.amplitude.com/press/amplitude-acquires-infinigrow)，2026 年 5 月 5 日接手 Statsig 的品牌、产品与客户。更早的 2024 年，Command AI 已经补上应用内引导 [Command AI](https://amplitude.com/blog/amplitude-acquires-command-ai)。最后一笔最特殊：Statsig 团队在 2025 年 9 月 2 日加入 OpenAI [Statsig 公告](https://statsig.com/blog/openai-acquisition)，Amplitude 拿到的是实验与 Feature Flag 的客户基础，不是组织能力。这是一次“资产与团队分离”的交易，也提醒买方：被收购不等于产品会更安全。 **优势与限制。** 优势是平台完整度最高、实验与 Feature Flag 最强、治理与上市公司透明度更好，不限席位对“全员看数”友好。限制同样明显：事件计价在高事件量、autocapture 全开时成本上升快；平台越宽，tracking plan 不做好，图表越多越乱；warehouse-native 只覆盖 Snowflake；身份合并有硬边界；AI 功能依赖既有语义质量。团队没有专职的数据或埋点负责人时，Amplitude 的广度会变成负担；核心需求只是“看页面点击和录屏”时，为实验与 CDP 付费是浪费。 > **判断**：Amplitude 买的是“分析之后的每一步”，这让它在四家里最难被替代；但它把治理成本留给了买方——事件计价奖励少采集，平台广度要求多治理，两件事天然拉扯。 ## 2.3 Mixpanel：把“第一次查询”做成生意 Mixpanel 是四家里最克制的一家。它不建 CDP，不卖重实施，不追“全公司操作系统”，而是把赌注押在“第一次查询的体验”和“透明的事件计价”上。 **公司与产品面。** 2009 年成立，独立私营，CEO 为 Jen Taylor（截至 2025 年 10 月公开信息）。2021 年 11 月获 Bain Capital Tech Opportunities 2 亿美元 C 轮，估值 10.5 亿美元，累计融资 2.77 亿美元 [Bain 公告](https://www.baincapitaltechopportunities.com/news/product-analytics-leader-mixpanel-secures-200-million-growth-investment-help-more-teams-build)；截至 2026 年 10 月，未发现被收购的官方公告，股权结构待核实。产品包括 Analytics（Insights、Funnels、Retention、Flows、Cohorts）、Session Replay、Heatmaps、Experiments、Feature Flags、Metric Trees、Lexicon、Warehouse Connectors、Data Pipelines、Cohort Sync，以及 Agent 与 MCP。 **事件模型。** 事件、属性、用户画像、分组（Group Analytics）。Web 端 autocapture 默认开启，采集页面浏览、滚动、表单交互、元素点击、归因、死点击与怒点击；移动端也支持屏幕浏览、点击、死点击与怒点击，但移动端点击采集仍是 beta 且默认关闭。默认排除输入框内容、密码与表单值，只采集 class、name、aria-label、role、title、type 等有限属性 [Autocapture](https://docs.mixpanel.com/docs/tracking-methods/autocapture)。这个默认值比“能采多少”更重要：它决定了回放与事件里会不会出现 PII，也决定了客户能否在合规评审时少改一轮代码。 **分析与 AI。** 事件分析是四家里最顺手的，公式、分组、cohort、留存与漏斗路径都成熟。Lexicon 提供事件与属性的数据字典 [Lexicon](https://docs.mixpanel.com/docs/data-governance/lexicon)，让治理有一个具体落点；2025 年 8 月 26 日推出的 Metric Trees 把指标之间的因果关系做成可协作的树 [Metric Trees](https://mixpanel.com/blog/mixpanel-metric-trees/)；2025 年 10 月 7 日收购 DoubleLoop，补的正是“指标与业务结果”的结构化。实验按 MEU（月度实验用户）计量，Feature Flag 与实验共享套餐额度 [Experiments](https://docs.mixpanel.com/docs/experiments)，起步晚于 Amplitude，但够用。AI 侧有 Mixpanel Agent、Root Cause Analysis 与 MCP Connections；MCP 仍标 BETA，Agentic Automations 与 Real-Time Event Streams 也在 beta [MCP 文档](https://docs.mixpanel.com/docs/mcp-connections)。 **部署与定价。** SaaS，默认美国 GCP；欧盟驻留项目使用 api-eu.mixpanel.com，印度也有驻留选项，没有澳大利亚/日本区域 [欧盟驻留](https://docs.mixpanel.com/docs/privacy/eu-residency)。仓库侧是“导入”而不是“下推”：Warehouse Connectors 支持 Snowflake、BigQuery、Databricks、Redshift、Postgres，付费事件套餐续约时免费附带；Mirror 模式会把仓库中的删除与修改同步回 Mixpanel [Warehouse Connectors](https://docs.mixpanel.com/docs/tracking-methods/warehouse-connectors)。数据主副本仍在 Mixpanel，这是它与 Amplitude Snowflake Native 的根本差别。 Free 100 万事件/月、1 万次回放/月、1,000 MEU、10 个活跃 Flag；Growth 从 0 美元起，官方示例为 150 万事件/月、年付 1,200 美元（100 美元/月，折合 1,800 万事件/年），上限 2,000 万事件/月、50 万次回放/月、5,000 MEU、50 个 Flag；按公开价目，1,000 万事件/月年付 840 美元，2,000 万 1,635 美元；Enterprise 上限写到 1 万亿事件/月 [定价](https://mixpanel.com/pricing/)。旧 MTU 合同 2 万美元/年起，只在客户每月超过 10 万用户或 500 万事件时由销售介入 [MTU 说明](https://docs.mixpanel.com/docs/pricing/legacy-mtu-billing)。回放 Free/Growth 默认 30 天，Enterprise 可配 7–365 天，12 个月只是其中一个档位。 **2025–26 的变化与限制。** 2025 年补 Metric Trees、仓库导入与 DoubleLoop；2026 年补 Agent 与 MCP。它的优势是上手最快、查询体验好、事件计价透明、免费层足够做真实 POC；欧盟与印度驻留对出海团队友好。限制是行动端最窄：没有原生应用内引导，人群要同步到外部工具；实验与治理不如 Amplitude 厚；企业权限、审计与合规档位更薄；没有澳大利亚/日本区域。 Mixpanel 的真正资产是“第一次查询”与自助购买链路，这让它在 PLG/SMB 市场获客便宜；但这也意味着它最容易被当成“够用就好”的工具。向上，它要面对 Amplitude 的实验与治理；向下，要面对 PostHog 的开源与一体化。2026 年的 Agent 与 MCP 是向上走的尝试，但行动端仍要靠外部工具补齐。 ## 2.4 Heap 与 Contentsquare：一次还没收尾的整合 Heap 是这四家里唯一已经失去独立身份的。2023 年 12 月 7 日交割后，它从一家以 autocapture 起家的公司，变成 Contentsquare 的产品分析模块。 **公司与产品面。** Heap 2013 年成立；Contentsquare 2023 年 9 月 28 日签约收购，12 月 7 日完成，称这是其最大一笔收购 [交割公告](https://contentsquare.com/press/contentsquare-completes-acquisition-heap/)。Contentsquare 在 2022 年 7 月宣布 6 亿美元融资、估值 56 亿美元，累计融资 14 亿美元 [融资报道](https://siliconangle.com/2022/07/29/new-600m-financing-contentsquare-aims-humanize-digital-interactions/)，覆盖 130 万网站、1,300 多家企业品牌。客户数口径冲突得很典型：同一份交割公告里，正文称 Heap“超过 10,000 家公司（companies）”，About Heap 段落又称“超过 1,000 家企业（businesses）”，未说明是否付费/企业级口径；Heap 官网导航写“9,000 多家成功公司” [Heap 定价页](https://www.heap.io/pricing)。三个数字并列时，最诚实的用法是“量级在数千到一万之间，口径待核实”。 产品分两条线。Heap 侧有 Capture、Charts、Journeys、Segments、Dashboards、Playbooks、Illuminate、Sense AI、Session Replay、Heatmaps、Governance、Heap Connect；Contentsquare 侧有 Session Replay、Heatmaps & Zoning、Journeys、Attribution、Product Analytics、Surveys、Conversation Intelligence、Errors & Performance、Experimentation [产品分析](https://contentsquare.com/platform/product-analytics/)。2026 年 10 月 13 日，Contentsquare 发布“AI-first Experience Platform”，把人类、LLM 与 Agent 流量放进同一套旅程分析，加入多会话旅程、WebMCP 监控与 agentic experimentation [平台发布](https://contentsquare.com/press/new-ai-first-experience-platform/)。 **事件模型。** Heap 的核心是 autocapture（官方称 Smart Capture）：Web 端一次安装采集浏览、点击、滑动、表单填写；移动端支持原生与跨平台框架的自动采集，也支持手动事件与服务端 API [Capture](https://www.heap.io/platform/capture)。它保留“先采集、后定义”的能力，虚拟事件可以回溯；Heap Connect 把行为数据、虚拟事件与用户属性同步到 Redshift、BigQuery、Snowflake 或 S3，且可回溯 [Heap Connect](https://www.heap.io/platform/connect)。身份侧支持 identify、alias、账户属性与服务端 track [开发者文档](https://developers.heap.io/llms.txt)。这套模型的优点是上线快，缺点是“事件”在采集时没有业务含义，分析阶段才被命名；命名一旦混乱，回溯也救不了语义。Contentsquare 侧则以页面、会话与旅程为单位，回放与热图是主数据源，事件是补充。 **分析与 AI。** 漏斗、留存、路径、分群、看板、Playbooks；Illuminate 用数据科学找“未知摩擦”；Sense 用 AI 找摩擦并量化收入影响；回放与热图是体验分析的入口。Contentsquare 的强项是多会话、跨设备、跨渠道旅程，以及把对话与 LLM 流量当作事件纳入分析。AI 侧，Sense 与 Sense Analyst 能识别摩擦、量化收入影响、摘要会话与热图，甚至写邮件与工单；Sense Analyst lite 仍标 Beta。它的“写权限”比另外三家更靠前，采购时要把“AI 能写什么、谁批、怎么回滚”写进安全评审。 **部署与定价。** SaaS。Heap 只在 Premier 套餐提供区域特定存储 [Heap 定价](https://www.heap.io/pricing)；Contentsquare 的公开文档没有列明区域选项，区域选项待核实，需在合同中确认。合规上，Contentsquare 信任中心写 ISO 27001、27017、27018、27701 与 SOC 2 Type II，并明确 Heap 与 Hotjar 已并入 [信任中心](https://trust.contentsquare.com/)。 计价按会话量。Heap Free 每月 1 万会话、6 个月数据、SSO；Growth 起价需在安装后获取估算；Pro 与 Premier 定制，回放为加购，Heap Connect 在 Pro 需加购、Premier 包含 [Heap 定价](https://www.heap.io/pricing)。会话的定义是 Web 端 30 分钟无页面浏览、移动端 5 分钟无活动。Contentsquare 的 Experience Analytics Free 给 20 万会话/月但只有 1 个月数据访问；Growth 月付 49 美元、年付 39 美元/月，对应 7,000 会话，可扩到 20 万；Pro 定制 [Contentsquare 定价](https://contentsquare.com/pricing/)。两套价目表并存，说明整合还没有完成到“一个产品、一个价格”。 **2025–26 的变化与限制。** 2025 年 10 月完成对 Loris 的收购，把语音与文本对话接进旅程 [Loris 收购](https://contentsquare.com/press/contentsquare-completes-acquisition-of-loris-ai/)；2026 年 9 月 15 日的文档把 Heap Core SDK 与 Contentsquare SDK 合并为统一的 CSQ SDK，支持从 Heap Core、Heap Classic、Heap + Contentsquare 三种旧组合迁移，CocoaPods 将在 2026 年 12 月 2 日后停止发布新版本 [SDK 迁移](https://docs.contentsquare.com/en/csq-sdk-ios/product-analytics/upgrade-from-heap-and-cs-sdk/)；2026 年 10 月 13 日发布 AI-first 平台。优势是“安装到看见数据”的时间最短，autocapture 对快速迭代的产品很实用，体验分析与产品分析在同一平台，企业认证齐全，电商与 CX 模板深。 限制首先是整合期的三个结构问题：两个产品、两套计价、两个品牌。客户需要判断自己买的是 Heap 还是 Contentsquare，迁移窗口与路线图要写进合同。会话计价对“长会话、低事件”的产品可能更贵，对“高频短会话”更便宜；产品分析的深度（公式、实验、治理）仍弱于 Amplitude 与 Mixpanel；区域存储要 Premier，门槛不低。 整合有三种可能路径：双产品并行、统一平台、Heap 成为 Contentsquare 的产品分析模块。2026 年 10 月的证据更接近第二与第三条之间：文档已统一，定价页仍分开，销售话术仍在讲 Heap。采购时要问：合同主体是谁、续约时会不会被要求换 SKU、历史 Heap 数据能否留在原区域、回放是否强制绑定 Contentsquare、CSQ SDK 的迁移窗口、Heap 品牌是否还有独立路线图。 > **判断**：买 Heap 不等于买 Contentsquare。前者是按会话计价的产品分析模块，后者是按体验分析打包的平台；一张合同里可能同时存在两套计价、两条路线图，签约前要确认自己买的是哪一条。 ## 2.5 Pendo：卖的是“用起来”，不是“查得到” Pendo 的起点不是“分析”，是“采用”。它先回答“用户有没有用上这个功能”，再回答“为什么不用”。这个顺序决定了它的数据模型、计价单位与买单人。 **公司与产品面。** 2013 年成立，独立私营，CEO 为 Todd Olson。2021 年 7 月完成 1.5 亿美元 F 轮，估值 26 亿美元 [F 轮](https://www.finsmes.com/2021/07/pendo-raises-150m-in-series-f-funding.html)。产品包括 Product Analytics、In-app Guides、Session Replay、Listen（反馈）、Predict（流失/增购预测）、Agent Analytics、Command Center、Orchestrate、Data Sync、Sentiment、Leo（内置 AI）、MCP Server，以及 2026 年 5 月 27 日开放 beta 的 Novus；完整清单与定价见[定价页](https://www.pendo.io/pricing/)。 **事件模型。** Pendo 的模型是“页面 + 功能 + 访客 + 账户”。安装 snippet 后自动采集页面加载与功能点击，AI tagging 读取路由结构来识别页面与功能，减少手工标注 [产品分析](https://www.pendo.io/product/analytics/)。不在自动采集范围内的事件用 Track Events，客户端或服务端发送，必须带 Visitor 与 Account ID；每个应用最多 5,000 个命名 Track Event [Track Events](https://support.pendo.io/hc/en-us/articles/360032294151-Track-Events)。这个上限来自产品定位：Pendo 不打算做通用事件分析，它要的是“功能采用”这套结构。代价是复杂事件语义、自由探索与自定义分析会被卡住。 **分析与 AI。** 采用率、功能使用、路径、漏斗、留存、引导转化、NPS/CSAT、反馈主题、流失预测、Agent 采用与对话分析。它的强项是“从数据到动作”：同一套人群可以触发引导、邮件、Survey 或 Orchestrate 旅程。弱项是自由探索：不提供 SQL 探索界面，事件级分析受 5,000 个 Track Event 与页面/功能模型约束。AI 侧有 Leo、MCP 与 Novus；Novus 把入口从“安装 snippet”改成“连接代码库”，用 Agent 自动埋点、生成 PR、维护产品记忆，但要求人批准后才合并 [Novus](https://www.pendo.io/pendo-blog/novus-open-beta/)。它仍是 beta，稳定性、代码安全与定价都未定。 **部署与定价。** SaaS，GCP 上四个独立环境：美国、欧盟、澳大利亚、日本；环境之间不复制数据，客户可选择 [全球托管](https://support.pendo.io/hc/en-us/articles/22832528657179-Global-data-hosting)。合规页列 SOC 2、GDPR、TX-RAMP、HIPAA，未列 ISO 27001 [信任页](https://www.pendo.io/trust/)。按 MAU 计价：Free 500 MAU；Base、Core、Ultimate 均按自定义 MAU 报价，Base 不含回放（加购），Core 含回放，Ultimate 再加 Sentiment、Orchestrate、Listen [定价](https://www.pendo.io/pricing/)。MAU 定义为最近 30 个日历日内至少活跃一次的独立访客，多应用不额外收费。2026 年，Pendo Free 对新用户不再作为主推，改为 AI 原生免费产品 Novus（开放 beta，无 MAU 限制，付费层计划在 GA 后推出）[Pendo Free](https://www.pendo.io/pendo-free/)。 **MAU 经济学。** Pendo 的账单随客户活跃用户增长，而不是随事件量或席位。对 B2B SaaS，这与“客户成功”的计费逻辑一致；对 C 端或免费增值产品，MAU 会把大量不付费用户计入账单。一个 50 万 MAU 的消费级产品，Pendo 通常不是最优解；一个 5 万 MAU、客单价高的 B2B 产品，MAU 账单反而可预测。 **2025–26 的变化与限制。** 2025 年 7 月 9 日收购 Forwrd.ai，成为 Pendo Predict [Forwrd](https://www.pendo.io/news/pendo-acquires-predictive-ai-company-forwrd-to-strengthen-data-capture-and-decision-support-for-software-experience/)；2025 年 10 月收购 Product Collective [Product Collective](https://www.pendo.io/news/pendo-8th-annual-pendomonium-announcing-7-new-features-and-acquisition-product-collective/)；2026 年 2 月 3 日收购 Chisel Labs，Pendo 称其为 18 个月内第四笔收购、第三家 AI-native 公司，并在浦那设印度办公室 [Chisel](https://www.pendo.io/news/pendo-acquires-chisel-labs-to-help-product-teams-build-better-and-faster-with-agentic-ai/)；2026 年 5 月 27 日开放 Novus beta。更早的 2024 年 7 月 31 日，Zelta AI 已经成为 Listen 的反馈聚合能力，覆盖 150 多个来源 [Zelta](https://www.pendo.io/news/pendo-accelerates-ai-roadmap-with-acquisition-of-customer-intelligence-platform-zelta-ai/)。优势是离行动最近、MAU 计价与 B2B 客户成功指标一致、引导/Survey/反馈/预测在同一平台、四个数据区域对跨国企业友好。 限制是 MAU 对 C 端、免费用户多、季节性强的产品不友好；页面/功能模型不适合复杂事件语义与自定义分析；没有通用产品实验、Feature Flag 平台与 CDP，只有 Guide Experiments 用来测引导文案 [Guide Experiments](https://www.pendo.io/pendo-blog/how-to-use-pendo-guide-experiments/)；Track Events 上限 5,000；移动端与单页应用的自动识别仍有边界；Novus 仍是 beta，不能当成熟产品采购。 ## 2.6 能力对比矩阵 把八项能力压成一张表，先看结构，再看强弱。标签只表达相对位置，不替代 POC。 | 维度 | Amplitude | Mixpanel | Heap / Contentsquare | Pendo | |---|---|---|---|---| | 事件模型 | 强｜事件/用户/分组，Ampli 由 tracking plan 生成强类型 SDK | 强｜事件/属性/Group，Lexicon 做字典 | 中强｜autocapture 起家，虚拟事件可回溯 | 中｜页面/功能为主，Track Event 上限 5,000 | | Autocapture | 强｜Web 全量，移动采集安装与屏幕 | 中强｜Web 默认开，移动点击 beta 默认关 | 最强｜Smart Capture，移动原生与跨平台 | 中｜页面/功能自动识别，非全量点击 | | Warehouse | 强｜Snowflake 下推，数据不出仓库 | 中强｜仓库导入，主副本仍在 Mixpanel | 中｜Heap Connect 导出，可回溯 | 中｜Data Sync 单向导出 | | 回放 | 强｜Web/移动，默认留存 1 个月 | 强｜Web/移动，默认 30 天 | 强｜Contentsquare 回放与热图 | 中强｜Core/Ultimate 含，Base 加购 | | 实验 | 最强｜序贯、CUPED、bandit、holdout | 中强｜按 MEU 计费，Flag 同套餐 | 中｜Contentsquare 实验偏 Web | 弱｜仅 Guide Experiments | | 计价 | 事件量，不限席位 | 事件量，旧合同按 MTU | 会话量 | MAU | | 部署 | SaaS 美/欧；Snowflake Native | SaaS 美/欧/印 | SaaS；区域存储仅 Premier | SaaS 美/欧/澳/日 | | AI | 强｜Global Agent、Wave、MCP，可触发动作 | 中强｜Agent、根因分析，MCP 仍 beta | 强｜Sense、MCP，可写邮件/工单 | 中强｜Leo、MCP、Novus beta | 这张表最重要的不是谁有几项“强”，而是三件被表格遮住的事。 第一，事件模型一列的“强”含义不同。Amplitude 与 Mixpanel 强在语义可治理：事件名、属性、字典、废弃流程都有落点；Heap 强在采集覆盖：先收全量，再补虚拟事件；Pendo 强在页面/功能结构，但 5,000 个 Track Event 是硬上限。把三种“强”当成同一种能力，会在 POC 时得出错误结论。 第二，warehouse 一列必须拆成三种动作：下推、导入、导出。Amplitude 的 Snowflake Native 是下推，计算在客户仓库；Mixpanel 的 Warehouse Connectors 是导入，数据主副本仍在 Mixpanel；Heap Connect 与 Pendo Data Sync 是导出，方向相反。只有下推才真正改变数据主权与成本结构，导入和导出只是接口。 第三，AI 一列最容易被高估。四家都能做自然语言查询、异常解释、会话摘要；差别在能读哪些表、能不能写回业务系统、写之前谁批准。Contentsquare 的 Sense 能写邮件、工单并跑实验，Amplitude 的 Agent 能触发实验与内容变更，Pendo 的 Novus 能生成 PR 但要求人批准，Mixpanel 的 Agent 更偏查询与根因。采购时不要问“有没有 AI”，要问“AI 能读什么、能写什么、日志在哪里”。 ## 2.7 四家的共性局限 四家的短板高度相似。根因在商业模式，不在技术能力：卖给谁、按什么量收钱、靠什么模块向上销售，决定了它们优先做什么、延后做什么。 **一，语义资产不随数据走。** 原始事件可以导出，但事件命名、属性类型、owner、废弃状态、人群定义、看板注释、实验配置、引导文案不会跟着 CSV 走。Amplitude 的 Data/Govern、Mixpanel 的 Lexicon、Heap 的 Governance、Pendo 的 tagging 规则，成熟度依次下降；这是“谁对事件定义负责”的组织问题，与功能多少无关。迁移时最贵的一步，是把旧平台的“活跃用户”翻译成新平台的“7 天有事件用户”。 **二，计价与采集互相惩罚。** 按事件计价要求客户控制采集量，autocapture 全开会让账单失控；按会话计价鼓励采集，但长会话、低事件的产品会为“停留”付钱；按 MAU 计价把收入绑在客户的活跃用户上，C 端与免费增值产品会被不付费用户拖累。没有一种计价单位是中立的，选型时要先问：未来 12 个月，哪一种量最可能失控。 **三，warehouse-native 的三种模式常被混用。** 下推、导入、导出的架构与退出方式不同，定义见 1.4，本节不再展开。对四家而言，只有下推能让数据不出域；导入会制造第二个口径，导出只是数据离开平台。 **四，身份解析有硬边界。** Amplitude 不能合并两个已经建立的 User ID，跨项目只能用 User Mapping API；Mixpanel 用 $identify、alias、merge；Heap 用 identify、alias、账户；Pendo 用 Visitor 与 Account ID。边界本身不是问题，问题是边界不透明：合并错了不可回滚，漏斗与留存会在无人察觉的情况下改变。采购时要让厂商演示“匿名—登录—换设备—再登录—合并—拆分”的完整链路，而不是只看一张干净的图。 **五，行动端越深，退出越贵。** Amplitude 的实验、引导、CDP，Pendo 的 Guides、Listen、Orchestrate，Contentsquare 的回放、Survey、旅程，都是内容资产，不是原始数据。它们越有用，越难搬走。合同里要写三类东西：原始事件的可导出格式与频率、聚合层（人群、指标、看板）的可迁移描述、终止后的数据保留与删除时限。只写“客户拥有数据”不够，要写“以什么格式、多久之内、收不收费”。 **六，整合期与 AI 写权限，把风险从功能移到合同。** Heap 的两套价目表、Statsig 的“资产与团队分离”、Pendo 的连续收购，都说明产品线会换主人。AI 又在增加一种新风险：Agent 能写邮件、建实验、生成 PR，审批与回滚机制却各不相同。采购要把“控制权变更终止权、计价单位变更权、AI 训练条款、写操作审计”写进合同，而不是只审 SOC 2 证书。 还有一个边界常被忽略：这四家都不是 GA4 的替代品。GA4 的免费流量分析、广告归因与 BigQuery 导出仍是很多公司的基线；四家的价值在事件语义、身份、实验与行动。把它们当“更贵的 GA”会低估实施成本，也会错配预算。 > **判断**：四家的共性局限不是“功能不够”，而是“语义与行动都被锁在平台里”。数据可以导出，语义、内容与历史结论很难；这就是为什么迁移项目常常在“技术上线”之后才真正开始。 ## 2.8 启示：主平台、卫星工具与四条合同 对买方，结论不是“选哪家”，而是“哪一层做主平台、哪一层买卫星”。 | 层 | 建议 | 理由 | |---|---|---| | 事件语义与治理 | 主平台或自建，必须能导出 | 决定第三年还能不能信任数据 | | 分析体验 | 按团队成熟度选 | Mixpanel 上手最快，Amplitude 更深 | | 实验/Flag | 要深度选 Amplitude，否则外接 | Pendo 只有 Guide Experiments，Heap/CSQ 偏 Web | | 回放/体验 | 卫星工具 | Contentsquare/Heap 的强项，不必绑主平台 | | 应用内引导/采用 | 卫星工具 | Pendo 的强项，但 MAU 计价要算清 | 双供应商是理性选择，但要有主次：一个做“事件语义与实验”的主平台，一个做“回放/体验/引导”的专用工具；两边的身份与事件命名必须对齐，否则第二年就会陷入“两个真相”。 合同有四条比功能清单更重要。第一，计价单位变更权：厂商能否单方面把“事件”改成“MAU”或“行”。Amplitude 在 2023–2026 年换了三次尺，是最现实的案例。第二，续约涨幅上限：写死 5% 或 CPI，还是“按届时价目表”。第三，语义资产清单：事件定义、属性类型、人群、看板、实验配置、引导内容，哪些能导出、以什么格式。第四，AI 训练与写权限：客户数据是否用于训练、Agent 能写什么、谁批准、日志保留多久。 对做产品的人，四家的启示不是“再做一个事件分析”。事件分析、漏斗、留存、路径已经商品化，单点功能很难形成溢价。真正能形成差异的是三件事：事件语义的治理能力、身份解析的边界处理、从洞察到行动的最后一公里。Amplitude 用 Data/Govern 与 Experiment 把三件事串起来；Mixpanel 用 Lexicon 与仓库导入守住分析体验；Heap 用 autocapture 降低采集门槛；Pendo 用 Guides 把“看见”变成“改变”。如果要做新产品，优先选“某个垂直场景的语义标准 + 行动模板”，而不是“再多一个图表”。 最后，90 天内做三个测试，比看 30 页 PPT 有用。第一，在客户仓库里建一张宽表，验证“warehouse-native”是真下推还是隔夜同步。第二，做一次身份合并测试：匿名—登录—换设备—再登录，检查是否出现双 profile。第三，让 AI 回答 20 个有标准答案的问题，记录准确率与引用来源。三个测试都过，再谈价格。 > **判断**：2026 年的产品分析市场，功能差距在缩小，计价与数据主权在放大。选型的核心不是“谁的功能多”，而是“谁的事件语义能被我控制、谁的数据我能带走、谁的账单我能预测”。 ## 参考来源 - [Amplitude — Q2 2026 Financial Results](https://investors.amplitude.com/news-releases/news-release-details/amplitude-announces-second-quarter-2026-financial-results) - [Amplitude — FY2025 Financial Results](https://amplitude.gcs-web.com/news-releases/news-release-details/amplitude-announces-fourth-quarter-and-fiscal-year-2025) - [Amplitude — Product Index (llms.txt)](https://amplitude.com/llms.txt) - [Amplitude — Autocapture](https://amplitude.com/docs/data/autocapture) - [Amplitude — Data Docs](https://amplitude.com/docs/llms-data.txt) - [Amplitude — Feature Experimentation](https://amplitude.com/amplitude-experiment) - [Amplitude — Warehouse Native GA](https://amplitude.com/releases/warehouse-native-ga) - [Amplitude — Pricing](https://amplitude.com/pricing) - [Amplitude — Amplitude and Statsig](https://amplitude.com/blog/amplitude-and-statsig-partnership) - [Statsig — Statsig is joining OpenAI](https://statsig.com/blog/openai-acquisition) - [Amplitude — Acquires Command AI](https://amplitude.com/blog/amplitude-acquires-command-ai) - [Amplitude — Acquires Kraftful](https://amplitude.com/blog/amplitude-acquires-kraftful) - [Amplitude — Acquires InfiniGrow](https://www.amplitude.com/press/amplitude-acquires-infinigrow) - [Votefirst — Amplitude Pricing History](https://votefirst.app/en/pricing/amplitude) - [Mixpanel — Pricing](https://mixpanel.com/pricing/) - [Mixpanel — Legacy MTU Billing](https://docs.mixpanel.com/docs/pricing/legacy-mtu-billing) - [Mixpanel — Autocapture](https://docs.mixpanel.com/docs/tracking-methods/autocapture) - [Mixpanel — Warehouse Connectors](https://docs.mixpanel.com/docs/tracking-methods/warehouse-connectors) - [Mixpanel — EU Residency](https://docs.mixpanel.com/docs/privacy/eu-residency) - [Mixpanel — Lexicon](https://docs.mixpanel.com/docs/data-governance/lexicon) - [Mixpanel — Experiments](https://docs.mixpanel.com/docs/experiments) - [Mixpanel — MCP Connections](https://docs.mixpanel.com/docs/mcp-connections) - [Mixpanel — Metric Trees](https://mixpanel.com/blog/mixpanel-metric-trees/) - [Mixpanel — Acquires DoubleLoop](https://mixpanel.com/blog/mixpanel-acquires-doubleloop/) - [Bain Capital — Mixpanel $200M Investment](https://www.baincapitaltechopportunities.com/news/product-analytics-leader-mixpanel-secures-200-million-growth-investment-help-more-teams-build) - [Contentsquare — Completes Acquisition of Heap](https://contentsquare.com/press/contentsquare-completes-acquisition-heap/) - [Contentsquare — Product Analytics](https://contentsquare.com/platform/product-analytics/) - [Contentsquare — CSQ SDK Upgrade from Heap](https://docs.contentsquare.com/en/csq-sdk-ios/product-analytics/upgrade-from-heap-and-cs-sdk/) - [Contentsquare — AI-First Experience Platform](https://contentsquare.com/press/new-ai-first-experience-platform/) - [Contentsquare — Acquires Loris AI](https://contentsquare.com/press/contentsquare-completes-acquisition-of-loris-ai/) - [Contentsquare — Pricing](https://contentsquare.com/pricing/) - [Contentsquare — Trust Portal](https://trust.contentsquare.com/) - [Heap — Pricing](https://www.heap.io/pricing) - [Heap — Capture](https://www.heap.io/platform/capture) - [Heap — Heap Connect](https://www.heap.io/platform/connect) - [Heap — Developer Docs](https://developers.heap.io/llms.txt) - [SiliconANGLE — Contentsquare Raises $600M](https://siliconangle.com/2022/07/29/new-600m-financing-contentsquare-aims-humanize-digital-interactions/) - [Pendo — Pricing](https://www.pendo.io/pricing/) - [Pendo — Trust](https://www.pendo.io/trust/) - [Pendo — Global Data Hosting](https://support.pendo.io/hc/en-us/articles/22832528657179-Global-data-hosting) - [Pendo — Track Events](https://support.pendo.io/hc/en-us/articles/360032294151-Track-Events) - [Pendo — Product Analytics](https://www.pendo.io/product/analytics/) - [Pendo — Novus Open Beta](https://www.pendo.io/pendo-blog/novus-open-beta/) - [Pendo — Pendo Free](https://www.pendo.io/pendo-free/) - [Pendo — Acquires Zelta AI](https://www.pendo.io/news/pendo-accelerates-ai-roadmap-with-acquisition-of-customer-intelligence-platform-zelta-ai/) - [Pendo — Acquires Chisel Labs](https://www.pendo.io/news/pendo-acquires-chisel-labs-to-help-product-teams-build-better-and-faster-with-agentic-ai/) - [Pendo — Acquires Forwrd.ai](https://www.pendo.io/news/pendo-acquires-predictive-ai-company-forwrd-to-strengthen-data-capture-and-decision-support-for-software-experience/) - [Pendo — Guide Experiments](https://www.pendo.io/pendo-blog/how-to-use-pendo-guide-experiments/) - [FinSMEs — Pendo Raises $150M Series F](https://www.finsmes.com/2021/07/pendo-raises-150m-in-series-f-funding.html) - [Pendo — Product Collective acquisition](https://www.pendo.io/news/pendo-8th-annual-pendomonium-announcing-7-new-features-and-acquisition-product-collective/) --- # 03 · 商业平台（下）：回放、全渠道与平台巨头 > 回放、测量云与 CDP 被塞进同一张功能表，是采购里最贵的误判：三者卖的是三种商品，数据落点与计价单位都不同。 体验分析是这一轮 UBA 采购里最容易被买错的一层。FullStory、LogRocket、Glassbox、Quantum Metric 都被叫作“会话回放”，但四家卖的并不是同一种商品：一个卖隐私可控的行为数据层，一个卖前端排障的上下文，一个卖可举证的合规记录，一个卖大企业的体验度量。再往外一层，GA4 与 Adobe 卖的是测量入口与客户数据模型，Segment 卖的是管道。把这些放进同一张功能表打勾，结果通常是在法务评审、续费或迁移时才重新洗牌。 所以这一章不按“功能多少”排座次，而是按三个更硬的变量拆：数据落在哪、按什么计价、退出时能带走什么。这三个变量决定了产品形态，也决定了它在你栈里应该待在哪一层。 ## 3.1 体验分析的三种做法 回放厂商经常被放在一张表里比“有没有热图、有没有移动端、AI 强不强”，这是把三种生意当成一种功能。按“会话在这门生意里扮演什么”来分，市场只有三种做法。 | 做法 | 核心产物 | 代表 | 主要买单人 | 计价锚点 | 最大风险 | |---|---|---|---|---|---| | 会话即证据 | 可检索、可举证的会话记录 | Glassbox | 合规、数字体验、银行保险 | 企业合同 | 价格不透明，自助分析弱 | | 会话即数据层 | 分析、回放、引导、仓库导出共用一套会话 | FullStory、Quantum Metric | 产品/UX、企业 CX | 会话量 + 模块 + 留存 | 留存与导出成本随规模上升 | | 会话即调试上下文 | 回放与控制台、网络、性能、错误对齐 | LogRocket | 工程、支持 | 会话量 + 席位 + 留存 | 隐私默认弱，分析深度有限 | 三条路线的物理差异先于功能差异。FullStory 与 LogRocket 都用 DOM 变化重建会话，不是屏幕录像；Glassbox 用无埋点采集，官方称覆盖 100% 会话、平均每会话超过 1,000 个事件 [Glassbox 无埋点采集](https://www.glassbox.com/platform/tagless-data-capture/)。“100% 采集”是这类厂商的核心话术，它的真实含义是“不抽样”，不是“不丢事件”：网络中断、SDK 未加载、遮罩规则误伤，都会让会话缺失。采购时要把覆盖率拆成三层问：SDK 装载率、会话采样率、事件丢失率。 隐私默认值的差别，比功能差别更能决定项目能不能过法务。FullStory 把遮罩做在设备端，被排除的内容不上传 [Private by Default](https://help.fullstory.com/hc/en-us/articles/360044349073-Fullstory-Private-by-Default)；LogRocket 需要显式加 `data-private`，密码与信用卡字段由 SDK 自动处理 [LogRocket 隐私文档](https://docs.logrocket.com/docs/privacy)；Glassbox 默认遮罩、可定制 [Glassbox 隐私与安全](https://www.glassbox.com/platform/data-privacy-security/)；Quantum Metric 把加密放在客户端，称暴露的个人信息不跨网络传输 [Quantum Metric 回放说明](https://www.quantummetric.com/platform/session-replay/)。FullStory 与 Glassbox 把合规成本放进产品默认值，LogRocket 把它推给接入规范，Quantum Metric 把它压在客户端加密上。 移动端是不是“二等公民”，决定体验分析在 App 型产品里能不能用。FullStory 移动端是独立加购模块，支持 Android 与 iOS，回放不靠截屏 [FullStory 移动端说明](https://help.fullstory.com/hc/en-us/articles/360020623114-Does-Fullstory-work-with-native-mobile-apps)；LogRocket 全套餐覆盖 Android、iOS、React Native、Flutter，但 WebView 要另装 Web SDK [LogRocket 移动端支持](https://docs.logrocket.com/docs/mobile-feature-support)；Glassbox 把 Web、原生、混合应用统一采集；Quantum Metric 强调原生回放与 Web 回放在同一引擎渲染 [Quantum Metric 移动端](https://www.quantummetric.com/platform/mobile-app-analytics/)。 留存与计价是同一件事的两面。体验分析按会话卖，厂商被鼓励多录、长留、少采样。FullStory 的免费层给 30,000 会话/月、10 个席位、5,000 条服务端事件/月、1 年回放与产品分析留存 [FullstoryFree 方案](https://help.fullstory.com/hc/en-us/articles/360020623354-FullstoryFree-Plan)；LogRocket 的扩展留存会把被组织成员观看超过 1 秒的会话自动保留 12 个月，上限是当月会话配额的 5% [扩展留存](https://docs.logrocket.com/docs/extended-session-retention)。这两条规则说的是同一件事：留存不是产品默认值，是合同变量。 | 计价锚点 | 代表 | 厂商被鼓励做什么 | 客户要防什么 | |---|---|---|---| | 会话 | FullStory、LogRocket、Heap | 多录、长留、少采样 | 留存与附加模块推高账单 | | 事件 | Amplitude、Mixpanel、GA4 360 | 多埋点、细化参数 | 全埋点自我惩罚，治理成本上升 | | server call | Adobe Analytics | 多接页面与请求 | 同一行为被拆成多次调用 | | 数据行 | Customer Journey Analytics | 多接数据源、拉长历史 | 13 个月核心数据之外的容量费 | | MAU | Pendo | 活跃用户增长 | 不付费的活跃用户也计入账单 | 同一个 1,000 万月活的产品，按会话、事件、MTU、行算出来的数字可能差一个量级。这是计量口径问题，不是谈判问题：会话按访问去重，事件按上报计数，MTU 按月活用户计数，行按天级平均行数计数。供应商只给年费、不给公式时，比价其实是在比折扣。 回放是主入口还是附属模块，也能看出产品形态。Heap 以 autocapture 起家，先采集后定义，回放是加购，计价按会话 [Heap 定价](https://www.heap.io/pricing)；Pendo 的模型是“页面 + 功能 + 访客 + 账户”，回放从 Core 套餐才有，计价按 MAU [Pendo 定价](https://www.pendo.io/pricing/)。前者把语义后置到分析时，后者把语义放在页面与功能层——语义越靠前，治理成本越高，可复用性也越强。 全渠道常被误解为“Web、App、线下都接上”。难点其实是身份、会话与口径对齐，市场上对应三种做法：平台云（GA4/Firebase、Adobe AEP）以采集入口和身份图为核心；CDP（Segment）以事件管道和身份图为核心，把数据送到 700 多个目的地；体验分析以会话为核心，补移动端与线下，但跨渠道身份弱。三条路线的共同瓶颈都是身份：匿名到登录的合并、跨设备、家庭/企业账号、线下会员 ID。谁拥有身份图，谁就拥有“全渠道”的解释权。 > **判断**：体验分析的分水岭不是“有没有回放”，而是“回放数据能不能被治理、被检索、被导出、被合规引用”。四家在这一点的答案不同，价格与合同结构也就无法直接比较。 ## 3.2 FullStory Fullstory, Inc. 总部亚特兰大，独立私营公司。2025 年 11 月 3 日它收购了数字采用平台 Usetiful，官方称这是公司首次并购 [Usetiful 收购](https://markets.businessinsider.com/news/stocks/fullstory-acquires-usetiful-turning-digital-insights-into-decisive-actions-1035476979)。它给自己的定位是 behavioral data company，不是回放播放器。这个定位决定了产品结构：分析、回放、热图、引导与问卷、仓库导出、Activation 都挂在同一套会话数据上。 技术选择上，FullStory 用 DOM 变化重建会话；Web 端自动采集，服务端事件按套餐限额；移动端是独立附加模块，支持 Android 与 iOS，官方明确不做截屏，文本、图片与个人数据在设备端默认遮罩。这让“Private by Default”成为产品能力而不是政策承诺：遮罩发生在设备端，被排除的内容没有上传。 部署是它的硬约束。数据在 Google Cloud Platform，只有美国 us-central1 与欧盟 europe-west3 两个区域，账户彼此独立、不能跨区迁移 [FullStory 数据驻留](https://help.fullstory.com/hc/en-us/articles/8901113940375-Fullstory-Data-Residency)。没有亚太区域，跨境团队要么接受美/欧，要么放弃。定价按会话量、产品分析与回放留存（两者可分开设置）、模块与移动端附加报价，官方页面不公开美元价 [套餐类型](https://help.fullstory.com/hc/en-us/articles/360020828173-Choosing-a-Fullstory-plan-type)；免费层 FullstoryFree 承担获客，也给了一个可试用的分析链路。 2025–2026 年的动作集中在“从看见到干预”。2025 年 4 月发布 StoryAI agent 套件 [2025 年 4 月发布](https://www.fullstory.com/fullstory-unveils-ai-agent-powered-behavioral-data-solutions/)；Session Summaries 包含在 Advanced 与 Enterprise，Opportunities 与 Ask StoryAI 属于 StoryAI Premium，StoryAI Home 与 Activation Agents 仍是 Early Access [StoryAI 说明](https://help.fullstory.com/hc/en-us/articles/30944300173719-Overview-of-StoryAI)。同年 11 月收购 Usetiful，把引导、问卷与应用内提示接进行为数据。这条路线不需要赢 CDP，只需要让产品团队把 FullStory 当成“看行为的第一站”。 免费层的条款值得单独读。官方写明 Fullstory 拥有匿名非 PII 数据的所有权，并可将这些数据用于 AI 模型训练与行业基准 [FullstoryFree 条款](https://help.fullstory.com/hc/en-us/articles/360020623354-FullstoryFree-Plan)。这不是隐藏条款，而是“免费换数据”的定价：只看“30,000 会话免费”，就会漏掉数据权属这一行；在意训练条款的话，付费版的 DPA 才是谈判重点。 > **判断**：FullStory 卖的是“隐私可控的行为数据层”，不是“回放播放器”。它的免费层既是获客入口，也是数据权属的分界线；企业采购必须先谈免费层的数据使用，再谈价格。 ## 3.3 LogRocket LogRocket, Inc. 总部波士顿，独立私营公司，官方产品页称“3,000+ 客户” [Galileo 产品页](https://logrocket.com/products/galileo-ai)；2024–2026 年未查到所有权变更或并购公告（待核实）。它从工程排障切入：会话回放叠加 console、network、Redux、性能与错误上下文，卖给工程、支持与产品团队，开发者自助接入，按会话付费。 模块覆盖回放、产品分析、错误追踪、前端性能、热图、问卷、Galileo AI、MCP/API、Streaming Export 与自托管。一个容易被低估的条款是：分析事件、错误事件与日志在全部套餐不设量 [官方定价](https://logrocket.com/pricing)。 部署与计价的限制同样明确。SaaS 客户数据托管在美国，官方 FAQ 直接写“For SaaS customers, data is hosted in the United States” [官方 FAQ](https://docs.logrocket.com/docs/q-a)；需要数据不出内网只能选 Enterprise 自托管。定价按会话量，默认 25,000 会话/月配置下年付起价 176 美元/月，最终价取决于席位、留存长度与 Streaming Export；Pro 含 Galileo，Enterprise 含自托管与无限席位；14 天试用，没有免费层。留存按合同配置，扩展留存把被观看超过 1 秒的会话自动留 12 个月，上限为当月配额的 5%。 2025–2026 年的变化围绕 Galileo 展开。2026 年它推出 Issues 2026 Beta、Signals、AI 编码 agent 派发与 MCP [Issues 2026 文档](https://docs.logrocket.com/docs/issues-2026)，Galileo 从“会话摘要”扩展到问题检测、漏斗洞察、反馈分析与异常检测。它没有把自己做成“单一数据源”，而是把回放变成工程工作流里的一个上下文入口。 短板也很集中：隐私不是默认遮罩，需要显式加 `data-private`；SaaS 只在美国，未见欧洲区域选项；会话量一大，账单增长很快；分析深度不如专业产品分析平台；企业合规模块不如 Glassbox 完整。 LogRocket 的护城河是“开发者愿意装”，代价是“隐私默认值偏弱”：它在工程组织里渗透力强，但要让法务放心，遮罩规则必须写进接入规范，而不是依赖 SDK 默认。 ## 3.4 Glassbox 与 Quantum Metric 这两家经常被并列，但一个卖合规，一个卖度量，合同逻辑几乎相反。 Glassbox 2010 年成立，总部伦敦，曾在特拉维夫证券交易所上市（TASE: GLBX）。2024 年 5 月 20 日与 Alicorn Venture Partners 达成全现金交易，估值约 1.5 亿美元，转为私有公司 [Alicorn 收购公告](https://www.glassbox.com/news/glassbox-to-be-acquired-by-alicorn-venture-partners/)；2025 年 11 月 4 日收购实时异常检测公司 Anodot [Anodot 收购公告](https://www.glassbox.com/news/glassbox-anodot-acquisition/)。客户集中在银行、保险、医疗、电信，官方称服务“全球十大银行中的六家”。 产品清单很长：回放、旅程分析、移动端分析、热图、无障碍检测、Rapid Response、Insights Assistant（GIA）、漏斗与受挫分析，以及两个真正的差异件——Tagless Data Capture 与 Digital Record Keeping（Session Vault）[Glassbox 平台](https://www.glassbox.com/platform/)。采集是无埋点的，官方称覆盖 100% 会话、平均每会话超过 1,000 个事件；Session Vault 对指定会话做时间戳、不可篡改、可检索的留存 [数字记录](https://www.glassbox.com/platform/digital-record-keeping/)。这两件事合起来，才是“可举证”的含义：不是把个别会话录下来，而是让一段会话在争议里能被当作记录引用。 部署与合规是它的定价权来源：多租户云、单租户云（AWS 或 Azure）、本地部署三种形态；官方称符合 HIPAA、GLBA、PCI、CCPA、GDPR，持有 ISO 27701、SOC 2 Type II、ISO 27001、ISO 27017、ISO 42001 [隐私与安全](https://www.glassbox.com/platform/data-privacy-security/)。GIA 基于 Microsoft Azure OpenAI，官方称客户数据不会被用于训练未来模型 [GIA 页面](https://www.glassbox.com/platform/glassbox-insights-assistant/)。价格不公开，按会话量、部署形态与合约定价；“每年超过 1 万亿会话”是营销口径，未经审计。 Quantum Metric 走另一条路。公司总部科罗拉多斯普林斯；2021 年 1 月获 Insight Partners 领投的 2 亿美元 B 轮，估值超过 10 亿美元 [2021 年融资公告](https://www.insightpartners.com/ideas/quantum-metric-raises-200-million-with-valuation-above-1-billion-to-help-enterprises-build-better-digital-products-faster/)；截至 2026 年 10 月仍为独立私营公司，未查到被收购的官方公告（待核实）。客户是大型企业的数字、产品、UX、CX 团队，集中在零售、金融、旅行、电信、游戏、医疗。 它的产品重心是“多触点 + 移动端同权 + agentic”。回放、Segment Builder、Autocapture（官方称 300+ 指标）、页面性能、移动端分析、Felix AI Agentic、旅程、交互热图、机会分析、Voice of Customer、监控告警、Data Activation，以及 Adobe Experience Platform Connector 与 Salesforce Lightning Analytics [Quantum Metric 平台](https://www.quantummetric.com/platform/)。原生移动回放与 Web 回放在同一引擎渲染，官方称接近同等分析能力；自定义事件可远程配置，不必发版。Felix AI 于 2024 年 4 月上线，Felix Agentic 在 2026 年 7 月 16 日正式 GA，能持续监控、检测异常、定位根因并量化影响 [Felix Agentic GA](https://www.quantummetric.com/press-releases/quantum-metric-launches-next-evolution-of-enterprise-agentic-analytics)。 计价按年度会话量、数字触点数量、附加模块与专业服务，不按席位或 credits [官方定价](https://www.quantummetric.com/pricing/)；留存期限、SLA、数据区域等细节公开资料不足（待核实）；“每月 80 亿会话、覆盖全球 50% 互联网用户”无法独立核实。这是它相对 Glassbox 的另一个差别：Glassbox 把“合规”写在资质清单里，Quantum Metric 把“能力”写在新闻稿里，两者都需要 RFP 才能落到合同。 > **判断**：Glassbox 卖的不是“更好的回放”，而是“可被监管接受的数字证据链”；Quantum Metric 卖的也不是回放，而是“移动端不降级的企业体验度量 + 已 GA 的 agent”。两家的共同短板是透明度：价格、留存、区域、SLA 都要靠 RFP 才能确认。 ## 3.5 GA4 与 Firebase 的真实边界 GA4 的免费不是“低成本方案”，是获客入口。它在四个地方设了硬边界：留存、采样、阈值、导出。这四个边界决定了它能回答什么问题，也决定了什么时候必须买 360。 | 边界 | 标准版 | 360 | 对分析的含义 | |---|---|---|---| | 数据留存 | 用户级/事件级数据可选 2 或 14 个月 | 可选 2、14、26、38、50 个月 | 跨年同比与长周期留存，标准版做不了 | | 探索查询采样 | 单次查询上限 1,000 万事件 | 上限 10 亿、默认 1 亿；未采样探索每天 20,000 tokens、单次最多 5,000 | 大属性的一次探索可能只覆盖月事件的一小部分 | | 数据阈值 | 由系统定义、不可调整 | 阈值机制相同，门槛不同 | 细分到小群体时数字会“消失”，不是查询写错 | | BigQuery 导出 | 每日导出，每日上限 100 万事件 | 数十亿事件，流式导出不限量 | 想留全量原始事件，必须走 360 或自建采集 | | 结构上限 | 25 参数/事件、25 用户属性、50 个事件级自定义维度/指标、100 个受众、30 个关键事件 | 100、100、125、400、50 | 事件语义一复杂，先撞到的是结构上限 | | 计价 | 免费 | 按事件量，第三方口径约 5 万美元/年起 | 免费层省的是软件费，不是总成本 | 这张表里有三行经常被误读。第一行是留存：设置只影响探索与漏斗报告，不影响标准聚合报表 [数据保留说明](https://support.google.com/analytics/answer/7667196?hl=en)——同一份数据在报表与探索里能看到的范围不同，跨团队对数时会被当成“数据不准”。第二行是阈值：它由系统定义、不可调整，涉及人口统计与搜索查询时可能直接隐藏数据 [数据阈值说明](https://support.google.com/analytics/answer/9383630?hl=en)，这是产品分层，不是 bug。第三行是结构上限：标准版 25 个参数、25 个用户属性、50 个事件级自定义维度，一旦要按业务线、渠道、实验分组细分，先耗尽的往往是这些配额，而不是事件量 [GA4 360 限额](https://support.google.com/analytics/answer/11202874?hl=en)。 采样可以做一个粗算。一个标准版属性每月产生 3 亿事件，单次探索查询上限 1,000 万，那么一次查询最多覆盖约 3.3% 的月事件；360 把上限提到 10 亿，才可能在不采样的前提下看全量 [采样说明](https://support.google.com/analytics/answer/13331292?hl=en)。漏斗步骤越多、维度越细，采样误差越容易被放大；这也是为什么“报表看起来对、一拉细分就不对”在 GA4 里格外常见。 BigQuery 导出是另一个分界。标准版每日导出上限 100 万事件，360 为“数十亿”，流式导出不限量 [BigQuery 导出](https://support.google.com/analytics/answer/9358801?hl=en)；Firebase 的导出为每日同步，单日上限同样是 100 万事件 [Firebase 导出](https://firebase.google.com/docs/projects/bigquery-export)。这意味着移动端产品想用 BigQuery 做全量归因，先要确认自己是否已经在 360 或自建采集上；否则“数据在 BigQuery 里”只是一部分数据。 360 到底买到什么，可以压成四项：未采样探索、更长留存、更高结构上限、更大导出与限额。它不是“更快的 GA4”，而是把上述四个上限抬高的企业合同。价格官方不公开，Google 合作伙伴 Cardinal Path 在 2022 年给出的口径是“零售起价 50,000 美元/年，含 2,500 万事件/月，超出按量计价” [Cardinal Path 计价分析](https://www.cardinalpath.com/blog/ua-360-vs-ga4-360-pricing-model)；PostHog 在 2024 年也给出“5 万美元/年起”的说法（[PostHog 成本分析](https://posthog.com/blog/google-analytics-cost)）。两家都不是 Google 官方报价：一家是合作伙伴，一家是竞品，只能作量级参考。 2025–2026 年的产品更新没有改变这些边界。2026 年 5 月 13 日新增 AI Assistant 流量渠道识别（ChatGPT、Gemini、Claude 等），9 月 9 日原生 Dashboards 上线 [2026 年更新](https://support.google.com/analytics/answer/9164320?hl=en)。这些是入口层的改进，不是计量层的松动。Consent Mode v2 增加 `ad_user_data` 与 `ad_personalization` 两个参数 [Consent Mode 文档](https://developers.google.com/tag-platform/security/guides/consent)，它影响 Google 的建模与广告数据使用，但不等于法律意义上的合规，仍需 CMP、DPA 与保留策略配合。 区域是另一个待确认项。GA4 由 Google 托管，标准版通常不提供客户自选区域（待核实）；BigQuery 数据集可以选择区域，但 GA4 原始采集区域并不由此决定（合同细节待核实）。GA4 没有原生回放，也不是 CDP；把它当“免费版 Adobe”或“轻量回放工具”，都会在第一次做归因审计时暴露。 > **判断**：GA4 的真实边界不在“能不能看”，而在“能不能留下、能不能导出、能不能不采样”。一旦问题变成“看三年、跑十亿事件、做归因审计”，免费版就会把成本推给 360、BigQuery 与实施服务。 ## 3.6 Adobe Analytics 与 Customer Journey Analytics Adobe 这两年做的不是产品升级，是换数据模型。Adobe Analytics（AA）用 report suite、prop、eVar、event 与 server call；Customer Journey Analytics（CJA）用 AEP dataset、XDM schema、connection 与 data view。官方迁移指南写得很直白：CJA 没有 report suite，等价物是 connection 加 data view [迁移指南](https://experienceleague.adobe.com/en/perspectives/migrating-from-adobe-analytics-to-customer-journey-analytics)。这不是改名，是把“报表套件”换成“数据湖上的视图层”。 采集与分析也跟着换。推荐路径是 Web SDK（alloy.js）发到 Edge Network，再进 AEP；AppMeasurement 可迁移。分析侧仍是 Analysis Workspace、归因（组件级模型、容器、回看窗口）、Guided Analysis、预测、异常告警、漏斗/留存/路径；CJA 的 data view 负责把 schema 元素定义成维度与指标，并控制归属与治理。这是它和 GA4“一个属性一套维度”最大的结构差异：同一个 connection 上可以并存多套 data view，服务不同业务线、不同口径、不同权限。 治理粒度直接写进了产品说明。每个 connection 可建 500（Foundation）、600（Select）、750（Prime）、1,000（Ultimate）个 data view；Full Table Export 每次可导 300 万、3,000 万、1.5 亿、3 亿行；Data Distiller 按 compute hours 计费，Query Service 默认 5 个并发用户 [CJA 产品说明](https://helpx.adobe.com/legal/product-descriptions/customer-journey-analytics.html)。这些数字说明它的设计对象是“多品牌、多国家、多团队共用一套事件”的组织，而不是一个产品团队。 计价是合同事件，不是价目表。AA 按 Primary/Secondary Server Call 卖，分 Select、Prime、Ultimate；Foundation Pack 自 2024 年 1 月 1 日起不再销售、升级或续约 [AA 产品说明](https://helpx.adobe.com/legal/product-descriptions/adobe-analytics.html)。CJA 按“每百万行数据”卖，同样分四档；CJA 含 13 个月以内的核心数据，超过要买 Extended Data Capacity 或历史数据附加包；月报表请求从 50 万到 500 万次。Adobe Analytics Evolution 是迁移期的过渡授权，只能授权一次、不可续约。这套合同把客户从“按请求计费”推到“按数据量计费”。 迁移的成本也不只是许可证。AA 到 CJA 是架构重做：schema 先行、身份解析、连接与 data view 治理、历史回填、双轨运行。官方指南把“先定用例”放在第一步，说明这是指标治理项目。对已经深度使用 Adobe Experience Cloud 的企业，这是“留在生态内”的选择；对没有 AEP 的企业，迁移成本可能高于换一家工具。 AI 的位置需要说清楚。AEP AI Assistant 在 2024 年 7 月 25 日 GA，嵌在 Real-Time CDP、Journey Optimizer 与 CJA 里，能回答产品问题、执行任务、生成受众与旅程 [AEP AI Assistant GA](https://news.adobe.com/news/news-details/2024/media-alert-adobe-announces-general-availability-of-adobe-experience-platform-ai-assistant-to-supercharge-enterprise-productivity)；CJA 里的助手更偏文档解释与排障，不是自主分析 agent。2026 年 2 月起，Content Analytics 不再作为 CJA 附加包销售，只能单独购买——分析正在被拆成更多可单独计价的能力。 换句话说，Adobe 真正卖的不是 Analysis Workspace，而是 AEP 上的客户数据模型与合同：data view 与行计价决定了它卖给有治理需求的大企业，13 个月的核心数据则把“历史”做成了可售卖的容量。 ## 3.7 CDP 不是分析 Segment 的位置，要看它在母公司叙事里的权重。Twilio 在 2024 年 3 月 5 日结束对 Segment 的战略评估，结论是保留而非出售；当时 Segment 占 Twilio 2023 年收入的 7%，客户超过 8,000 家，并设定了 2025 年二季度非 GAAP 运营盈亏平衡的目标 [Twilio 2024 年评估](https://www.twilio.com/en-us/press/releases/twilio-concludes-operational-review-of-segment)。到 2026 年二季度，Twilio 收入 15 亿美元、同比增长 22%，电话会的主角是 Messaging、Voice、Conversation Memory 等通信与 AI 产品，Segment 没有出现在可见的 prepared remarks 与 Q&A 里 [2026 年 Q2 财报电话会](https://www.fool.com/earnings/call-transcripts/2026/08/13/twilio-twlo-q2-2026-earnings-call-transcript/)。这不等于停服，但说明它在母公司叙事中的权重在下降。 它卖的东西其实很清楚：Connections（官方称 700+ 应用）、Warehouses、Reverse ETL、Functions、Protocols、Unify、Engage。数据模型是 Segment Spec：identify、track、page、screen、group、alias；Tracking Plans 与 Protocols 做 schema 控制；仓库是特殊目的地，按批加载、自动调整 schema，不是实时查询引擎 [仓库目标文档](https://www.twilio.com/docs/segment/connections/storage/warehouses)。身份靠 Unify 的 Identity Graph 合并 cookie、device、email 与自定义 external ID，支持匿名会话合并、user:account 与 merge protection，但需要 Business 套餐 [身份解析文档](https://www.twilio.com/docs/segment/unify/identity-resolution)。 部署与计价同样有边界。美国（默认俄勒冈）与欧洲双区域；只有 EU workspace 才把数据存在欧盟，区域间可故障转移但不跨区，Regional Segment 需要 Business 套餐 [区域文档](https://www.twilio.com/docs/segment/guides/regional-segment)。按每月跟踪用户数（MTU）计价，官方定价页只给免费试用，Business 与 CDP 套餐按量定制报价 [官方定价](https://segment.com/pricing/)；Warehouse 在 Free/Team 只能 1 个，Business 可多个。 关键在分析层：Segment 本身不做漏斗、留存、路径探索。分析发生在仓库、BI 或下游 UBA 工具里，Engage 只负责人群与 Journey 编排。它解决“把事件送到哪里、把身份并起来、把人群发出去”，不解决“为什么转化掉了”。 | 问题 | Segment（CDP） | UBA（Amplitude/GA4/FullStory 等） | |---|---|---| | 核心资产 | 事件管道、身份图、目的地 | 事件语义、分析原语、可视化 | | 事件定义 | Spec + Tracking Plan，偏采集治理 | 分析模型 + 指标口径 | | 身份 | 强：跨端、跨系统、账户级 | 中：以产品内 user_id 为主 | | 分析 | 不做漏斗/留存探索 | 核心能力 | | 行动 | 强：受众下发、Journey、Reverse ETL | 弱到中：看板、告警、实验/引导 | | 计价 | MTU + 目的地 + 合同 | 事件/会话/席位 | | 数据落点 | 客户仓库 + Segment | 厂商云 + 可选仓库导出 | | 退出 | 管道可替换，身份图难迁 | 历史事件可导出，语义难迁 | 边界可以用三个问题判断：谁定义指标、谁解释原因、谁执行动作。Segment 定义事件规范与身份，但不定义指标；UBA 定义指标与探索，但通常不拥有全渠道身份；执行动作可能落在 CDP、营销云或实验平台。三者重叠的地方，正是采购最容易重复付费的地方。 这条边界正在被两边侵蚀。UBA 向上做人群下发与激活（FullStory 的 Anywhere: Activation、Quantum Metric 的 Data Activation、Amplitude 的 Activation），营销云向下做数据管道与实时对话（Twilio 把 Conversation Memory 接进 Segment 画像，Adobe 用 Real-Time CDP 承载 AEP 受众）。Segment 的中间位置最稳，也最容易被替代：管道本身正在同质化，身份图才是它真正难迁的部分。mParticle 等同层产品缺少可核对的一手文档，不展开。 > **判断**：Segment 的价值在“管道与身份”，不在“分析”。把它当 UBA 买，会得到一套昂贵的 ETL；把它当客户数据基础设施买，才是正确用法。 ## 3.8 对比矩阵 先看四家体验分析。 | 维度 | FullStory | LogRocket | Glassbox | Quantum Metric | |---|---|---|---|---| | 主要买单人 | 产品/UX/客服 | 工程/支持/产品 | 合规/数字体验/银行保险 | 企业数字/产品/CX | | 采集方式 | DOM 重建 + 自动采集 | DOM 回放 + 控制台/网络/Redux | 无埋点，官方称 100% 会话 | 持续采集，官方称 300+ 指标 | | 移动端 | 加购，Android/iOS | 全套餐，Android/iOS/RN/Flutter | Web/原生/混合统一采集 | 原生回放与 Web 同引擎 | | 隐私默认 | Private by Default，设备端遮罩 | 需显式 `data-private` | 默认遮罩，可定制 | 客户端加密，PII 不出端 | | 留存 | 免费 1 年；付费可配 | 合同配置；被观看会话可延至 12 个月 | Session Vault 可配，可长期留存 | 不公开（待核实） | | 部署 | SaaS，美/欧两区 | SaaS 美国；企业自托管 | 多租户/单租户/本地 | SaaS（本地部署待核实） | | 计价 | 会话 + 模块 + 留存 | 会话 + 留存 + 席位 | 企业合同 | 年度会话 + 触点 + 服务 | | AI 状态 | StoryAI，部分 Early Access | Galileo GA；Issues 2026 Beta | GIA GA；Anodot 整合中 | Felix Agentic 已 GA | | 实验 | 未见原生模块 | 未见原生模块 | 未见原生模块 | 未见原生模块 | | 主要短板 | 无亚太区；移动加购 | 隐私默认弱；美国托管 | 价格不透明；自助弱 | 价格不透明；公开细节少 | 表里三行最容易被忽略，也最容易翻车：谁承担合规成本（做进 SDK、交给接入方、做进产品、压在客户端，四种答案）；移动端是不是加购；留存按什么口径计。三种差异只能进合同。 四家都没有原生实验模块。“回放 + 实验”要么靠集成（回放看现象、实验平台做因果），要么靠分析平台自带（Amplitude 的 Experiment、Contentsquare 的 Experimentation）；指望回放厂商回答“这个改动有没有效”，是把观察工具当成了推断工具。 再看平台型玩家，它们的比较单位完全不同。 | 维度 | GA4 / Firebase | Adobe Analytics / CJA | Segment | |---|---|---|---| | 数据落点 | Google 托管 + BigQuery | AEP 数据湖 + Workspace | 客户仓库 + Segment | | 计价单位 | 免费；360 按事件量 | AA 按 server call；CJA 按百万行 | MTU + 目的地 | | 身份 | User-ID、设备、Google 信号 | AEP Identity Service、字段拼接 | Identity Graph，跨端跨系统 | | 分析原语 | 报表、探索、受众、归因 | Workspace、归因、Guided Analysis、预测 | 不做漏斗/留存/路径 | | 行动 | Google Ads、DV360 | RT-CDP、Journey Optimizer、Target | 受众下发、Journey、Reverse ETL | | 最适合 | 广告测量、免费起步、BigQuery 生态 | 多品牌、跨渠道、强治理的大企业 | 工具多、要统一事件与身份的组织 | 两张表放在一起，结论不是“谁分高”，而是“比较单位不同”。体验分析按会话，平台云按事件、server call 或行，CDP 按 MTU。同一组用量，换个锚点就能差一个量级。矩阵的用法是先确认买的是哪一层计量，再看这一层里谁的边界更匹配。 所以三张表不能合并成一张：合并的那一刻，你已经在用“功能数量”替代“计量单位、数据落点与退出能力”这三个真正决定三年成本的变量。 ## 3.9 启示 对做产品的人，第一件事不是接 rrweb，而是定三件事：遮罩在端上还是云上、移动端是否同权、留存与导出如何计价。FullStory 的端上遮罩、Glassbox 的 Session Vault、LogRocket 的 `data-private` 是三种工程取舍，没有一种能自动覆盖所有框架；端上遮罩还要处理选择器稳定性与动态内容。回放的长期成本不在存储，而在“错误采集之后的删除与举证”。 对采购，五个问题必须先问，再谈价格。 1. **默认遮罩是什么？** 是默认排除与遮罩，还是需要客户逐元素配置？FullStory 与 Glassbox 默认更严，LogRocket 需要显式配置。 2. **移动端是不是二等公民？** 加购、全套餐、统一采集、同引擎，四种答案对应四种成本。 3. **留存与导出怎么计价？** GA4 的 14 个月、CJA 的 13 个月、FullStory 的 1 年免费留存，都是合同变量，不是产品默认值。 4. **AI 用不用我们的数据训练？** FullStory 免费层保留匿名数据用于训练，Glassbox 的 GIA 明确不用于训练，其余要逐条谈 DPA。 5. **退出时能带走什么？** 原始事件、身份图、回放、看板定义、审计日志，哪些能导、以什么格式、收不收费。 把这五个问题做成评分卡：默认遮罩 20 分、移动端 15 分、留存与导出 20 分、AI 数据条款 20 分、退出能力 15 分、总价 10 分。权重按行业调整：金融把合规与本地部署提到 30 分，互联网产品把分析与协作提到 30 分。评分卡不替代 POC，但能防止“演示很漂亮、合同签完才发现不能用”。 对平台方，三条设计原则可以照抄：端上遮罩、事件语义治理、仓库可导出。端上遮罩决定法务能否签字；事件语义治理决定第三年数据还能不能用；仓库可导出决定客户敢不敢把核心分析放上来。三条都不便宜，但都比“再做一个图表”更难被替代。 对中国市场，GA4、Adobe、Segment 的公开方案都不覆盖大陆：没有本地区域与私有化选项，也不适配小程序与鸿蒙；可复用的是三条设计原则。“支持私有化”也不等于“能规模运维”，升级、备份、监控与多租户隔离才是真实成本。 | 层 | 建议 | 理由 | |---|---|---| | 采集与遮罩 | 自建或深度定制 | 合规与数据权属的分界线，不能外包 | | 会话存储与留存 | 按举证需求分层 | 全量长留存很贵，只有争议与审计场景需要 | | 分析原语 | 买成熟产品 | 漏斗、留存、路径已商品化，自建 ROI 低 | | 身份图 | 自建或绑定 CDP | 全渠道解释权的来源，迁移成本最高 | | 行动层 | 买或集成 | 引导、实验、人群下发变化快，自建跟不上 | | 合规举证 | 买 | 时间戳、不可篡改、可检索，属于资质与流程 | 四个反例值得写进采购备忘。**把回放当证据**：回放是重建，不是原始录像，遮罩、采样、浏览器差异都会影响“所见即所得”；真正要举证时，带时间戳、不可篡改的留存才算记录。**把 CDP 当分析**：Segment 能把事件送到 700 多个目的地，但它不告诉你漏斗在哪一步掉了；没有分析层，CDP 只会让错误的事件更快流向更多系统。**把 GA4 免费当低成本**：14 个月留存与采样上限，会在数据量上来后迫使你买 360、BigQuery 与实施服务。**把 AI 摘要当结论**：摘要能缩短看会话的时间，但替代不了假设、采样与统计判断；事件语义错了，AI 只会更快地给出错误解释。 > **判断**：未来 24 个月，体验分析的竞争点是“留存与举证”，平台巨头的竞争点是“身份图归谁”，CDP 的竞争点是“能不能证明自己不只是管道”。三者会在同一张采购单上相遇，但不会合并成同一个产品。 ## 参考来源 - [FullstoryFree Plan](https://help.fullstory.com/hc/en-us/articles/360020623354-FullstoryFree-Plan) - [Choosing a Fullstory plan type](https://help.fullstory.com/hc/en-us/articles/360020828173-Choosing-a-Fullstory-plan-type) - [Fullstory Private by Default](https://help.fullstory.com/hc/en-us/articles/360044349073-Fullstory-Private-by-Default) - [Fullstory Data Residency](https://help.fullstory.com/hc/en-us/articles/8901113940375-Fullstory-Data-Residency) - [Does Fullstory work with native mobile apps?](https://help.fullstory.com/hc/en-us/articles/360020623114-Does-Fullstory-work-with-native-mobile-apps) - [Overview of StoryAI](https://help.fullstory.com/hc/en-us/articles/30944300173719-Overview-of-StoryAI) - [Fullstory Unveils AI Agent-Powered Behavioral Data Solutions](https://www.fullstory.com/fullstory-unveils-ai-agent-powered-behavioral-data-solutions/) - [Fullstory acquires Usetiful](https://markets.businessinsider.com/news/stocks/fullstory-acquires-usetiful-turning-digital-insights-into-decisive-actions-1035476979) - [LogRocket Pricing](https://logrocket.com/pricing) - [LogRocket Galileo AI product page](https://logrocket.com/products/galileo-ai) - [LogRocket Issues 2026](https://docs.logrocket.com/docs/issues-2026) - [LogRocket Privacy](https://docs.logrocket.com/docs/privacy) - [LogRocket FAQ](https://docs.logrocket.com/docs/q-a) - [LogRocket Mobile Feature Support](https://docs.logrocket.com/docs/mobile-feature-support) - [LogRocket Extended Session Retention](https://docs.logrocket.com/docs/extended-session-retention) - [Glassbox to Be Acquired by Alicorn Venture Partners](https://www.glassbox.com/news/glassbox-to-be-acquired-by-alicorn-venture-partners/) - [Glassbox Strengthens Anomaly Detection with Acquisition of Anodot](https://www.glassbox.com/news/glassbox-anodot-acquisition/) - [Glassbox Platform](https://www.glassbox.com/platform/) - [Glassbox Tagless Data Capture](https://www.glassbox.com/platform/tagless-data-capture/) - [Glassbox Digital Record Keeping](https://www.glassbox.com/platform/digital-record-keeping/) - [Glassbox Data Privacy & Security](https://www.glassbox.com/platform/data-privacy-security/) - [Meet GIA — Glassbox Insights Assistant](https://www.glassbox.com/platform/glassbox-insights-assistant/) - [Quantum Metric Raises $200 Million](https://www.insightpartners.com/ideas/quantum-metric-raises-200-million-with-valuation-above-1-billion-to-help-enterprises-build-better-digital-products-faster/) - [Quantum Metric Platform](https://www.quantummetric.com/platform/) - [Quantum Metric Pricing](https://www.quantummetric.com/pricing/) - [Quantum Metric Mobile App Analytics](https://www.quantummetric.com/platform/mobile-app-analytics/) - [Quantum Metric Session Replay](https://www.quantummetric.com/platform/session-replay/) - [Quantum Metric Felix Agentic GA](https://www.quantummetric.com/press-releases/quantum-metric-launches-next-evolution-of-enterprise-agentic-analytics) - [Heap — Pricing](https://www.heap.io/pricing) - [Pendo — Pricing](https://www.pendo.io/pricing/) - [GA4 Data retention](https://support.google.com/analytics/answer/7667196?hl=en) - [GA4 About data sampling](https://support.google.com/analytics/answer/13331292?hl=en) - [GA4 About data thresholds](https://support.google.com/analytics/answer/9383630?hl=en) - [GA4 360 feature limits](https://support.google.com/analytics/answer/11202874?hl=en) - [GA4 BigQuery Export](https://support.google.com/analytics/answer/9358801?hl=en) - [Firebase BigQuery export](https://firebase.google.com/docs/projects/bigquery-export) - [What's new in Google Analytics](https://support.google.com/analytics/answer/9164320?hl=en) - [Google Consent Mode](https://developers.google.com/tag-platform/security/guides/consent) - [The GA4 360 Pricing Model — Cardinal Path](https://www.cardinalpath.com/blog/ua-360-vs-ga4-360-pricing-model) - [Adobe Analytics Product Description](https://helpx.adobe.com/legal/product-descriptions/adobe-analytics.html) - [Customer Journey Analytics Product Description](https://helpx.adobe.com/legal/product-descriptions/customer-journey-analytics.html) - [Migrating from Adobe Analytics to CJA](https://experienceleague.adobe.com/en/perspectives/migrating-from-adobe-analytics-to-customer-journey-analytics) - [Adobe AEP AI Assistant GA](https://news.adobe.com/news/news-details/2024/media-alert-adobe-announces-general-availability-of-adobe-experience-platform-ai-assistant-to-supercharge-enterprise-productivity) - [Twilio Concludes Operational Review of Segment](https://www.twilio.com/en-us/press/releases/twilio-concludes-operational-review-of-segment) - [Twilio Segment Pricing](https://segment.com/pricing/) - [Segment Data Warehouses](https://www.twilio.com/docs/segment/connections/storage/warehouses) - [Segment Identity Resolution](https://www.twilio.com/docs/segment/unify/identity-resolution) - [Segment Regional](https://www.twilio.com/docs/segment/guides/regional-segment) - [Twilio Q2 2026 Earnings Call Transcript](https://www.fool.com/earnings/call-transcripts/2026/08/13/twilio-twlo-q2-2026-earnings-call-transcript/) - [PostHog — How much does Google Analytics cost?](https://posthog.com/blog/google-analytics-cost) --- # 04 · 中国平台：从“支持私有化”到“进入业务系统” > 中国 UBA 的竞争不在图表：私有化已是默认交付，计价锚点分裂成三套，真正的差异是谁能把事件定义送进业务系统，且让客户走得掉。 中国 UBA 市场在 2026 年已经没有“纯粹”的玩家。神策主推 Sensors AI，GrowingIO 收进 StartDT 的分析云，数数科技改名 ThinkingAI，DataFinder、Quick Tracking、友盟、百度统计则分别是字节、阿里、百度的云或流量配套。**埋点分析不再是终点，而是这些公司进入另一门生意的入口。** 这不是产品失败，是计价方式失败。2015–2019 年卖工具，2020–2022 年卖 CDP，2023–2024 年卖私有化与信创，2025–2026 年改卖 Agent。每次转向，都是上一代收费方式先卖不动 [来源](https://www.geekpark.net/news/366666)。 最后一笔行业级融资是神策 2022 年 5 月的 2 亿美元 D 轮，据公开融资与并购记录，此后四年未发现同量级事件（检索截至 2026-10-18；未覆盖未披露交易） [来源](https://m.cls.cn/detail/1006661)。资本退出比产品迭代更能解释 2026 年的格局。 ## 4.1 中国市场结构 **两类卖家，一个价格地板。** 第一类是云与流量平台的配套产品。DataFinder 的利润在云资源与 ByteHouse，Quick Tracking 在云账单，友盟和百度统计在推送、性能、广告与开发者服务。UBA 对它们是入口，不是利润中心；云厂商的 UBA 可以更便宜，因为成本能从别处收回来。 第二类是专业厂商。神策、GrowingIO、数数、诸葛、TalkingData、易观方舟，收入主要来自项目、私有化交付与行业方案。它们要养实施队伍，报价必须覆盖人力，所以客单价高、利润率低、规模化难。 第三层不是卖家，是价格地板。友盟免费版不限时长、不限数据量，百度统计完全免费 [来源](https://www.umeng.com/) [来源](https://tongji.baidu.com/web5/welcome/index)。只要这两家还在，中小客户的基础统计就不会形成可收费市场。 **所有权：产品还在，主体可能已经换了。** | 品牌 | 运营主体 | 2026 年所有权状态 | 产品状态 | |---|---|---|---| | 神策数据 | 神策网络科技（北京）有限公司 | 独立，未上市 | 分析、画像、CDP、智能运营；主推 Sensors AI | | GrowingIO | 北京易数科技有限公司 | StartDT 奇点云集团旗下（2022 年并购重组） | 增长分析、CDP、MA 按版本迭代 | | 诸葛智能（诸葛 IO） | 境内主体待核实 | 容联云全资子公司（2020 年宣布、2021 年完成） | 文档仍在，官网版权停在 2015–2023 | | 易观方舟 | 深圳易观数字科技有限公司 | 与易观分析分属不同主体 | 站点可访问，版权停在 2002–2022 | | 数数科技 / ThinkingAI | 数数信息科技（上海）有限公司 | 独立；2026-04-14 更名 | 原 ThinkingAnalytics 收进 Agentic Engine | | TalkingData | 北京腾云天下 | 独立 | 主叙事转为 AI 数据服务 | | 火山引擎 DataFinder | 北京火山引擎科技有限公司 | 字节跳动旗下云产品 | 四种交付形态，按资源包售卖 | | 阿里云 Quick Tracking | 阿里云 | 阿里云产品 | 极速、标准、专家三档 | | 友盟+ U-App | 阿里系，境内主体待核实 | 阿里系 | 免费统计加推送、性能、AI 服务 | | 百度统计 | 百度 | 百度旗下免费工具 | 免费，绑定广告生态 | 这张表最值得看的是最后两列。诸葛的文档仍在更新，母公司却经历了停牌、退市与 OTC 私有化；易观方舟的站点仍能打开，版权却停在 2022 年。产品存续与主体存续，在中国已不是一回事。 **计价：同一个“事件”，三种商品。** 云厂商按量卖年包，独立厂商按项目卖版本，免费工具用数据换服务。Quick Tracking 国际站采集流量 3.5 美元/GB，标准版 880–13,500 美元/月；DataFinder 只公开规则，按万 MTU 或百万事件量计，单价必须询价；神策在阿里云云市场的标价 54 万、63 万、72 万元/年，近 180 天成交 0 笔 [来源](https://www.alibabacloud.com/help/zh/quick-tracking/latest/collection-and-analysis-version-and-specifications) [来源](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/VolcanoEngineGrowthAnalysis-ProductServiceBillingSettlementRules?lang=zh) [来源](https://market.aliyun.com/detail/cmgj00047786.html)。标价是锚，不是成交价；真实价格随项目边界浮动。 同一家企业，按上报条数、有效事件、去重用户、存储量算，年费可以差出一个数量级。采购如果不在合同里定义“事件”，后面所有比价都没有意义。 **合规：数据在哪里，是一票否决项。** 《个人信息保护法》2021 年 8 月 20 日通过、11 月 1 日施行，把告知—同意、最小必要、单独同意、影响评估写成法定义务 [来源](https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm)。设备 ID、位置、页面行为都可能构成个人信息；SDK 初始化即采集，很难证明“最小必要”；向境外提供数据需要单独同意。 2024 年 3 月 22 日的《促进和规范数据跨境流动规定》把门槛量化：非关键信息基础设施运营者，当年累计向境外提供不满 10 万人个人信息（不含敏感）可免于申报评估、标准合同或认证；10 万–100 万人需标准合同或认证；100 万人以上、或 1 万人以上敏感个人信息需申报安全评估；评估结果有效期 3 年 [来源](https://www.cac.gov.cn/2024-03/22/c_1712776611775634.htm)。 所以私有化在中国是默认选项：用境外 SaaS 的企业，用户量过 10 万就要处理标准合同或安全评估；用境内 SaaS 的企业，仍要回答数据存在哪个 region、谁能访问、是否二次使用；金融、政务、国企还要叠加等保三级与信创适配。 厂商的资质页因此变成投标材料：神策列了 ISO 9001、等保、CMMI 3、鲲鹏/统信/麒麟兼容；数数写明等保三级、ISO 27001、SOC 2 Type II；诸葛写麒麟 V10、海光 CPU、OceanBase 兼容 [来源](https://www.sensorsdata.cn/) [来源](https://www.thinkingai.cn/product/self-hosted/) [来源](https://zhugeio.com/)。这些不是加分项，是门槛。 但私有化只是把软件搬进客户的机房。2026 年真正的竞争，是事件能不能被客户的 CDP、运营、实验和 Agent 直接消费；这决定了平台是“一个报表工具”，还是“业务系统的一部分”。 > **判断**：中国 UBA 已经不是一个独立品类，而是四种生意的入口——云资源、广告、运营软件、Agent。判断一家厂商，先看它的 UBA 在为哪门生意导流；这比看它有多少张图表有用得多。 ## 4.2 神策数据 神策 2015 年成立，2022 年 5 月完成 2 亿美元 D 轮，由 Tiger Global、凯雷投资集团领投，明势资本、DCM、线性资本、红杉中国跟投 [来源](https://m.cls.cn/detail/1006661)。官网称已服务 2000+ 客户、30 多个行业、50+ 全球财富 500 强、70+ 中国财富 500 强、100+ 已上市企业 [来源](https://www.sensorsdata.cn/)。均为厂商口径。 产品线已难一句话概括：神策分析做事件、漏斗、留存、路径、归因；用户画像做标签与分群；CDP 做多源接入与人群下发；智能运营做触达。2026 年 6 月 26 日发布的 Sensors AI 1.0 又加一层：一个主 Agent、五个场景化 Agent（客群圈选、单用户洞察、运营策略、智能报告、深度分析）、六类技能（指标分析、智能运营、分群标签、AutoML、语义标签、虚拟人评价）[来源](https://www.sensorsdata.cn/engines/SensorsAI.html)。三年战略叫“L4 级 AI Growth Team”，交付物从软件转向“工作量”，再转向“结果” [来源](https://www.geekpark.net/news/366666)。从卖软件到卖结果，改变的是收入确认与风险承担；但“结果”如何计量、未达标如何处理，公开资料没有说明。 **它真正卖的是什么。** 不是图表。事件分析、漏斗、留存、路径，国内十家都能做。差异在三件事：元数据与埋点方案被当成实施方法的一部分；ID-Mapping 把 device_id、登录 ID、匿名 ID 归一到统一用户；行业模板与 SDAF 方法论。交付能力才是 54 万–72 万报价里最贵的部分。 **价格是锚，不是价目。** 阿里云云市场的神策分析加用户画像，低配 54 万元、中配 63 万元、高配 72 万元，有效期 1 年，商品上架日期 2021-08-06，近 180 天成交 0 笔 [来源](https://market.aliyun.com/detail/cmgj00047786.html)。它证明有标价，不证明是成交价；直销项目制报价不公开，范围随事件量、端数、驻场与升级年限变化。 **限制也很清楚。** 贵，且越来越难说清“神策是什么”；从 UBA 到 CDP 到 Agent，边界持续外扩，容易被全家桶绑定。Agent 的交付效果只有厂商演示，L4 是厂商自定等级。私有化交付意味着升级、故障处理都依赖厂商队伍。 > **判断**：神策卖的不是分析工具，是“一套口径 + 一支能陪跑的队伍”。54–72 万元的云市场标价只是锚；真正的价格随交付边界浮动，真正的风险是这套口径的载体是厂商的实施方法，而不是一份你能带走的元数据。 ## 4.3 GrowingIO GrowingIO 2015 年由张溪梦创立，2022 年与奇点云完成并购重组，成立 StartDT 集团，GrowingIO 成为集团旗下的分析品牌 [来源](https://www.growingio.com/about)。官网称服务超过 1500 家企业级客户、100+ 头部泛零售客户 [来源](https://www.growingio.com/)。融资记录停在 2018 年 B 轮 3000 万美元 [来源](https://www.growingio.com/about)。 产品是“分析云”的六件套：增长分析、CDP、智能运营、获客分析（对接 40+ 投放渠道）、A/B 实验、渠道质量分析。采集支持多端、门店与私域，OneID 做实时身份整合。2026 年 7 月 17 日的 V4.13 增加了 AI 关键客户画像、流失预测、人群概率分布直方图、活动看板与 Kafka 订阅 AES 加密 [来源](https://www.growingio.com/news/ss534emcximil3ccipznt)。 产品还在迭代，但结构问题也出来了：AI 增量被放在集团另一条品牌线上。2026 年 9 月，集团以“奇点智能 DeciAGI”发布智能问数内容，GrowingIO 继续承担 UBA、CDP、MA [来源](https://www.growingio.com/news/ss534emcximil3ccipznt)。采购方要确认：合同主体是 GrowingIO 还是 StartDT；未来三年的 AI 路线图属于哪个品牌。 强项是零售与品牌的行业密度：会员、门店、导购、私域、渠道归因，模板和实施方法成熟。弱项是互联网客户声量弱于神策；品牌归属多次变化，合同主体与路线依赖集团；AI 能力分散在两个品牌。它的护城河是客户密度，不是功能；客户密度带来模板与口碑，也带来路径依赖。 价格不公开。官网只说“顾问结合产品模块、部署方式与业务需求提供报价” [来源](https://www.growingio.com/about)。同样叫“增长分析”，端数、事件量、CDP 模块、实施人天可以完全不同。 ## 4.4 火山引擎 DataFinder DataFinder 是字节跳动旗下火山引擎的增长分析产品，运营主体是北京火山引擎科技有限公司 [来源](https://www.volcengine.com/product/datafinder)。它提供四种交付形态：SaaS 云原生、SaaS 非云原生、云托管、私有化。云托管把存算放在客户自有 ByteHouse，官方称“相比私有化便宜 20% 左右”，但只面向部分企业开放 [来源](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/IntroductiontoCloudHostingModel?lang=zh)。 计费规则写得很细：资源包预付费、包年，单位是万 MTU 或百万事件量；超额后按量后付费、按月出账；增长分析不支持退订，已付费用不退款 [来源](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/VolcanoEngineGrowthAnalysis-ProductServiceBillingSettlementRules?lang=zh)。数据保留分环境：SaaS 云原生默认最长 2 年，云托管默认不设过期时间；停服 90 天后删除数据 [来源](https://docs.volcengine.com/docs/84129/1261816?lang=zh)。 这套规则不是财务条款，是产品设计。按量计费会让客户清理无用埋点；不退订会让采购签约前算准事件量；90 天删除会让迁移成本变高。字节内部“埋点成本要货币化”的方法，被翻译成了客户必须遵守的约束。 数据模型也体现同一套思路。device_id、web_id、anonymous_id 与 user_unique_id、ssid 做 Mapping；全埋点事件固定为 bav2b_click、bav2b_page；单应用事件上限默认 1000；事件和属性要先注册再上报 [来源](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/Newcustomersneedtoknow?lang=zh)。这套设计是逼客户在采集前想清楚事件叫什么、属于谁。 分析侧覆盖事件、漏斗、留存、路径、归因、Session 等常用模型，并把“多主体”（消费者、汽车、商家）做成可开通能力，适合汽车与线下融合场景；广告监测是独立增值模块 [来源](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/Newcustomersneedtoknow?lang=zh)。 **内部平台与对外产品不是一回事。** 字节内部叫“流量平台”，治理操作台叫 ByteIO；2023 年公开峰值是 1 亿+/秒、日增 10 万亿；治理收益包括 2021 年下线无用埋点省近亿元、分级省 100+PB 存储、2022 年采样省 3000+ 万元、监督式治理再省 4000 万元 [来源](https://www.techweb.com.cn/cloud/2021-09-06/2856406.shtml) [来源](https://server.it168.com/a2023/0110/6785/000006785467.shtml)。均为自报，口径含重复上报与多端，不能换算成唯一事件数。 但公开材料停在 2023 年。DataFinder 与内部流量平台是否同源，官方没有说明 [来源](https://www.volcengine.com/product/dataleap)。客户买到标准化后的功能、计费和权限，买不到字节的组织配套：数据产品经理、埋点评审、成本核算、跨团队治理。 限制也来自这套设计：与火山引擎账号、ByteHouse 强绑定；两套云环境造成文档分叉；不退订、90 天删数据，迁移成本高；广告监测必须搭配增长分析包。 > **判断**：DataFinder 卖的不是自由，是纪律。按量、包年、不退订、90 天删除，这些条款把字节的成本治理变成了客户的采购约束；它适合本来就想把埋点管起来的团队，不适合想先“随便采”的团队。 ## 4.5 阿里云 Quick Tracking 与友盟+ **Quick Tracking：把“先设计、后采集”做成了产品顺序。** Quick Tracking 的全称是“全域采集与增长分析”，阿里云产品 [来源](https://www.alibabacloud.com/help/zh/quick-tracking/latest/collection-and-analysis-version-and-specifications)。它分极速版、标准版、专家版：极速版几乎只有采集与管理，标准版含核心分析模型，专家版才补标签画像、人群圈选与高级 ID-Mapping。分析模型共 14 类，覆盖事件、漏斗、留存、路径、归因、Session、人群、渠道、热力等。 公开价是中国厂商里颗粒度最细的：采集流量 3.5 美元/GB；极速版 150 美元/月；标准版 880 美元/月（5000 万事件量/月）到 13,500 美元/月（16 亿事件量/月）；专家版 1,600 到 14,000 美元/月；组织配额 400 美元，视图配额 40 美元 [来源](https://www.alibabacloud.com/help/zh/quick-tracking/latest/collection-and-analysis-version-and-specifications)。这是国际站刊例价；中国站价格页更新于 2025-08-01，正文未抓取，人民币价格待核实 [来源](https://www.alibabacloud.com/help/zh/quick-tracking/latest/pricing-and-billing-description-collection-analysis)。 把两个数字放在一起，“软件订阅”里有一部分其实是流量账单：官方按 1 亿日志量约 200GB 估算，3.5 美元/GB 就是约 700 美元/月，接近标准版 5000 万事件量/月的 880 美元。日志里无用字段越多，客户越是在为噪声付两次钱。 版本断层也大：极速版没有完整分析能力，实际可用的是标准版起步；标签画像只在专家版提供。“880 美元/月”买到的是一套事件与漏斗工具，不是完整的用户经营平台。 数据生命周期是硬约束：SLS 可订阅 topic 21 天，ClickHouse 可查询 800 天；到期后 15 天内未续费，系统释放资源，历史数据全部清除且无法找回 [来源](https://www.alibabacloud.com/help/zh/quick-tracking/latest/collection-and-analysis-version-and-specifications)。21 天与 800 天不是保留策略，是查询窗口；超过窗口的数据，除非客户自己导出，否则不在产品里。 私有化未见公开说明，待核实。公开文档只写“整体支持阿里云公有云多租户 SaaS 部署”；金融、政务、国企很可能因此排除它。 Quick Tracking 的方法论与阿里内部一脉相承：UT 解决怎么声明和上报，SPM 解决位点怎么编号，黄金令箭解决日志按什么规范采集，OneData 解决指标怎么定义；Quick Tracking 要求先做指标体系与埋点方案，再录事件与属性，最后才接 SDK [来源](https://lemon-doc.faas.ele.me/guide/ut.html) [来源](https://www.alibabacloud.com/help/zh/quick-tracking/latest/access-process)。它卖的其实是这个顺序：先想清楚，再采集。内部 UT 体系是否同源，官方没有说明，待核实 [来源](https://developer.aliyun.com/article/1674625)。 **友盟+：免费统计是入口，不是产品。** 友盟+ 是阿里系，境内运营主体待核实 [来源](https://www.umeng.com/)。产品矩阵包括移动、网站、小程序统计，以及推送、性能、超链、合规、模型路由 U-Router、AI Hub。U-App 页面称有 303 万开发者在使用 [来源](https://www.umeng.com/analytics)。 免费策略很彻底：10+ 款核心产品免费版不限时长、不限数据量；专业版提供更高并发、专属客服与定制；新客首月 19.9 元 [来源](https://www.umeng.com/)。定价页按标准、专业、尊享列功能与推送配额，但不列单价 [来源](https://www.umeng.com/market)。软件价格是 0，收入来自推送量、并发、服务，以及 2026 年新增的 U-Router 与 AI Hub。 这套模式对中小团队总拥有成本最低，但代价是数据主权：SaaS only，私有化未见公开方案；深度画像、跨端 ID 弱于专业 UBA；一旦要做用户级归因，迁移成本远高于省下的 license。 Quick Tracking 与友盟是两种商业模式：前者把 UBA 做成阿里云账单里的一个 SKU，后者用免费统计换开发者的推送、性能与模型调用。把它们放在同一张功能表里比较，从第一行就错了。 ## 4.6 百度统计、诸葛 IO、易观方舟、数数科技、TalkingData **百度统计：免费工具的天花板。** 百度统计包含网站、移动统计、CDP 与 A/B，支持全埋点、可视化圈选、API 采集，网站、App、小程序统一管理 [来源](https://tongji.baidu.com/web5/welcome/index)。它完全免费，SaaS only，无私有化。真正的买单人是百度广告体系里的广告主：统计是投放链路的一部分，不是独立收入。官网称“数十万企业的安心之选”，并称可实时洞察“千亿级用户行为数据”——这是营销口径，不是第三方审计数据。 它适合中小站点和百度投放团队，不适合作为唯一 UBA：复杂路径、多主体、标签画像弱；没有 SLA；数据不可私有化。当起步工具可以，当公司级底座会碰到天花板。 **诸葛 IO：产品还在，母公司已经换过一轮生死。** 诸葛智能是容联云全资子公司。2020 年 12 月 13 日容联云宣布全资收购，2021 年完成整合 [来源](https://finance.china.com/TMT/13004688/20250829/48772776.html) [来源](https://finance.china.com/TMT/13004688/20250829/48772776.html)。官网自述累计合作 1000+ 家企业，金融行业为主 [来源](https://zhugeio.com/)。产品包括诸葛 IO、CDP、CEP、BI、AI 自助分析；支持代码、可视化、全埋点；信创适配麒麟 V10、海光、OceanBase；交付有 SaaS、私有化 PaaS、SMART 数据中台 [来源](https://zhugeio.com/)。 它是金融行业里少数把标签体系、运营场景与信创适配都做全的厂商，价格通常低于神策。风险在主体层：母公司 2021 年 2 月在纽交所上市，828 天后被暂停交易并启动退市，市值从超 76 亿美元跌到约 6000 万美元，公开报道援引调查称其 2021 年 Q2、Q3 存在收入虚增；2026 年 5 月 12 日签署私有化合并协议，将从 OTC 摘牌并完成 SEC 注销 [来源](https://finance.china.com/TMT/13004688/20250829/48772776.html) [来源](https://www.kingandwood.com/cn/zh/about-us/media-center/king-and-wood-advises-on-taking-private-of-u-s-otc-quoted-cloopen.html)。官网版权停在 2015–2023。 **易观方舟：没有停服公告的收缩。** 易观体系分两块：易观分析做研究、千帆、博阅；易观方舟由深圳易观数字科技有限公司运营 [来源](https://www.analysysdata.com/)。方舟是“智能用户运营”套件：12 大分析模型、智能画像、12 种触达通道、可视化埋点、私有化；价格页只有标准版、高级版的功能对比，没有金额 [来源](https://www.analysysdata.com/eapricing.html)。 2026 年的状态是实质收缩：易观分析主站的产品矩阵已不再列方舟，只剩千帆、博阅、咨询与解决方案；方舟独立域名 ark.analysys.cn 在 2026-10-18 实测无法解析（curl 返回 000）；易观数科站仍可访问，但页脚版权为 2002–2022；没有找到任何 2024–2026 年的版本发布或停服公告，公开资料不足，只能标注“待核实” [来源](https://www.analysys.cn/) [来源](https://www.analysysdata.com/)。对存量客户，问题不是升级，是“续费给谁”。 **数数科技 / ThinkingAI：更名是战略转向，不是换 logo。** 数数 2015 年成立，2026 年 4 月 14 日正式更名 ThinkingAI；官方称服务全球 1500+ 企业、20 个国家 [来源](https://www.thinkingai.cn/blog/b8e1a4f6/)。产品从 ThinkingAnalytics 的事件、漏斗、留存、LTV、归因，转到 Agentic Engine、100+ 行业 Skills、MCP 与私有化部署 [来源](https://www.thinkingai.cn/)。 官方称 80% 客户选择私有化，支持等保三级、ISO 27001、SOC 2 Type II、GDPR、PIPL [来源](https://www.thinkingai.cn/product/self-hosted/)。游戏与出海是基本盘，实时上报、多端采集、买量 ROI 与 LTV 是强项。更名后纯分析采购的比价难度上升：官网导航已没有 ThinkingEngine、ThinkingAnalytics，全部改为 Agent 与 Skills；客户要问清楚买的是分析能力还是 Agent 使用权。品牌更名还会带来搜索、合同、招投标资质的一致性成本。 **TalkingData：从分析工具转成数据原料商。** TalkingData 主体是北京腾云天下，独立；2026 年官网定位改为“Leading AI Data Service Platform” [来源](https://www.talkingdata.com/)。产品仍有应用统计、广告监测、DMP，但新增重点是数据集、标注、联合建模、SmartDP、可信数据空间 [来源](https://debug.talkingdata.com/analytics-marketing.jsp?languagetype=zh_cn)。买单人从产品经理变成数据、算法负责人。 它的官网数字存在明显冲突：SmartDP 页写“450K+ App integrations”，应用统计页写“10 万+ 接入应用”，相差 4.5 倍；日均事件都是 500 亿+。另有 800+ 数据标签；首页数据集规模 2.4B（未注明单位）、标注准确率 99.8%、模型调用 124M、图文对齐 95%+ [来源](https://www.talkingdata.com/)。引用必须注明页面与口径，否则尽调会被带偏。 TalkingData 的优势是数据资产、设备图谱、广告归因；限制是 UBA 已不是战略中心，迭代与支持优先级存疑，数据业务受个人信息保护与广告标识政策影响大。买它，买的是数据原料，不是分析工作台。 > **判断**：诸葛与易观方舟说明同一件事——产品可以还在，主体可以先死。采购尽调的第一页应该是股权、存续与支持主体，不是功能清单；一份没有“控制权变更、产品终止”条款的合同，等于把停服风险全部留给自己。 ## 4.7 横向对比 **能力：十家都能做漏斗，差异在空白处。** 事件、漏斗、留存、路径、归因是十家的共同能力，逐家打“强”不提供决策信息；下表只列会改变决策的差异项。 | 差异项 | 神策 | GrowingIO | DataFinder | Quick Tracking | 数数/ThinkingAI | 诸葛 | |---|---|---|---|---|---|---| | 画像、CDP | 强 | 强 | 中 | 专家版 | 中 | 强 | | 实验、A/B | 待核实 | 有 | DataTester 另购 | 待核实 | 有 | 有（CDP 内） | | 私有化 | 有（信创） | 有 | 有加云托管 | 待核实 | 有（80% 客户） | 有 | | 公开定价 | 云市场 54–72 万/年 | 无 | 规则公开、单价不公开 | 国际站公开 | 无 | 无 | | 2026 风险 | 叙事分散、绑定 | 品牌归属 | 云绑定、删除条款 | 数据生命周期、私有化缺位 | 更名、行业周期 | 母公司治理 | 这张表最值得注意的不是“谁全都有”，而是空白：A/B 在多数中国 UBA 里不是标配；私有化在云厂商产品里普遍缺公开方案；公开定价几乎不存在。中国 UBA 的采购因此更像项目采购，而不是软件订阅。 采集层已经同质化。十家都支持全埋点、代码埋点、服务端上报、小程序，差异不在“能不能采”，而在“采完之后能不能治理”。DataFinder 要求先注册事件和属性；Quick Tracking 把埋点方案、页面区块、规范做成独立模块；神策和 GrowingIO 把元数据与 ID-Mapping 当成实施方法。采集是入场券，治理才是产品。美团 2017 年就说过，无痕埋点只能解决约 70% 的需求 [来源](https://tech.meituan.com/2017/03/02/mt-mobile-analytics-practice.html)。 分析层的差距在口径，不在模型。十家都能做事件、漏斗、留存、路径、归因；差距是同一个“活跃用户”有十种定义，同一张漏斗换端、换登录态、换时区后能否复算，指标能不能由业务方自己定义。神策、数数、GrowingIO 投入最多；云厂商产品更依赖客户的数据团队。 **价格：公开价与询价，是两张不同的表。** | 产品 | 计价单位 | 公开价格（2026-10 页面） | 性质 | |---|---|---|---| | Quick Tracking | 事件量、采集流量、版本 | 3.5 美元/GB；150（极速）–14,000（专家）美元/月 | 阿里云国际站刊例价 | | 神策 | 版本 × 年 | 54 万、63 万、72 万元/年 | 云市场标价，近 180 天 0 成交 | | 百度统计 | 不适用 | 0 元 | 免费，绑定广告生态 | | 友盟+ | 版本加推送、并发配额 | 免费版 0 元；新客首月 19.9 元；专业版单价未公开 | 版本公开，单价不公开 | | 网易有数 BI（参照） | 创作者 × 年 | 988、3,888 元/年；阅览者 988 元/年 | BI 产品，仅作价格锚点 | | 产品 | 计价单位 | 公开信息 | 采购含义 | |---|---|---|---| | DataFinder | 万 MTU 或百万事件量，资源包包年 | 规则细，单价不公开；不支持退订 | 按自身事件量测算，谈超额与封顶 | | GrowingIO | 模块加部署方式 | 顾问报价 | 报价随模块边界浮动，要求拆明细 | | 诸葛 | 项目加部署方式 | 不公开 | 金融项目制，价格通常低于神策 | | 易观方舟 | 版本（标准、高级） | 只有功能对比，无金额 | 存量续费需确认支持主体 | | 数数 / ThinkingAI | 项目加部署方式 | 不公开 | 私有化比例高，交付人力占比大 | | TalkingData | 项目 | 不公开，免费试用 | 数据服务与 UBA 混售，需拆分 | 两张表放在一起，价格结构就出来了：云厂商按事件量、流量、版本拆开卖，可以预算，但版本间断层大；独立厂商把 UBA 包进项目，无法横向比价；免费工具把价格压到 0，用数据与入口变现。只拿到总价，几乎无法判断买贵了没有。 比价方法：先算自家的事件量、MTU、存储量、端数、保留期，再让每家按同一组参数报价；要求拆分软件授权、采集流量、实施人天、私有化节点、年度支持五项。五项拆不开的报价，默认不可比。网易有数的公开价说明中国厂商不是不会公开定价，而是 UBA 厂商不愿公开：BI 按创作者卖，边界清楚；UBA 按项目卖，边界本身就是利润 [来源](https://youdata.netease.com/index/deploy)。 **行业：客户密度决定产品形状。** | 行业 | 主要玩家 | 真实需求 | 产品形状 | |---|---|---|---| | 互联网、内容 | 神策、DataFinder、GrowingIO | 事件量大、迭代快、实验多 | SaaS 或云托管，按事件量计价 | | 零售、品牌 | GrowingIO、神策、诸葛 | 线上线下融合、会员、私域、导购 | CDP 加 MA 加咨询，私有化或混合 | | 金融 | 神策、诸葛、数数 | 合规、信创、审计、私有化 | 私有化加等保三级、国产化适配 | | 游戏 | 数数、神策、DataFinder | 买量 ROI、LTV、实时、出海 | 私有化或云托管，按事件量，强归因 | | 汽车 | DataFinder、神策、GrowingIO | 车主 ID、多主体、线下门店 | 多主体分析加 CDP，项目制 | | SaaS、企业服务 | GrowingIO、神策、诸葛 | 线索、激活、留存、扩容、多租户 | 产品分析加 CDP，SaaS 或混合 | | 中小 App、站点 | 友盟、百度统计 | 免费、快、渠道归因 | 免费 SaaS 加广告、推送增值 | 这张表解释了一个反常识：功能差异主要不是技术差异，而是行业客户密度差异。GrowingIO 的零售方案细，因为客户集中在零售；数数的游戏方案细，因为客户集中在游戏；DataFinder 的多主体做得早，因为字节的汽车与商业化客户需要它。厂商进入新行业时，产品页什么都“支持”，模板、口径、实施方法却是空的。 最容易踩的坑：用互联网 demo 评估零售项目。互联网客户的事件量可能百万级/天，零售客户只有十万级/天，但后者的身份合并、门店归属、导购分佣、会员等级规则复杂得多。前者考查询性能，后者考数据建模。让厂商用你的行业数据跑一遍，比看一百页功能清单有用。 **大厂内部平台与对外产品，差的是组织配套。** 字节 2023 年公开的峰值是 1 亿+/秒、日增 10 万亿事件；阿里内部的 UT、SPM、黄金令箭、OneData 把声明、编号、采集、指标定义拆成四件事 [来源](https://www.techweb.com.cn/cloud/2021-09-06/2856406.shtml) [来源](https://lemon-doc.faas.ele.me/guide/ut.html)。这些能力被裁剪成 DataFinder、Quick Tracking 时，客户买到的是标准功能、计费和权限，买不到数据产品经理、埋点评审、成本核算和跨团队治理。两者是否同源，公开材料没有说明，待核实。 > **判断**：中国 UBA 的功能差异，主要是行业客户密度差异；空白比勾更重要——不支持的 A/B、缺公开方案的私有化、不公开的价格，才是采购要谈的地方。 ## 4.8 选型与风险 **部署与合规：先排除，再评分。** | 产品 | 交付形态 | 数据位置与保留 | 合规、信创 | 私有化证据 | |---|---|---|---|---| | 神策 | SaaS 加私有化 | 数据中心区域未公开 | ISO 9001、等保、CMMI 3、鲲鹏/统信/麒麟 | 有 | | GrowingIO | SaaS、私有化、混合 | 数据区域未公开 | 公开资料未见完整清单 | 有 | | DataFinder | SaaS 云原生/非云原生、云托管、私有化 | 云原生默认最长 2 年；云托管不过期；停服 90 天删除 | 公开资料未见完整清单 | 有 | | Quick Tracking | 阿里云公有云多租户 SaaS | SLS 21 天、ClickHouse 800 天；到期 15 天清空 | 阿里云合规体系 | 待核实 | | 友盟+ | SaaS only | 数据在阿里云、友盟侧 | 未见私有化方案 | 无公开方案 | | 百度统计 | SaaS only | 数据在百度 | 未见私有化方案 | 无 | | 数数 / ThinkingAI | 私有化为主（80%） | 客户环境 | 等保三级、ISO 27001、SOC 2 Type II、GDPR、PIPL | 有 | | 诸葛 | SaaS、私有化 PaaS、SMART 数据中台 | 数据区域未公开 | 麒麟 V10、海光、OceanBase | 有 | 这张表先用排除法：金融、政务、国企先看私有化与等保；跨境业务先看数据区域与出境路径；中小团队先看免费版够不够。一项不过，功能评分就没有意义。私有化只解决“数据在哪里”，不解决“谁能看、谁能改、谁能导出”；没有权限治理的私有化，只是把风险从厂商机房搬到自己的机房。 **合同：五个条款比五页功能清单重要。** 1. **计价单位定义。** 写清“事件”是上报条数、有效事件、去重用户还是存储量；写清禁用、待验收、SDK 自动采集事件是否计费。DataFinder 明确“禁用事件不计入用量”，这类细节必须进合同 [来源](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/Newcustomersneedtoknow?lang=zh)。 2. **超额单价与封顶。** Quick Tracking 与 DataFinder 都把超额做成后付费；必须约定超额单价、告警阈值与月度封顶，否则一次埋点事故就是一张账单。 3. **导出与迁移。** 约定格式、频率、是否收费、停服后保留天数。Quick Tracking 到期 15 天即清空历史数据，DataFinder 停服 90 天删除数据，这两条都应作为谈判点 [来源](https://www.alibabacloud.com/help/zh/quick-tracking/latest/collection-and-analysis-version-and-specifications) [来源](https://docs.volcengine.com/docs/84129/1261816?lang=zh)。 4. **停服与所有权变更。** 易观方舟的案例说明，产品停更可以没有任何公告。合同里要有“控制权变更、产品终止需提前 N 个月通知并免费导出”的条款。 5. **审计权。** 要求厂商提供用量审计日志，允许第三方核对事件量与计费口径。中国厂商普遍不提供，这是差异化谈判点。 权重建议：口径与治理 30%、分析体验 20%、部署与合规 20%、TCO 20%、生态与存续 10%。不要给“AI 功能”单独权重，把它放进“分析体验”，要求厂商用客户数据演示。POC 至少跑三件事：同一份事件表复算 10 个核心指标；断网、重复上报、跨端合并、权限越权演练；历史数据导出、双跑、回滚。 **三个反例。** - **“免费所以先用着”。** 友盟和百度统计的免费版能解决基础统计，但要做用户级归因、跨端 ID、私有化时，迁移成本远高于省下的 license。 - **“私有化就是安全”。** 私有化只解决数据在哪里，不解决谁能看、谁能改、谁能导出。 - **“Agent 能替代分析师”。** 神策自己把 Agent 定义为“L4 级”，需要人设定目标与边界 [来源](https://www.geekpark.net/news/366666)。事件语义没有统一之前，Agent 产出的结论需要人逐条复核；省下的不是分析时间，是写 SQL 的时间。 **按厂商看风险。** 神策是叙事分散与全家桶绑定；GrowingIO 是品牌归属与路线分叉；DataFinder 是云绑定、不退订与 90 天删除；Quick Tracking 是生命周期短、私有化缺公开方案；友盟是数据主权；百度是能力上限；诸葛是母公司治理；易观是收缩与支持主体不明；数数是更名一致性与游戏周期；TalkingData 是战略转移与口径冲突。 回到标题。2019–2022 年，差异是“能不能私有化”；2023–2026 年，私有化成了标配，差异变成“能不能进入业务系统”：事件能不能被 CDP、MA、实验、Agent 直接消费，定义能不能复用，权限能不能细到指标。进入越深，替换成本越高；退出条款是给三年后的自己留一条退路。 > **判断**：2026 年选型的第一问题不是“谁功能多”，而是“三年后这份合同还在谁手里、数据还能不能带走”。私有化解决的是数据在哪，进入业务系统决定的是平台有没有用，退出条款决定的是你还有没有选择。 ## 参考来源 - [神策数据 — 官网首页](https://www.sensorsdata.cn/) - [神策数据 — Sensors AI 产品页](https://www.sensorsdata.cn/engines/SensorsAI.html) - [极客公园 — 神策数据 Sensors AI 产品发布会](https://www.geekpark.net/news/366666) - [财联社 — 神策数据完成 2 亿美元 D 轮融资](https://m.cls.cn/detail/1006661) - [阿里云云市场 — 神策分析与神策用户画像](https://market.aliyun.com/detail/cmgj00047786.html) - [GrowingIO — 官网首页](https://www.growingio.com/) - [GrowingIO — 公司介绍（含 StartDT 并购说明）](https://www.growingio.com/about) - [GrowingIO — 分析云 V4.13 发布说明](https://www.growingio.com/news/ss534emcximil3ccipznt) - [诸葛智能 — 官网](https://zhugeio.com/) - [中华网财经 — 容联云想靠 AI 翻盘（2025-08-29）](https://finance.china.com/TMT/13004688/20250829/48772776.html) - [金杜 — 金杜助力容联云私有化（2026-05）](https://www.kingandwood.com/cn/zh/about-us/media-center/king-and-wood-advises-on-taking-private-of-u-s-otc-quoted-cloopen.html) - [易观分析 — 官网](https://www.analysys.cn/) - [易观数科（易观方舟）— 官网](https://www.analysysdata.com/) - [易观方舟 — 智能运营价格页](https://www.analysysdata.com/eapricing.html) - [数数科技 — 更名 ThinkingAI 公告（2026-04-14）](https://www.thinkingai.cn/blog/b8e1a4f6/) - [ThinkingAI — 官网首页](https://www.thinkingai.cn/) - [ThinkingAI — 私有化部署页](https://www.thinkingai.cn/product/self-hosted/) - [TalkingData — 官网首页](https://www.talkingdata.com/) - [TalkingData — 监测分析与营销增长产品页](https://debug.talkingdata.com/analytics-marketing.jsp?languagetype=zh_cn) - [火山引擎 — DataFinder 产品页](https://www.volcengine.com/product/datafinder) - [DataFinder — 新客需知道（计费口径、ID、埋点）](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/Newcustomersneedtoknow?lang=zh) - [DataFinder — 产品与服务计费结算规则](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/VolcanoEngineGrowthAnalysis-ProductServiceBillingSettlementRules?lang=zh) - [DataFinder — 云托管模式介绍](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/IntroductiontoCloudHostingModel?lang=zh) - [DataFinder — 费用、用量与使用咨询](https://docs.volcengine.com/docs/84129/1261816?lang=zh) - [火山引擎 — DataLeap 产品页](https://www.volcengine.com/product/dataleap) - [阿里云 — Quick Tracking 采集分析版本及规格说明](https://www.alibabacloud.com/help/zh/quick-tracking/latest/collection-and-analysis-version-and-specifications) - [阿里云 — Quick Tracking 产品计费说明](https://www.alibabacloud.com/help/zh/quick-tracking/latest/pricing-and-billing-description-collection-analysis) - [阿里云 — Quick Tracking 快速接入](https://www.alibabacloud.com/help/zh/quick-tracking/latest/access-process) - [阿里 UT 埋点接入文档](https://lemon-doc.faas.ele.me/guide/ut.html) - [阿里云开发者社区 — OneData 数据中台体系](https://developer.aliyun.com/article/1674625) - [友盟+ — 官网首页](https://www.umeng.com/) - [友盟+ — 付费服务定价页](https://www.umeng.com/market) - [友盟+ — U-App 移动统计产品页](https://www.umeng.com/analytics) - [百度统计 — 产品首页](https://tongji.baidu.com/web5/welcome/index) - [《中华人民共和国个人信息保护法》](https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm) - [《促进和规范数据跨境流动规定》（2024-03-22）](https://www.cac.gov.cn/2024-03/22/c_1712776611775634.htm) - [字节跳动大规模埋点数据治理实践（2021）](https://www.techweb.com.cn/cloud/2021-09-06/2856406.shtml) - [字节跳动埋点成本治理实践（2023）](https://server.it168.com/a2023/0110/6785/000006785467.shtml) - [美团点评前端无痕埋点实践（2017）](https://tech.meituan.com/2017/03/02/mt-mobile-analytics-practice.html) - [网易有数 BI — 定价页](https://youdata.netease.com/index/deploy) --- # 05 · 大厂自建：埋点平台为什么最后都长成“数据基础设施” > 字节、阿里、腾讯、美团、滴滴、小红书、B 站、快手、京东的公开线索，拼出一条共同的演化路径。 中国大厂很少把“埋点分析”做成一个独立产品。字节的入口叫流量平台，B 站叫北极星，网易云音乐叫全链路埋点管理平台，京东没有统一平台名，公开的是“流量数仓”。名字各异，骨架却趋同：上面是漏斗、留存、路径，中间是指标与 OLAP，下面是采集、传输、存储，贯穿始终的是一层埋点元数据。分析界面是这套系统的出口，不是主体。 这个观察有一个直接推论：大厂自建真正解决的，不是“有没有图看”，而是“这条事件是谁定义的、什么时候改的、错了谁负责、一年花多少钱”。当事件量到万亿级、业务线到上百条，后面这四个问题会比“再多一个图表”贵得多。于是平台的重心自然从报表往上游移，最后长成一套需要编制预算、划分 SLA、做版本发布的数据基础设施。 > **判断**：大厂自建的产物是“埋点全生命周期 + 成本核算”的基础设施，分析只是它最上面的一层。判断一家公司的自建水平，看三件事就够：埋点有没有唯一权威的元数据，事件有没有版本与测试，成本有没有被货币化。 ## 5.1 从报表到平台 先把“自建”拆成三个世界，否则很容易把内部工具、云产品和开源项目混为一谈。 **内部平台**不对外售卖，买单人是业务线，收入体现为内部结算或成本分摊。字节流量平台、B 站北极星、网易云音乐埋点管理平台、京东零售流量数仓、快手 OneSQL、美团与滴滴的指标平台都属于这一类。它们的公开材料以技术博客、QCon/DataFun 演讲和公众号整理稿为主，细节多，但数字基本是自报。 **能力外溢的云产品**是第二类。字节把增长分析做成 DataFinder、把研发治理做成 DataLeap、把 ClickHouse 做成 ByteHouse；阿里云提供 Quick Tracking；腾讯把灯塔放到腾讯云，把零售分析做成有数；网易数帆卖有数 BI。它们有官网、文档和定价页，证据等级更高，但功能被标准化过，和内部平台不是同一套东西（[DataFinder 产品页](https://www.volcengine.com/product/datafinder)、[Quick Tracking 快速接入](https://www.alibabacloud.com/help/zh/quick-tracking/latest/access-process)、[腾讯云灯塔](https://cloud.tencent.cn/document/product/1003/106100)、[有数 BI 定价](https://youdata.netease.com/index/deploy)）。 **技术输出与开源**是第三类。滴滴把小桔棱镜（DiDiPrism）以 Apache-2.0 开源，做移动端操作回放与检测；快手把百 PB 迁移做成平台化的“星移”流程；美团、滴滴把指标平台方法论公开。它们不直接卖 UBA，但降低了后来者的自建门槛（[DiDiPrism](https://github.com/didi/DiDiPrism)、[LICENSE](https://raw.githubusercontent.com/didi/DiDiPrism/master/LICENSE)、[快手迁移实践](https://cloud.tencent.com.cn/developer/article/2710727)）。 把 11 家公司放到一条时间轴上，会看到相当一致的四个阶段。第一阶段是**报表**：按需求建表，一个埋点一张 Hive 表，事件没有统一模型，B 站称之为“按业务需求定制化管理”，数据只能一次性使用（[B 站 2023 年分享](https://zhuanlan.zhihu.com/p/644137017)）。第二阶段是**事件模型**：引入 who/when/where/what/how 的抽象，统一公共字段，SDK 收敛采集，美团的声明式埋点、字节的 Applog、B 站的 SPMID 都在这一层。第三阶段是**元数据平台**：埋点设计成为第一手资料，录入只是二手信息，埋点有了版本、负责人、血缘、质量规则和测试用例；字节的说法很直接——“埋点设计才是 single source of truth”（[字节 2021 年演讲](https://www.techweb.com.cn/cloud/2021-09-06/2856406.shtml)）。第四阶段是**基础设施**：埋点平台与实时计算、湖仓、指标平台、实验平台打通，按成本、SLA、合规做分级。 > **判断**：这四个阶段不能跳。直接买一个分析工具，等于跳过第二、第三阶段，最后一定会回到“口径对不上、埋点找不到、成本下不来”的原点。 先说明证据成色。A 级是官方文档、博客、源码与定价页；B 级是有署名讲者的演讲整理，或细节具体、可追溯的第三方整理；C 级是资料不足或只有二手转述。按此口径，美团、网易有数的部分材料是 A；字节、腾讯灯塔、B 站、网易云音乐、滴滴、京东、快手是 A- 或 B+；阿里大量依赖生态文档，记 B；拼多多是 C。等级不是给公司打分，只说明哪些数字能直接用，哪些只能当公司口径。 ## 5.2 字节跳动：把成本算到每条业务头上 字节的公开材料里，最值得看的不是“日增多少万亿”，而是它怎么把埋点变成一门内部生意。 平台结构分三块：埋点内容（设计、开发、验证、上线、下线）、埋点治理（成本、SLA、合规）、链路（收集、处理、订阅），治理操作台叫 ByteIO。SDK 内置管控，合规不允许的埋点在端侧直接丢弃；Event 先聚合成 Applog 再上报，HTTP 收数进消息队列，实时 ETL 完成解析、清洗、分发。自研计算引擎支持 Groovy 热加载、拓扑重构、UDF/RPC 动态化，可插拔 Flink、PyJstorm、TCE 等运行时（[2021 年演讲](https://www.techweb.com.cn/cloud/2021-09-06/2856406.shtml)）。 规模数字能说明这套系统的量级：2021 年覆盖 2000+ 应用、20 万埋点、日增事件万亿级；2023 年峰值 1 亿+/秒、日增 10 万亿、HDFS 日增 10+PB。这些是公司自报口径，且“万亿/天”包含重复上报与多端，不能直接换算成唯一事件数（[字节 2021](https://www.techweb.com.cn/cloud/2021-09-06/2856406.shtml)、[字节 2023](https://server.it168.com/a2023/0110/6785/000006785467.shtml)）。 真正难复制的是治理链路：**无用埋点下线 → 埋点分级 → 采样上报 → 自动治理**，每一步都有平台入口和可计算的收益。公开口径是 2021 年下线无用埋点省近亿元、分级存储省 100+PB；2022 年采样省 3000+ 万元；监督式治理当年再省 4000 万元。无监督式治理把长尾业务的无用埋点占比从 60% 降到 20%（[2023 年成本治理分享](https://server.it168.com/a2023/0110/6785/000006785467.shtml)）。 这套治理能运转，靠的是四个可被业务看懂的指标：埋点上报总量、埋点成本、无用埋点占比、埋点密度（上报总量 ÷ 用户活跃时长）。埋点密度比总量更有解释力——用户时长没涨、上报量疯涨，基本就是埋点失控。字节的另一个经验是“治理不能靠运动”：业务不会主动看指标，所以要把人工发起改成系统监测、推送、负责人确认，监督式治理每两个月跑一次。 对外，字节把经验拆成三个产品：DataFinder 做增长分析与广告监测，DataLeap 做研发治理，ByteHouse 做分析型数据库（[DataFinder 事件分析](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/Eventanalysis-1?lang=zh)、[广告监测](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/Adtrackingoverview?lang=zh)、[DataLeap](https://www.volcengine.com/product/dataleap)、[ByteHouse](https://www.volcengine.com/product/bytehouse)）。但三者都没有公开单价，属询价型；内部平台与对外产品是否同源、同代码，公开材料没有说明。 ## 5.3 阿里巴巴：资产是编码体系，不是平台 阿里对这件事的贡献，主要不在某个平台，而在三套编码：UT 解决“怎么声明和上报”，SPM 解决“位点怎么编号”，黄金令箭解决“日志按什么规范采集”。再往上，OneData 解决“指标怎么定义”。四件事拼起来，才是阿里系的埋点与指标体系（[UT 接入文档](https://lemon-doc.faas.ele.me/guide/ut.html)、[OneData 整理](https://developer.aliyun.com/article/1674625)）。 UT 用声明式属性（`ut-click`、`ut-visit`、`ut-data` 等）把埋点写进 HTML，减少业务代码侵入；SPM 把页面、模块、位置编成层级位点（spm-a/b/c）；黄金令箭用类似 `/lemon.track.module` 的编码标记采集点。三者共同的思路是：**让埋点在写代码之前就有一个可读、可复用、可定位的名字**。 对外产品 Quick Tracking 的接入顺序很讲究：先定指标体系、再录事件与属性、最后才接 SDK（[快速接入](https://www.alibabacloud.com/help/zh/quick-tracking/latest/access-process)）。它支持事件分析、漏斗、留存、分布、间隔、session、路径、可视化与归因（[埋点 API 文档](https://www.alibabacloud.com/help/zh/quick-tracking/latest/advanced-features-1)）。文档 2025-06 仍在更新，但公开定价页缺失，国内项目仍以询价与部署方案为主。 OneData 的方法论影响更长远：原子指标、派生指标、复合指标，配合 ODS/CDM/ADS 三层建模，把“指标”从报表里抽出来变成可复用的定义。不过公开材料多为第三方整理，像“3000+ 质量规则”这类数字无法独立核实；Quick Tracking 与内部 UT 体系是否同源，官方也没有明确说明。 ## 5.4 腾讯：两条产品线，一个融合引擎 腾讯的公开材料里有两个容易混淆的产品。灯塔是“全场景大数据分析套件”，官方称由腾讯 50+ 业务自 2018 年以来使用的数据中台演化而成，日均数十亿条数据、服务数千名业务员工；有数面向智慧零售，做经营、渠道、客群与营销分析（[腾讯云灯塔 2024-10](https://cloud.tencent.cn/document/product/1003/106100)、[有数用户指南](https://lingshou.tencent.com/doc/bi/intro.html)）。前者是分析平台，后者更接近零售商的经营工具，不能当成同一个东西。 灯塔的能力面很宽：数据上报接入、开发治理、敏捷分析、可视化、用户行为分析、画像、自动化运营、机器学习、A/B 实验。底层是融合分析引擎——Calcite 做统一 SQL 前端，Presto/Impala 做 MPP，ClickHouse 做 BI 抽取加速，Alluxio 做缓存，Kudu 做存储，再加 WLM 负载管理和物化视图（[融合引擎 2023](https://cloud.tencent.cn/developer/article/2219100)）。时效被明确分层：实时统计约 1 分钟可见，基础概况与时段分布约 2 小时，画像按月计算（[腾讯云灯塔](https://cloud.tencent.cn/document/product/1003/106100)）。这个分层值得抄：不同问题需要不同新鲜度，不必都塞进同一条实时链路。 有数的数据模型是另一条线索。它用 Object 模型（`type`、`props`、`from`、`tracking_id`），其中 `tracking_id` 是会话级 uuid，用于行为追溯与数据恢复；再用 idmapping 融合线上、线下用户（[有数数据上报](https://lingshou.tencent.com/doc/bi/report.html)）。这是零售场景逼出来的设计：门店、导购、线上账号本来就不是一套 ID。 限制同样明显。灯塔 FAQ 里“覆盖 7 亿终端”的说法没有标日期（[灯塔平台介绍](https://beacon-help.gitbook.io/beacon-help/faq/guan-yu-deng-ta-ping-tai.md)），属于旧数据，不能当作 2026 年的现状；融合引擎文章停在 2023 年；灯塔与有数的内部埋点治理（元数据、版本、成本）几乎没有公开。腾讯公开的是“引擎能力”和“行业模型”，不是“怎么管埋点”。 ## 5.5 美团与滴滴：采集和语义，分成两层做 美团没有统一对外的埋点平台品牌，公开的是前端埋点体系、指标平台与 BI 三条线。2017 年，美团把埋点分成代码埋点、声明式埋点、无痕埋点三类并存。无痕埋点通过控件 ID、类名、父组件 Index 生成事件标识，配置后台维护映射并动态下发；官方称这套方案让埋点成本降低 80%、上线后无埋点故障（[2017 年实践](https://tech.meituan.com/2017/03/02/mt-mobile-analytics-practice.html)）。同一篇文章还给了一个冷静的判断：无痕埋点只能覆盖约 70% 的需求，剩下 30% 仍要声明式或代码埋点。2019 年的 MTFlexbox 把埋点类型做成 Tag 属性写进布局文件，双端一份配置，支持可视化圈选，让布局与埋点解耦（[2019 年探索](https://tech.meituan.com/2019/08/15/mtflexbox-automation-buried-point-exploration.html)）。这是客户端工程思路：把埋点从“运行时补救”变成“编译期声明”。 2026 年的公开复盘则把重心移到语义层。美团基本否定了“数据集驱动的敏捷 BI”：百万级数据集带来口径混乱、性能不可控、指标无法跨集复用。新一代架构以指标平台为核心，用自动语义把业务语言翻译成逻辑表达，用智能物化做预计算，用多引擎路由做查询降级。规模口径是百余业务线、万级模型、十万级指标维度，日查询百万级、第三方 API 千万级/日，成功率 99.9%，Ad-hoc P90 分钟级、Serving P90 秒级（[2026 年 BI 实践](https://tech.meituan.com/2026/03/20/Busniness-Intelligence-practice-in-meituan.html)）。文中还给出云器 Lakehouse 对比 Trino 千核集群约 2 倍性能的双跑评测（84 张表、1000+TB 数据），但这是厂商合作场景，需打折看。 滴滴走的是另一条路：先把指标定义标准化，再把消费统一。指标字典阶段发现它只是“线上 wiki”，于是升级成带权责、审批、自动命名的指标管理工具，支持原子、派生、计算、复合指标；原子指标或修饰词变更，下游派生指标自动级联变更；T1 核心指标变更需要数据管理员与业务板块管理员双审批。最后用统一查询 DSL 和数据虚拟化收口各数据产品，走 headless BI 路线（[2024 年指标标准化](https://server.it168.com/a2024/0929/6864/000006864595.shtml)）。 端侧，滴滴把小桔棱镜开源，做操作回放、操作检测与数据可视化，基于自研的操作行为标识指令与 DSL，license 是 Apache-2.0（[仓库](https://github.com/didi/DiDiPrism)、[README](https://raw.githubusercontent.com/didi/DiDiPrism/master/README_cn.md)）。它把“回放”定位成埋点的补充证据，而不是替代品。存储侧，滴滴数据湖用 Apache Ozone，ASF 博客称支撑数百 PB（[ASF 博客](https://news.apache.org/foundation/entry/how-didi-scaled-to-hundreds-of-petabytes-with-apache-ozone)）；但这是存储规模，不是事件量，两者不能混用。 > **判断**：美团和滴滴代表同一种分工——采集层负责“采得全、改得动”，语义层负责“口径统一、定义即研发”。两层分开，才有可能让指标平台不被埋点的历史包袱拖住；合在一起，最后往往是一张谁也说不清的表。 ## 5.6 小红书、B 站、快手：三种瓶颈，三种答案 这三家公司的公开材料，恰好对应三种不同的自我诊断。 小红书诊断的是查询。它原来用自研存算分离的 ClickHouse，遇到三个问题：排序键随分析习惯失效、多表 Join 受限、取数方式单一。于是转向 Iceberg + StarRocks：单分区数据量从年初 100 亿行涨到 200 多亿行，用 10 个桶做分桶表支撑大表 Join，P90 查询提升 3 倍、稳定在 10 秒以内，存储相比 ClickHouse 存算分离版本减少一半。后续又用 StarRocks 审计日志推断排序列、异步跑 ZOrder 做“排序键保鲜”，DataCache 让 P90 再提升约 20%，大查询用 `EXPLAIN ESTIMATE` 预判并路由到小集群或 Spark（[2025 年湖仓跃迁](https://cloud.tencent.cn/developer/article/2501517)）。 这笔账算得细，但要看边界：P90 提升 3 倍是特定数据集与查询场景，不能外推；文章经 StarRocks 社区渠道发布，带厂商视角；小红书只公开了分析层，埋点采集、元数据、治理没有细节。它回答的是“分析引擎怎么换”，不是“埋点平台怎么建”。 B 站诊断的是元数据。它做了 SPMID 五段式命名（business_id、page_id、module_id、position_id、埋点类型），事件 ID 本身就是语义，例如 `bili.homepage.top-tabbar.0.click`。属性分三层：全局公共字段、类型通用字段、业务私有字段。元数据里记录命名规范、数据类型、空值/枚举/默认值、版本、优先级和安全等级（S/A/B/C/D）（[2023 年埋点标准化](https://zhuanlan.zhihu.com/p/644137017)）。 工具侧，北极星管埋点创建、属性管理、上报时机、抽样比例和远程停止采集；测试支持扫码连接、实时校验、可视化报告；分析用 ClickHouse，承接日增千亿级数据，一周数据量到万亿级（原文口径，是否含副本待核实）。B 站对曝光类埋点按 1%、10%、20% 采样上报，并把采样率记进元数据，分析时再还原。流程上，B 站把埋点当软件工程治理：DRD 需求文档、六环节四角色、版本与 DIFF、从元数据生成测试规则、分级存储。分享者明确短期不做对外 SaaS。局限也在这里：材料停在 2023 年，两篇官方专栏（[埋点分析平台](https://www.bilibili.com/read/cv22600289/)、[ClickHouse 实践](https://www.bilibili.com/read/cv21106590/)）在本次抓取中被风控拦截，只能确认标题与链接，正文未获取。 快手诊断的是迁移。它把百 PB 数据、200+ 集群、数千张表从 ClickHouse 迁到 Doris/Bleem：OneSQL 做查询透明路由与灰度，星移做 DDL 转换、任务复制、存量迁移、数据校验、SQL 回放、灰度切换和 ClickHouse 下线，KwaiFlow 做离线调度，SeaTunnel 做 ETL。迁移期双写双跑，Hive→ClickHouse 走 T+1/小时级覆盖，Kafka→ClickHouse 走分钟级（[2026 年迁移实践](https://cloud.tencent.com.cn/developer/article/2710727)）。 效果被拆成可验收的工程指标：单表人工操作从 8 小时降到约 5 分钟，任务复制 1 分钟内完成，存量导出约 1GB/s，双跑/补数任务约两天内启动、整体补数约 10 天。日均查询 20 亿次以上。长期目标是把底座收敛成统一多模湖仓，承载指标查询、即席分析、向量检索和面向 Agent 的自然语言分析。同样要标注：文章由 SelectDB 社区转载，带 Doris 厂商立场；“20 亿次/日”是查询量，不是事件量；快手的埋点采集与治理没有公开。 > **判断**：三家公司给出的答案不同，但方法一致——先把瓶颈说成一个可测量的工程问题，再选组件。反过来，先选组件再找理由，最后都会变成一次昂贵的迁移。 ## 5.7 京东、拼多多、网易：资产、黑箱与配置管理 京东的公开材料最像“数据资产”这四个字。它原来按端（主站 App、M、PC、微信、垂站）和时效（实时/离线）分裂出 40+ 模型，统一后收敛为 4 个逻辑模型（曝光、点击、浏览、订单）、8 个实体模型。埋点解析 SDK 把 `shp` 映射为 `shop_id`、`rtm` 映射为 `receive_ts`，下游不再解析原始 JSON；Flink 集成解析 SDK，写入 JDQ，再写 Hudi，保证 Exactly-Once（[2025 年流量资产湖仓](https://developer.jdcloud.com/article/4173)）。 成本账也具体：Lambda 双链路每年多花约 100 万元计算资源，小时级加工又增加近 40 万元存储/计算；改造目标是分钟级可见、存算成本低于原表。曝光口径同样可操作——“单坑位 50% 露出 + 300ms 停留，且只上报页面内第一次曝光”，2024-03 起用 IntersectionObserver 改造（[京东开放平台数据上报](https://opendoc.jd.com/shop/newisv/docs/api/track)）。 局限是缺一个平台名。没有统一品牌，就很难判断这套东西是长期产品还是项目制交付；采集侧细节也少。但它证明了一件事：**埋点语义统一最终会落到表模型上**，40+ 变 4 个逻辑模型，比任何“治理规范”都更能约束下游。 拼多多在本次检索范围内没有公开工程材料——官网、技术博客、QCon/DataFun/InfoQ、GitHub 都没有。所以本章不写它的平台名，也不猜架构。这个空白本身就是结论：一家公司的自建能力可以很强，但完全不在公共知识里；任何“拼多多用了某架构”的说法，没有一手来源就应视为传闻。 网易的答案最有“软件工程”味道。云音乐的曙光埋点做多端一致的对象树、统一自动化埋点和链路追踪；管理平台把埋点元数据按版本管理：客户端每个大版本从 Master 拉出需求组，变更列表包含新增对象、新增血缘、修改参数、删除对象、删除血缘，支持部分变更上线；跨空间用“桥梁”对象挂载子空间埋点树。再配实时校验、线上稽查和代码模板，官方称线上埋点错误数下降 95%（[2023 年全链路埋点平台](https://server.it168.com/a2023/0118/6786/000006786834.shtml)）。 这几乎是把 Git 的工作流搬到埋点上：需求组是分支，DIFF 是变更集，rebase 解决“埋点停在开发分支、上线已过期”，桥梁解决多空间复用。它不需要大模型，只需要承认埋点是一种会演进的代码资产。 商业化侧的有数 BI 是另一回事。它支持 30+ 数据源、拖拽建模、报告/大屏/填报、指标异动分析与预警（[有数个人版](https://youdata.netease.com/index/personal)），定价也公开：个人版永久免费（1 个创作者），高级版 988 元/年/创作者，旗舰版 3888 元/年/创作者，阅览者 988 元/年，MPP 扩容 1G=10 元/年，私有化询价（[有数定价](https://youdata.netease.com/index/deploy)）。但它是 BI，不是 UBA，不能当成同一产品；云音乐平台文章停在 2023 年，文末“贡献到开源社区”的承诺是否兑现，待核实。 ## 5.8 横向对比与共性架构 先看证据，再看结论。 | 公司 | 公开平台/项目名 | 证据类型 | 可信度 | 结论 | |---|---|---|---|---| | 字节跳动 | 流量平台、ByteIO、DataFinder、DataLeap、ByteHouse | 演讲整理、产品文档、产品页 | A- | 全生命周期与成本治理最完整；数字自报 | | 阿里巴巴 | UT、SPM、黄金令箭、Quick Tracking、OneData | 生态文档、云文档、第三方整理 | B | 命名与位点体系最完整；内部架构公开少 | | 腾讯 | 灯塔、有数、融合分析引擎 | 官方文档、工程博客 | A- | 多引擎融合与零售对象模型；材料新旧混杂 | | 美团 | 前端埋点体系、MTFlexbox、指标平台、美团 BI | 官方技术博客 | A | 采集与指标两层都强；UBA 原语讲得少 | | 滴滴 | 指标管理工具、DiDiPrism、Ozone | 演讲整理、开源仓库、ASF 博客 | A- | headless BI 与端侧回放；采集细节少 | | 小红书 | RedBI、Dataverse、DLF | 会议整理 | B+ | 湖仓替换 ClickHouse 的完整工程账 | | 哔哩哔哩 | SPMID、北极星、埋点分析平台 | 演讲整理 | A- | 元数据与流程治理最像软件工程 | | 快手 | KwaiBI、OneSQL、Bleem、星移 | 演讲整理（厂商社区） | B+ | 百 PB 级 OLAP 迁移方法论 | | 京东 | 流量数仓、埋点解析 SDK、Hudi 湖仓 | 官方开发者社区 | A- | 40+ 模型收敛为 4 个逻辑模型 | | 拼多多 | 未发现 | 无 | C | 公开资料不足，不作推断 | | 网易 | 曙光埋点、全链路埋点管理平台、有数 BI | 演讲整理、官方定价页 | A- | 埋点版本化与 rebase/DIFF/桥梁 | 再看“对外产品”和“内部平台”的边界。这是中国案例最容易被误读的地方：云产品页上的功能，不等于内部平台的全部；内部平台的复杂度，也不等于客户能买到的东西。 | 公司 | 对外产品 | 内部平台 | 公开材料能证明的关系 | |---|---|---|---| | 字节跳动 | DataFinder、DataLeap、ByteHouse | 流量平台、ByteIO | 经验外化，是否同源同代码未说明 | | 阿里巴巴 | Quick Tracking | UT、SPM、黄金令箭、OneData | 流程同构；同源关系未说明 | | 腾讯 | 灯塔、有数 | 内部数据中台与埋点体系 | 灯塔自称由内部中台演化；治理细节未公开 | | 美团 | 无对外 UBA | 前端埋点体系、指标平台 | 仅技术博客，无商业产品 | | 滴滴 | DiDiPrism（开源组件，非 UBA） | 指标平台、数据服务 | 开源可验证；平台不对外 | | 哔哩哔哩 | 无（明确短期不做 SaaS） | SPMID、北极星 | 讲者口径，非官方公告 | | 快手 | 无 UBA 对外（Bleem 为内部发行版） | OneSQL、星移、KwaiBI | 迁移方法公开，产品不卖 | | 京东 | 开放平台 ISV 埋点上报 API | 流量数仓 | 对外是接入能力，不是分析产品 | | 网易 | 有数 BI（BI，非 UBA） | 曙光埋点、埋点管理平台 | 同属网易，产品定位不同 | | 拼多多 | 未发现 | 未发现 | 无公开材料 | > **判断**：能力可以外化，组织不能。客户能买到 SDK、看板、权限和计费，买不到“数据产品经理写 DRD、业务线认领埋点、平台方按成本结算”这套组织安排。把云产品当内部平台来对标，是选型时最常见的错位。 把它们压成五层，会看得更清楚。 | 层 | 要回答的问题 | 大厂做法 | 代表 | 中型公司最小实现 | |---|---|---|---|---| | 采集与 SDK | 数据怎么上来，端上怎么控 | 全栈 SDK、声明式/无痕/可视化、端侧合规丢弃、采样开关 | 字节全栈 SDK、美团声明式 + MTFlexbox、京东埋点解析 SDK | 多端 SDK + 服务端 API + 采样开关 | | 埋点元数据与流程 | 谁定义、谁评审、版本怎么管 | 设计即源头、SPMID/UT 编码、需求组、DIFF、rebase、DRD | B 站北极星、网易云音乐、字节流量平台 | 一张元数据表 + 评审流 + 版本号 | | 传输与实时处理 | 怎么解析、清洗、分发 | HTTP 收数 → MQ → 实时 ETL → 订阅，动态拓扑 | 字节 Applog + 自研引擎、京东 JDQ + Flink、快手 OneSQL | Kafka + Flink/Spark + 规范化层 | | 存储与 OLAP | 明细在哪、聚合在哪、怎么查 | ClickHouse/Doris/StarRocks + Hudi/Iceberg + Presto/Trino | 快手 Doris、小红书 Iceberg + StarRocks、美团多引擎 | ClickHouse 或 Doris 单引擎起步 | | 指标语义与消费 | 口径在哪、谁在消费 | 指标平台、语义层、统一 DSL、BI/API | 美团指标平台、滴滴 headless BI、阿里 OneData | 指标字典 + 语义层 + BI | 五层里，第四层最容易买，第二层最难建。多数自建失败不是查询引擎撑不住，而是元数据没有成为唯一权威，导致第一层采上来的东西没人敢用。这个顺序，比任何组件选型都重要。 存储路线可以再压成四种。它们不是“谁更快”，而是“哪类负载放在哪一层”。 | 路线 | 代表 | 适用负载 | 代价 | |---|---|---|---| | ClickHouse 单引擎/存算分离 | 小红书（迁移前）、快手（迁移前）、B 站 | 明细宽表、UV/PV、漏斗、看板 | 多表 Join 弱、排序键易失效、集群运维重 | | Doris/StarRocks MPP | 快手 Bleem、小红书 StarRocks | 多表 Join、湖仓查询、看板、即席 | 需重做分桶/Key/Colocation；迁移与双跑成本高 | | 湖仓（Hudi/Iceberg）+ 多引擎 | 京东 Hudi、小红书 Iceberg、美团云器 LH | 分钟级更新、Exactly-Once、冷热分层、开放存储 | 小文件、元数据、排序键维护；引擎适配工作量大 | | HTAP/关系型 | 腾讯灯塔（TDSQL-C，公开细节少） | 单表 10 亿级、TP/AP 同库、报表 | 分析负载会反噬在线业务，只适合特定规模 | 治理机制有六个，每家都能对上几项：**设计即源头**（字节，测试规则可从设计生成）、**命名即语义**（B 站、阿里，ID 可读可定位）、**元数据版本化**（网易云音乐，错误数下降 95%）、**规则化测试**（B 站、网易、字节，从元数据生成校验规则）、**分级与采样**（字节 P0/P2 的 TTL/SLA，B 站 1%/10%/20%）、**血缘与成本**（字节、滴滴、美团，按业务核算、评估变更影响）（[字节 2023](https://server.it168.com/a2023/0110/6785/000006785467.shtml)、[B 站 2023](https://zhuanlan.zhihu.com/p/644137017)）。 架构上也有共性。控制面是埋点元数据：定义、版本、owner、采样率、安全等级、血缘；数据面是采集网关、消息队列、实时 ETL、明细湖仓、OLAP、指标语义、分析 API。两边通过“下发”和“回写”连接：元数据下发到 SDK 与校验规则，运行时的质量、成本、血缘再回写到元数据。看起来像一条直线，实际是一个环——没有回写，元数据很快会与现实脱节。 ```text 埋点设计（元数据 / 版本 / owner） │ 下发 SDK / 服务端 API ──► 采集网关 ──► MQ ──► 实时 ETL ──► 明细湖/仓 ──► OLAP ──► 指标语义 ──► 分析 / API │ │ │ └── 采样 / 分级 / 合规丢弃 ───┴── 血缘 / 成本 / 质量 ─────────┘ ``` 组织是最后一层，也最难外化。大厂通常有四类角色：平台团队做 SDK、采集、引擎、OLAP 与指标平台；数据产品经理写 DRD、管元数据、做评审验收；分析师消费指标并反馈口径；每个埋点有 owner。中型公司的缺口往往不是工具，而是第二类角色不存在——需求直接给开发，埋点没有主人，离职即失传。 ## 5.9 对中型公司的可复用 pattern 不需要 11 家公司的全部能力。可迁移的部分，是七个 pattern。 **一，把埋点设计变成第一手资料。** 字节的经验是，录入是第二手甚至第 N 手信息，设计才是源头；设计阶段就把类型、必填、枚举、取值范围定好，测试规则和代码模板都能自动生成。中型公司不必一上来做设计工具，但必须有一份机器可读的 tracking plan，而不是 Word 文档。 **二，命名即语义，但别过度设计。** B 站的五段式可读性最好，代价是设计成本高，所以他们做了快速复制、一键导入、维表化下拉；阿里的 SPM 更适合页面型业务；字节的 bid/lab 更适合客户端控件。选一种，坚持三年，比每年换规范更重要。 **三，属性分三层，别平铺二十个 param。** 全局公共字段、类型通用字段、业务私有字段，是 B 站验证过的结构；美团的 lab 是业务字段的容器。平铺参数的扩展性差，后期治理成本高。 **四，元数据要像代码一样版本化。** 网易云音乐的 rebase、DIFF、桥梁，解决的是“埋点停在开发分支、上线时已经过期”；B 站的 DRD 加六环节四角色，解决的是“多方对不齐”。这两件事都不需要大模型，只需要把埋点当代码管。 **五，测试规则从元数据生成，而不是人肉验收。** 字节用设计约束生成测试用例，B 站用元数据生成 DQC 规则、测试机扫码后实时匹配，网易把实时校验做成上线卡点。这是投入产出比最高、也最容易被跳过的一环。 **六，把成本货币化，再谈治理。** 字节给业务看四个指标：上报总量、成本、无用埋点占比、埋点密度。中型公司算不出精确成本，也可以用“事件数 × 单价 × 保留天数”做一张估算表，先让业务看见钱。 **七，指标层是长期归宿，但要先有事件层。** 美团的指标平台建立在标准明细模型与统一聚合模型上，滴滴的 headless BI 建立在指标定义标准化、逻辑模型隔离、统一查询 DSL 上。没有事件层治理，指标层只是把混乱往上再堆一层。 按 6 个月、3–5 人算，可以把范围压到五件事。下表是裁剪建议，验收信号由本报告给出，不是大厂标准。 | 交付物 | 内容 | 验收信号（建议） | |---|---|---| | 机器可读 tracking plan | 事件名、属性、类型、必填、枚举、owner、版本、废弃标记，落在 YAML/JSON + Git | 新增事件必须走 PR；能自动生成校验规则 | | 采集网关 | 鉴权、限流、schema 校验、PII 脱敏、采样开关、脏数据分流 | 坏数据不进主表；采样率可下发给 SDK | | 存储与查询 | 日事件量 1 亿以下用 ClickHouse 单机/小集群；超过 10 亿再考虑 Doris/StarRocks 或湖仓 | 核心看板 P90 达标；扩容不靠加机器硬扛 | | 指标层 | 先做 30–50 个核心指标，统一命名、口径、维度、周期 | BI 只从指标层取数，禁止在数据集里各写 SQL | | 治理看板 | 事件量、存储成本、无用埋点占比、埋点密度、验收通过率、查询 P90 | 每月一次治理会，决议能落到下线/采样/分级 | 六个反模式，都能在公开案例里找到反证。 - **平台名先行**：先起“XX 数据中台”的名字，再找团队填功能。大厂的平台名是事后总结，不是事前目标。 - **全埋点替代设计**：美团 2017 年就说过无痕埋点只覆盖约 70% 的需求；把全埋点当默认，等于把治理成本推到未来。 - **只做报表，不做元数据**：报表能交差，但回答不了“这个数从哪来、能不能改、下线影响谁”。 - **治理靠运动**：字节的结论是业务不会主动看指标，必须系统监测、推送、负责人确认。 - **指标口径散落在 BI 数据集**：美团和滴滴都踩过，百万级数据集带来的不是敏捷，是口径混乱。 - **盲目上 ClickHouse**：单表快不等于多表快，排序键会随分析习惯失效，Join 和扩缩容是长期成本。快手和小红书都是用了几年才迁移。 还必须说清楚证据缺口。11 家里，字节、美团、小红书、快手、京东、网易有 2024–2026 年的一手材料；腾讯、阿里有 2024–2025 年的官方文档或产品页更新；B 站、网易云音乐的核心材料停在 2023 年；阿里缺少集团层面的官方架构文档；拼多多没有公开材料。所有“每天多少亿条/多少 PB”都是公司自报，口径不一——事件数、日志条数、查询次数、存储容量不能横向相加。组织与预算信息几乎空白：平台团队多少人、成本如何分摊、采购什么工具，公开材料很少提。 > **判断**：可复制的是约束，不是平台。约束是“元数据必须唯一、事件必须有版本、成本必须可见”；平台只是在这些约束下长出来的形状。先有约束，再选 ClickHouse、Doris 还是湖仓，顺序反过来就会得到一套昂贵而没人敢用的系统。 ## 参考来源 - [字节跳动大规模埋点数据治理优秀实践（2021）](https://www.techweb.com.cn/cloud/2021-09-06/2856406.shtml) - [字节跳动埋点成本治理实践（2023）](https://server.it168.com/a2023/0110/6785/000006785467.shtml) - [DataFinder 事件分析文档](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/Eventanalysis-1?lang=zh) - [DataFinder 广告监测文档](https://docs.volcengine.com/docs/GrowthAnalysisDataFinder/Adtrackingoverview?lang=zh) - [火山引擎 DataFinder 产品页](https://www.volcengine.com/product/datafinder) - [火山引擎 DataLeap 产品页](https://www.volcengine.com/product/dataleap) - [火山引擎 ByteHouse 产品页](https://www.volcengine.com/product/bytehouse) - [阿里 UT 埋点接入文档](https://lemon-doc.faas.ele.me/guide/ut.html) - [阿里云 Quick Tracking 快速接入（2025-06 更新）](https://www.alibabacloud.com/help/zh/quick-tracking/latest/access-process) - [阿里云 Quick Tracking 埋点 API](https://www.alibabacloud.com/help/zh/quick-tracking/latest/advanced-features-1) - [阿里巴巴 OneData 数据中台体系整理（2025-08）](https://developer.aliyun.com/article/1674625) - [腾讯云：互联网数据分析服务——腾讯灯塔（2024-10）](https://cloud.tencent.cn/document/product/1003/106100) - [腾讯灯塔融合引擎的设计与实践（2023-02）](https://cloud.tencent.cn/developer/article/2219100) - [腾讯有数用户指南](https://lingshou.tencent.com/doc/bi/intro.html) - [腾讯灯塔平台介绍](https://beacon-help.gitbook.io/beacon-help/faq/guan-yu-deng-ta-ping-tai.md) - [腾讯有数数据上报指引](https://lingshou.tencent.com/doc/bi/report.html) - [美团点评前端无痕埋点实践（2017）](https://tech.meituan.com/2017/03/02/mt-mobile-analytics-practice.html) - [MTFlexbox 自动化埋点探索（2019）](https://tech.meituan.com/2019/08/15/mtflexbox-automation-buried-point-exploration.html) - [美团 BI 在指标平台和分析引擎上的探索和实践（2026）](https://tech.meituan.com/2026/03/20/Busniness-Intelligence-practice-in-meituan.html) - [滴滴出行指标标准化实践（2024-09）](https://server.it168.com/a2024/0929/6864/000006864595.shtml) - [DiDiPrism 小桔棱镜 GitHub](https://github.com/didi/DiDiPrism) - [DiDiPrism README](https://raw.githubusercontent.com/didi/DiDiPrism/master/README_cn.md) - [DiDiPrism LICENSE（Apache-2.0）](https://raw.githubusercontent.com/didi/DiDiPrism/master/LICENSE) - [How DiDi Scaled to Hundreds of Petabytes with Apache Ozone](https://news.apache.org/foundation/entry/how-didi-scaled-to-hundreds-of-petabytes-with-apache-ozone) - [小红书湖仓架构的跃迁之路（2025-03）](https://cloud.tencent.cn/developer/article/2501517) - [B 站埋点数据标准化实践（2023）](https://zhuanlan.zhihu.com/p/644137017) - [B 站埋点分析平台的构建之路（专栏，抓取被风控）](https://www.bilibili.com/read/cv22600289/) - [B 站基于 ClickHouse 的海量用户行为分析应用实践（专栏，抓取被风控）](https://www.bilibili.com/read/cv21106590/) - [快手从 ClickHouse 到 Apache Doris 的百 PB、200+ 集群迁移实践（2026-07）](https://cloud.tencent.com.cn/developer/article/2710727) - [京东零售流量资产湖仓架构转型（2025-01）](https://developer.jdcloud.com/article/4173) - [京东开放平台：数据上报（含 2024-03 曝光口径）](https://opendoc.jd.com/shop/newisv/docs/api/track) - [网易云音乐全链路埋点管理平台建设（2023-01）](https://server.it168.com/a2023/0118/6786/000006786834.shtml) - [网易有数 BI 个人版](https://youdata.netease.com/index/personal) - [网易有数 BI 定价](https://youdata.netease.com/index/deploy) --- # 06 · 开源方案（上）：从 PostHog 到 Snowplow，谁能真正替掉 SaaS > 开源给你代码，不给你事件语义、值班表和合规责任；能替掉 SaaS 的，是厂商仍在认真经营的那一层。 先把结论放在前面。2026 年，能真正替掉一部分 SaaS 的开源项目只有三类：把托管做成主产品、用开源换信任的一体化平台（PostHog）；把 schema 与管道做成别人难以复制的数据基础设施（Snowplow、RudderStack）；以及只替代一个模块、但替代得很彻底的工具（Matomo、OpenReplay、Plausible）。除此之外，“开源”更多是一种采购姿态，不是交付能力。代码可以下载，事件语义、升级路径、CVE 响应和合规责任不能。 这也是本章与功能评测的区别。我们不打勾，而是回答三个问题：这个项目的 license 允许你做什么；社区版与企业版之间被切走的是哪一块；以及当它跑到 1,000 万、1 亿、10 亿事件/月时，账单和值班表长什么样。 ## 6.1 开源地图：三条产品线，四种“开源” 把 PostHog、Snowplow 和 OpenReplay 放进同一张漏斗功能表，是最常见的起手错误。它们根本不在卖同一种东西。 | 层 | 代表 | 交付物 | 典型买单人 | 不擅长 | |---|---|---|---|---| | 采集与管道 | Snowplow、Jitsu、RudderStack | 经校验、富化的事件，落到仓库或下游工具 | 数据平台、数据工程、合规 | 面向业务的分析界面、回放 | | 一体化分析 | PostHog、Matomo、Umami、Plausible、Countly | 采集、存储、查询、看板的一体机 | 产品、增长、市场、IT | 复杂仓库治理、跨系统身份图谱 | | 体验回放 | OpenReplay | DOM、网络、控制台级会话回放与协同浏览 | 工程、支持、产品 | CDP、实验、完整事件分析 | 这张表解释了一个常见误判：Snowplow 的客户名单里有很多大品牌，但它不提供开箱即用的漏斗界面；PostHog 的漏斗很好用，但数据默认留在 PostHog Cloud，而不是你的 Snowflake。前者的分析能力取决于你仓库里的 dbt 模型，后者的代价是数据位置由厂商决定。 > **判断**：先确定你要买的是“分析产品”还是“数据基础设施”，再比较功能。前者看分析体验与计价单位，后者看 schema 治理、投递语义与仓库成本；两者的选型标准几乎不重叠。 License 是第二道分水岭，而且比功能表更能决定“能不能用”。行业里说的“开源”至少有四种含义，对应四种完全不同的风险。 | 类型 | OSI 批准 | 项目与条款 | 商用 / 自托管 | 主要风险 | |---|---|---|---|---| | 宽松开源 | 是 | Jitsu：MIT；Umami：MIT | 可商用、可修改、可再分发 | 商标与云服务条款另算 | | Copyleft | 是 | Matomo：GPL-3.0-or-later；Plausible：AGPL-3.0；OWA：GPL-2.0 | 可商用；分发或网络服务会触发义务 | 闭源二次分发、SaaS 化需法务评估 | | Open Core | 部分是 | PostHog：MIT + `ee/` 商业许可；Countly：AGPL-3.0 改 Section 7；OpenReplay：AGPL + MIT + `ee/` | 核心可用，企业功能收费 | 社区版缺关键能力、商标与品牌条款 | | Source-available | 否 | RudderStack：Elastic License 2.0；Snowplow 管道应用：Limited Use License | 受限：ELv2 禁止托管服务；Snowplow 仅限非生产 | 生产使用即违约，需商业合同 | Snowplow 最容易被误读。GitHub 根目录的 [LICENSE](https://github.com/snowplow/snowplow/blob/master/LICENSE) 仍是 Apache-2.0，但仓库 README 写明：2024-01-08 起，新版本核心管道改用 [Snowplow Limited Use License](https://docs.snowplow.io/limited-use-license-1.1/)，并且不再为 2024 年 1 月前的版本提供安全补丁。官方 [licensing 页面](https://docs.snowplow.io/docs/licensing/)把组件拆得很细，结论是：**今天的 Snowplow 不是“Apache-2.0 的 Snowplow”**。只看仓库首页的 license 徽章，会得出相反结论。 RudderStack 的 [LICENSE](https://github.com/rudderlabs/rudder-server/blob/master/LICENSE) 是 Elastic License 2.0：可以内部使用、修改、分发，但不得把软件作为托管或管理服务提供给第三方，也不得绕过 license key。Jitsu 在自己的[对比页](https://jitsu.com/compare/jitsu-vs-rudderstack)里把这一点当卖点：“RudderStack 的 license 禁止你把管道放进自己的产品里，MIT 不会。”这句话是竞品口径，但条款本身可以核对。 Countly 的条款更微妙。[LICENSE.md](https://github.com/Countly/countly-server/blob/master/LICENSE.md) 是 AGPL-3.0 加修改后的 Section 7：不得移除 Countly 的 logo 与品牌，衍生品不得使用其他品牌。README 又写“Free to use under an open-source, non-commercial license”，与 AGPL 的商用许可存在口径冲突。这种模糊比明文收费更危险，因为它把判断留给了法务，而法务通常不会在 POC 阶段出现。 **License 只回答半个问题。** 它管“我能不能改、能不能分发”，不管“我能不能生产用、能不能不署名、能不能做成 SaaS”。后三个问题分别看 Limited Use、商标条款和 ELv2/AGPL。GitHub star 数一个都回答不了；它衡量的是注意力，不是许可、可维护性或你的规模上限。 2024–2026 年，这批项目的产品边界在互相入侵：Snowplow 从管道向上做实时信号与激活，PostHog 从分析向下做 CDP 与数据仓库，OpenReplay 从回放横向做产品分析，Umami 从轻量统计扩到漏斗与回放。功能表会越来越像，但 license、数据位置和运维模型不会趋同。选型时要问“它明年还想做什么”，而不只是“今天有没有这个图”。 ## 6.2 PostHog：源代码开放的云产品 PostHog 是这批项目里资本动作最密集的一家。2025-06 完成 [7,000 万美元 D 轮](https://posthog.com/blog/series-d)，估值 9.2 亿美元，Stripe 领投；同年 9 月 29 日宣布、10 月完成 [7,500 万美元 E 轮](https://posthog.com/blog/series-e)，估值 14 亿美元，Peak XV Partners 领投。官方史页称截至 2025-10 累计融资约 1.94 亿美元（[Hogpedia](https://posthog.com/hogpedia/history-of-posthog)）。一年两轮、估值涨约五成，说明资本市场买的不是“又一个开源分析工具”，而是它把多个产品塞进同一套事件模型的能力。 **产品形态。** 模块包括 Product Analytics、Web Analytics、Session Replay、Feature Flags、Experiments、Surveys、Error Tracking、LLM Observability、Data Warehouse、CDP，以及 2026 年初的 [PostHog Desktop](https://posthog.com/desktop)。真正的差异不是模块数量，而是它们共享 person/event 模型：同一个用户可以从趋势图下钻到回放、Flag 和实验，不需要跨工具拼 ID。对 5–50 人的产品团队，这种“一个合同解决五件事”的体验，通常比自建快得多。 **数据与架构。** 官方[架构文档](https://posthog.com/docs/how-posthog-works)写得很具体：Django 负责 Web 与 API，Rust 服务负责 capture、flags、replay，Kafka（云上用 WarpStream）做总线，ClickHouse 存事件与分析，Aurora PostgreSQL 存元数据，Redis/Valkey 做缓存，S3 存放回放与导出。这套栈的性能上限很高，但运维复杂度被云服务隐藏了；自建意味着你要同时维护 ClickHouse、Kafka、Postgres 和对象存储四套系统。 **计价。** 按产品用量计费，无座位费。[官方定价](https://posthog.com/pricing)的产品分析部分：每月前 100 万事件免费，1–2M 为 $0.00005/事件，2–15M 为 $0.0000343，15–50M 为 $0.0000295，50–100M 为 $0.0000218，100–250M 为 $0.000015，250M 以上 $0.000009。回放前 5,000 条免费，之后 $0.005 降至 $0.0015/条；Flag 前 100 万次免费，之后 $0.0001 降至 $0.00001/次。按公开阶梯累加，1,000 万事件/月约 $324/月，1 亿约 $2,618/月——这是“产品分析”一项的费用，不含回放与平台包。 这里有两个容易被忽略的分层。其一是**事件保留与回放保留不是一回事**：官方文档写的是付费版事件保留 7 年、免费版 1 年；而[平台包](https://posthog.com/platform-packages)页面显示，免费层回放只留 1 个月、付费层默认 90 天，要 12 个月回放得买 Boost（$250/月）或 Scale（$750/月）。其二是**治理能力单独收费**：SSO、SCIM、审计日志这些企业采购的硬门槛，落在 Boost/Scale 平台包里，而不是随事件量附送。把回放与平台包一起算，1,000 万事件/月的年费会从 $3,888 升到接近 1 万美元量级。 **自托管是最大的误解。** PostHog 的代码是 MIT（`ee/` 除外），理论上可以自建；但[官方文档](https://posthog.com/docs/self-host)明确写：自托管“officially unsupported”，不发布 CVE、不做 tagged release、不提供付费支持，规模问题自负。社区可用的只是一个 Docker Compose 的“hobby deploy”。这不是法律限制，是支持承诺的缺失——对生产系统而言，后者更致命。官方定价页称“97% 的公司在免费使用 PostHog”，这是营销口径，不能反推 97% 的公司在自建。 > **判断**：PostHog 是“源代码开放的云产品”，不是“可自建的开源平台”。开源在这里解决的是信任与获客，不是数据主权；把它当私有化方案，通常会在第一次大版本升级或第一次故障时付学费。 它也有真实的短板：按事件线性计价，量大后并不便宜；仓库治理、schema 契约、跨系统身份图谱弱于 Snowplow/RudderStack；功能扩张带来界面复杂度和学习成本。它最适合的，是愿意把行为数据交给一家高速迭代的供应商、换取上线速度的产品团队，而不是数据不得出域的组织。 ## 6.3 Snowplow：管道还在，开源时代结束了 Snowplow Analytics 是英国公司，2024–2026 年未见并购公告，仍以独立公司身份发布消息（所有权细节待核实）。它卖的不是分析界面，而是一条完整的采集链路：Tracker SDK 采集，Collector 接收，Enrich 校验与富化，Iglu schema registry 管事件定义，各类 Loader 把好事件写进仓库，坏事件进 bad stream。官方[管道文档](https://docs.snowplow.io/docs/pipeline/)把这个流程描述为 collect → validate → enrich → good/bad stream → warehouse/BI。 **它的核心资产是 schema，不是代码。** 每个事件是 canonical event 加 self-describing JSON，带 entity/context、schema 版本与校验。原子事件落到客户自己的仓库，因此可以重跑、回填、用任意 SQL 重新定义指标。这是它相对一体化分析工具的真正优势：分析口径可以随业务变化重算，而不是被厂商的报表模型锁死。代价是分析界面不存在——漏斗、留存、路径都要在 dbt 或 BI 里自己建。 **License 把组件切成了四块。** 这是采购时最该逐项核对的地方： | 组件 | 许可 | 生产可用 | |---|---|---| | Tracker SDK | Apache-2.0（JS Tracker 为 BSD-3） | 可 | | 核心库与开发工具 | Community License | 受限：非竞品、不得分发 | | Collector 3.0+、Enrich 4.0+、Iglu Server 0.12+、各类 Loader | Limited Use License | 仅非生产、不得分发 | | 数据模型 | Personal & Academic（Web/Mobile 除外） | 受限 | 也就是说，你可以免费使用 tracker 采集，但要把事件送进生产仓库，Collector、Enrich 和 Loader 都需要商业授权。2024-01-08 是这条线的分水岭：此前的版本不再获得安全补丁，此后的核心管道不再允许生产使用。很多中文资料仍停留在“Snowplow 是 Apache-2.0”，这是本章最需要纠正的过时印象。 **商业变化。** 2025-05-28 发布 Signals，从“管道”扩到实时受众与触发；2026 年把叙事改为“Customer Context Infrastructure”，面向 AI Agent 提供实时上下文。官方 [Newsroom](https://snowplow.io/newsroom) 连续公布 Snowflake、Databricks、AWS 的伙伴奖项，属于厂商口径（B）。这些动作说明它在向上走：不再只卖“把事件送到仓库”，而是卖“仓库里的行为数据能被实时调用”。 **定价。** [定价页](https://snowplow.io/pricing)只给 14 天免费试用，价格取决于月事件量、托管方式、消费量与目的地，需联系销售。对中小团队，这是“不可预算”的一类：你无法在 POC 前算出三年 TCO，只能拿到一个销售流程。 > **判断**：2024 年之后，“开源的 Snowplow”只存在于旧版本和 tracker 里。今天采购它，买的是商业管道合同加一套 schema 方法论；如果预算里没有商业授权这一项，项目会在上线前停住。 它的适用边界也因此很清楚：受监管、数据不得出仓、有专职数据工程团队、愿意把事件 schema 当长期资产的企业。反过来，没有 dbt/BI 建模能力、指望开箱看漏斗的团队，买 Snowplow 只会得到一条通向空仓库的管道。组件多、升级与监控重，总成本是商业 license 加管道算力加仓库存储，通常高于同量级的 PostHog Cloud。 ## 6.4 Jitsu 与 RudderStack：两种管道生意 Jitsu 和 RudderStack 常被放在一起，因为都做“事件管道”。但它们的 license 决定了两种完全不同的生意：Jitsu 的 MIT 允许你把管道嵌进自己的产品，RudderStack 的 ELv2 不允许。这一条，比任何功能差异都更能解释它们的客户结构。 **Jitsu：把管道做轻。** Jitsu Labs 是独立公司，核心仓库 [MIT](https://github.com/jitsucom/jitsu/blob/master/LICENSE)。产品概念很少：Sites 是推送源，Destinations 是目的地，Connectors 是拉取源（主要是 Airbyte 连接的封装），Functions 用 TypeScript/JavaScript 在事件飞行途中做过滤、富化、路由。它不做分析界面，只把事件送到 PostHog、GA4、Amplitude、ClickHouse、BigQuery 等下游。部署有 Cloud、Dedicated、自托管三档，官方称每一档都可自托管；自托管推荐 Kubernetes + Helm，文档提到 operator 与 function servers（[self-hosting](https://jitsu.com/docs/self-hosting)）。 它的计价口径值得单独说：按“active event”计费，只有成功送到至少一个目的地的事件才算；被采集但没有投递的事件不计费。[定价页](https://jitsu.com/pricing)Free 每月 20 万 active events；Growth $99/月含 200 万，之后 $40/每额外 100 万；active sync 超出后 $20/个/月。对“采集多、投递少”的场景，这个口径比按采集量计费友好得多。1,000 万事件/月约 $99 + 8×$40 = $419/月。 它的风险不在技术，在公司。连接器数量、HIPAA、SCIM、审计这些企业功能弱于 RudderStack；社区与文档厚度也薄；长期存续风险要计入采购决策。MIT 给了你“厂商倒了也能自己维护”的退路，但没有给你“厂商倒了有人接电话”的保障。 **RudderStack：把仓库放中间。** RudderStack 是美国公司，核心仓库 [Elastic License 2.0](https://github.com/rudderlabs/rudder-server/blob/master/LICENSE)。产品包括 Event Stream（Sources/Destinations）、Transformations（JS/Python）、Tracking Plans、Data Catalog、Profiles（仓库内身份图谱与特征）、Audiences、Lookout（数据质量与异常监控），2026 年又加了 [RudderAI](https://www.rudderstack.com/blog/)，用自然语言操作管道与治理。 架构是控制面与数据面分离：控制面是 SaaS 的 UI 与配置后端；数据面用 Go 编写，依赖 PostgreSQL 做临时事件队列，流程是 Gateway → Processor → Transformation → Router，事件成功投递后从库中删除，官方称“不持久化事件、不存储用户信息”（[架构文档](https://www.rudderstack.com/docs/get-started/rudderstack-open-source/rudderstack-architecture/)）。Profiles 则把身份图谱与特征计算下推到仓库。部署上，数据面可以放在 RudderStack Cloud（US/EU）或客户 VPC，控制面仍在厂商手里。 [定价](https://www.rudderstack.com/pricing/)Free 为 25 万 events/月；Growth $265/月含 100 万 events，可选 3M/5M/7M/10M/25M 档；超过 25M 联系销售；Enterprise 含 HIPAA、SSO、Profiles/Data Apps、5 分钟仓库同步；年付省 15%。10M 档的价格不在静态页上，需要选档后才显示——这类设计会让 POC 阶段的预算审批很难做。 它的优势是治理工具完整：Tracking Plans、Data Catalog、schema 校验、身份图谱，都是把事件当资产管理，而不是当日志。限制也同样明确：ELv2 禁止托管服务与嵌入产品，SaaS 厂商不能拿它做底层；价格显著高于 Jitsu；没有分析 UI 与回放；自托管只覆盖数据面，控制面仍依赖厂商。 > **判断**：Jitsu 与 RudderStack 都不是“开源版 PostHog”，它们卖的是把干净事件送进仓库。没有 dbt/BI 建模能力的团队，买到的是一条通向空仓库的管道；有建模能力的团队，买到的是一套可以迁移的资产。 ## 6.5 Matomo：数据主权最完整的 Web 分析 Matomo 是这批项目里功能最全的 Web 分析平台之一，核心是 [GPL-3.0-or-later](https://github.com/matomo-org/matomo)，商标注册，商业云与插件包由 Matomo 团队运营。官方口径是 140 万网站、190 多个国家，2025 年通过 ISO 27001:2022（[About](https://matomo.org/about/)）。它的强区是欧洲、医疗、政府、教育——这些买家首先问“数据在哪里”，然后才问“有没有漏斗”。 功能广度在开源 Web 分析里属于最大的一档：访问统计、目标与电商、漏斗、Users Flow、cohorts、多渠道路径、热图、会话录制、A/B 测试、表单分析、媒体分析、站内搜索、Tag Manager、同意管理、自定义维度、API。Cloud 数据存放在德国法兰克福（[定价页](https://matomo.org/pricing/)），这对数据出境敏感的欧洲客户是直接卖点。 **架构决定了它的上限。** 数据模型以 pageview/visit/action 为中心，MySQL/MariaDB 存原始日志，报表通过 `core:archive` 定时预计算成归档表。中小流量下这套模型很稳；大流量下，归档会成为日级任务。官方[自动归档文档](https://matomo.org/docs/setup-auto-archiving/)写得很直白：访问量到“几百/天”以上就建议 cron 每小时跑，数据量大时一次归档“数小时，甚至一天”。这不是配置问题，是 PHP/MySQL 架构的物理约束。 **定价。** [Cloud](https://matomo.org/pricing/) 5 万 hits/月 $29/月（年付 $26/月，不含税），10 万到 500 万 hits 分档，超过 1,000 万联系销售。On-Premise 核心免费，商业插件包 Team €275/月（4 用户、500 万 hits）、Business €1,450/月（20 用户、3,000 万 hits）、Enterprise €3,400/月（50 用户、1 亿 hits），不含服务器与运维。插件包按用户与 hits 叠加，功能越用越全，账单也越叠越高。 **2026 年的两个信号。** 一是 Matomo 6.0 仍处于 beta：2026-10-16 的最新版本是 `6.0.0-b6`（[Releases](https://github.com/matomo-org/matomo/releases)），大版本节奏偏慢。二是 2026-09-01 推出 [Reseller Partner Programme](https://matomo.org/blog/2026/09/matomo-launches-reseller-partner-programme/)，加码云渠道，重点仍是欧洲市场。这两件事放在一起看，更像是它在守存量与渠道，而不是抢产品分析的新预算。 Matomo 是“数据主权”最完整的 Web 分析答案，但 PHP/MySQL 与归档模型把它锁在 Web 分析。把它当产品分析平台，会在事件模型和归档时长上撞墙；把它当 GA 的合规替代，它几乎是开源里最稳的选择。 ## 6.6 轻量段：Umami、Plausible、Countly、OpenReplay 这一组产品的共同点是“只替代一块”，但替代的方式不同：Umami 与 Plausible 用低 TCO 和隐私替掉 GA，Countly 用移动端组合与私有化替掉移动分析套件，OpenReplay 用自托管回放替掉 LogRocket/FullStory。 **Umami：一年内从统计工具变成轻量产品分析。** 核心 [MIT](https://github.com/umami-software/umami)，后端 Next.js/Node，主库 PostgreSQL 12.14+，Docker Compose 可一键起。2025-11-06 的 [v3](https://umami.is/blog/umami-v3) 是转折点：此前它只是轻量 Web 统计，此后补上漏斗、留存、journeys、cohorts、归因、收入；v3.1/v3.2 把热图与会话回放放进自托管，v3.3 加双因素与会话身份拼接，v3.4 加标注、MCP、API key（[Blog](https://umami.is/blog)）。[Cloud 定价](https://umami.is/pricing) Free 每月 10 万 events，Pro $20/月含 100 万，Business $200/月含 1,000 万，回放 $0.005/条，自托管免费。 它的计价有一个细节：pageview、自定义事件、事件属性都计入事件量。埋点越细，账单越高，这一点在选型时经常被低估。功能上，它没有 Flag/实验，权限与审计弱，PostgreSQL 单库有规模上限；Cloud 与 self-host 也有功能差，email reports 只在 Cloud 提供（[Cloud 对比](https://umami.is/docs/cloud)）。但对静态站、内容站和小团队，它是这九家里性价比最高的一个。 **Plausible：把“极简”做成一种资本结构。** 核心 [AGPL-3.0](https://github.com/plausible/analytics)，JS tracker 单独用 MIT 以避免 AGPL 传染。后端 Elixir/Phoenix，PostgreSQL 存元数据、ClickHouse 存分析数据，脚本轻量、无 cookie、支持代理到第一方域名。功能包括 pageview、goals、custom events、funnels、user journeys、自定义属性、segments、annotations、revenue、Stats API、Looker Studio connector；2026 年补了漏斗对比、Flexible funnel、Journeys（[Changelog](https://plausible.io/changelog)）。它明确不做回放、热图、实验、CDP。 更值得注意的是它的规模口径：官方首页称 21,000 个付费订阅、313B 页面浏览、10 人团队、自筹资金、盈利（[Plausible](https://plausible.io/)）。在一个融资新闻密集的赛道里，这是一个反例——不靠融资扩张，靠低客单价和高毛利活下来。代价是功能窄、高流量档价格不透明、CE 明确“community supported”（[README](https://github.com/plausible/analytics)），自托管要同时维护 PostgreSQL 与 ClickHouse。 **Countly：移动端组合最完整的一档，license 最需要法务。** 核心 [AGPL-3.0 改 Section 7](https://github.com/Countly/countly-server/blob/master/LICENSE.md)，要求保留品牌；另有 Flex/Enterprise 商业版。产品覆盖 Advanced Analytics、Adaptivity（A/B、远程配置、推送、应用内消息）、Intelligence（预测与分群）、Crash/Error、User Journeys、Cohorts，官方称 70+ 功能（[定价页](https://countly.com/pricing)）。传统 Lite 是 Node.js + MongoDB 的插件式架构；2026-10-01 发布的 [26.01 新架构](https://countly.com/countly-new-architecture)改为“事件流 + 分析型存储 + 分布式查询”，官方宣称支持 1 亿 MAU、十亿级事件，但未公开具体组件。 部署上，Lite 自托管免费；Flex 是私有云，$175/月起，按用量而非座位计费；Enterprise 完全 on-prem，零厂商访问。它的优势是移动/推送/崩溃/远程配置的组合在开源里少见，且私有化彻底；风险是 license 表述冲突——LICENSE 是 AGPL 加品牌条款，README 却写“non-commercial”，商用前必须让法务确认。26.01 的新架构组件不透明，迁移与稳定性也待验证。 **OpenReplay：把回放做成可自托管的基础设施。** 核心 [AGPL-3.0，部分目录 MIT，`ee/` 商业许可](https://github.com/openreplay/openreplay)。产品以 session recording 为中心：DOM 快照与增量、网络请求、控制台日志、source map、协同浏览（Assist）、热图、漏斗、Spot bug 报告。自托管用 Docker Compose 或 Kubernetes/Helm，单机最低 2 vCPU/8 GB/50 GB，官方建议 t3.large 起步（[部署文档](https://docs.openreplay.com/en/deployment/deploy-docker/)）。第三方技术拆解称后端为 Go、使用 ClickHouse/Kafka，官方部署页未逐项列明，这条标 C/待核实。 [定价](https://openreplay.com/pricing)自托管免费；Dedicated 从 $199/月起（按小时 $0.276），分 O1/O2/O3 三档容量，按并发、是否录 canvas、是否含原生 App 决定；Enterprise 含 SAML/SCIM、审计、专属支持。2026-09-25 发布 1.28.0，仍在迭代。它的限制是回放的存储与带宽成本高、移动原生回放弱、没有实验/Flag/CDP，且 AGPL 与 `ee/` 混合，商用前要看清目录。 **一个反例：OWA 没有停更。** Open Web Analytics 是 GPL-2.0 的 PHP + MySQL 老项目，常被当成“早已死掉”的样本。但它的 1.7.8 停在 2023-01 后，2025-06 起恢复发布 1.7.9、1.8.0、1.8.1，2026-07 到 2026-09 连续发布 1.8.2 到 1.14.0，1.13.0 还明确说“为即将到来的 2.0 分支铺路”（[Releases](https://github.com/Open-Web-Analytics/Open-Web-Analytics/releases)）。它依然不适合作为新产品的主分析平台，但这个例子说明：用“最后一次 commit”判断项目死活，和用 star 判断质量一样不可靠。 轻量段正在分叉。Umami 与 Plausible 卖低 TCO 与隐私，Countly 与 OpenReplay 卖一个可私有化的单模块。它们都能替掉 SaaS 的某一块，没有一家能替掉整套；把它们当“PostHog 平替”，选型会在第三个模块上失败。 ## 6.7 能力对比：功能表之外，看身份与治理 下面三张表覆盖能力、版本切分与隐私。需要先说明口径：“强/中/弱”是这九家之间的相对比较，不是与全部商业 UBA 比较；Countly 的回放能力官方页面未明确列出，标“待核实”而不是想当然。 | 对象 | 核心许可 | 事件分析 | 回放/热图 | Flag/实验 | 治理 | 运维难度 | |---|---|---|---|---|---|---| | PostHog | MIT + `ee/` | 强 | 强/强 | 强 | 弱（靠命名约定） | 中（云）/极高（自建） | | Snowplow | Apache-2.0（旧）/ Limited Use（新） | 弱（靠 BI） | 不支持 | 不支持 | 强（Iglu schema） | 高 | | Jitsu | MIT | 不支持 | 不支持 | 不支持 | 中（Functions，无中心 plan） | 中 | | RudderStack | Elastic License 2.0 | 不支持 | 不支持 | 不支持 | 强（Tracking Plans） | 中高 | | Matomo | GPL-3.0+ | 中强 | 强/强 | 中（A/B 插件） | 弱（无 schema registry） | 中 | | Umami | MIT | 中 | 中/中 | 不支持 | 弱 | 低 | | Plausible | AGPL-3.0 | 中 | 不支持 | 不支持 | 弱 | 中 | | Countly | AGPL-3.0 §7 | 强（移动） | 待核实 | 强 | 中 | 中高 | | OpenReplay | AGPL + MIT + `ee/` | 中 | 强/强 | 不支持 | 弱 | 高 | 这张表最能预测迁移成本的，不是“事件分析”列，而是“治理”列。Snowplow 的 Iglu schema 与 RudderStack 的 Tracking Plans 是资产，迁出时最难，因为事件定义、版本和校验规则都在里面；PostHog、Umami、Plausible 的事件命名靠人，迁出容易，但治理弱；Matomo 与 Countly 的身份模型绑定 cookie/device，跨端合并要额外做。**如果你的痛点是“同一用户在 App、小程序、Web 上对不上”，先解决身份，不要先换分析 UI。** 第二张表是版本切分。开源项目的“免费”通常不是“功能少一点”，而是“关键能力被切走”。 | 对象 | 社区版/免费层 | 企业版/云版多出什么 | 采购陷阱 | |---|---|---|---| | PostHog | 100 万 events、5,000 回放、100 万 Flag 请求，1 年事件保留 | 更高额度、7 年事件保留、企业功能与支持 | 自托管“不支持”；SSO 与 12 个月回放要买平台包 | | Snowplow | Tracker 与旧版代码；新管道仅非生产 | 生产授权、CDI 控制台、支持 | 生产即需商业合同 | | Jitsu | MIT 全功能；云上 20 万 active events | 更高额度、专属部署、支持 | 企业合规功能弱 | | RudderStack | 25 万 events/月、基础目的地 | HIPAA、SSO、Profiles、5 分钟同步 | ELv2 禁止托管服务 | | Matomo | GPL 核心全功能 | 高级插件包、Cloud 托管、支持 | 插件包按用户与 hits 叠加 | | Umami | MIT 全功能（自托管） | Cloud 的 email reports、更高额度、支持 | Cloud 与 self-host 功能差 | | Plausible | AGPL CE 全功能 | Cloud 托管、SSO、更多站点与保留 | CE 无官方支持 | | Countly | Lite 免费（含品牌条款） | Flex 私有云、Adaptivity/Intelligence、SLA | license 表述冲突 | | OpenReplay | AGPL 核心，自托管免费 | `ee/` 功能、SAML/SCIM、审计、支持 | 回放存储成本 | 第三张表是回放与隐私。回放是隐私风险最高的模块，而“无 cookie”只解决标识问题，不解决事件属性里的 PII。 | 对象 | 回放/热图 | Cookie 与同意 | 数据位置 | 隐私风险点 | |---|---|---|---|---| | PostHog | 强/强 | 默认 cookie，支持同意与 mask | PostHog Cloud（区域待核实） | autocapture 可能采到敏感文本；回放需配置 mask | | Snowplow | 不支持 | tracker 可配置 cookie/同意 | 客户仓库/湖 | 原始事件含 PII 时，治理责任在客户 | | Jitsu | 不支持 | 透传，需自建同意 | 客户仓库/云 | Functions 里可能把 PII 写进日志 | | RudderStack | 不支持 | 透传，需自建同意 | 客户仓库/云（US/EU） | 事件不持久化，但目的地可能留存 | | Matomo | 强/强 | 支持无 cookie、IP 匿名、同意 | Cloud 法兰克福/自建 | 默认配置不当会过度采集 | | Umami | 中/中 | 默认无 cookie | 自建/CDN 边缘 | 自定义属性可能写入 PII | | Plausible | 不支持 | 无 cookie | Cloud EU/自建 | 脚本代理可绕过 ad blocker，需披露 | | Countly | 待核实 | 设备 ID/同意插件 | Flex 区域可选/自建 | 移动设备标识与推送 token | | OpenReplay | 强/强 | 需自建同意与 mask | 自建/50+ 区域/BYOC | DOM 回放会录到表单，遮罩需配置 | > **判断**：如果法务问“分析工具会不会录到用户密码”，先看回放配置，再看 license；这两件事没有关系。反过来，如果采购问“能不能私有化”，先看 license 与数据面，再看功能表；这两件事关系很大。 还有一个所有厂商都回避的问题：规模上限。这九家里没有一家给出可审计的“单机/集群上限”，官方的“支持 X 亿事件”是架构目标，不是在你的 schema、查询并发、保留期下的承诺。Countly 宣称 1 亿 MAU、Matomo 称云可扩到数亿 hits/月，都是厂商口径（B）。规模问题只能用自己的三个真实事件量做压测，不能从官网抄一个数字。 ## 6.8 自建的真实门槛：运维、计价与退出 自建的门槛不在安装，在运维。这一节把四件事拆开算：日常运维、现金 TCO、计价单位的差异、以及中国团队的特殊约束。 **第一，运维是持续成本。** Matomo 的报表靠 `core:archive` 预计算，大站一次归档可达数小时甚至一天；Plausible CE 要同时维护 PostgreSQL 与 ClickHouse；OpenReplay 单机最低 2 vCPU/8 GB/50 GB，回放量上来后存储与带宽线性增长；Countly Lite 仍以 MongoDB 为主，26.01 新架构的组件还没公开。这些不是“装一次就好”的成本，而是每个月都要有人看的任务。 **第二，现金 TCO 在中等规模下明显不利于自建。** 以 1,000 万事件/月、12 个月保留、单条原始 200 B 为例：压缩后按 50 B 计，3 副本约 18 GB，存储费用可以忽略；真正贵的是计算、消息队列和人力。自建一套 PostHog/Snowplow 形态，3 台 8C32G 加托管 PostgreSQL、Kafka、对象存储、监控，按公有云 list price 约 $1,800–3,000/月；再加 0.4 个 SRE（按 $5,000/月 loaded 计）约 $2,000/月；合计 $3,800–5,000/月，约 $46k–60k/年。 | 月事件量 | PostHog Cloud（公开阶梯累加） | 自建基础设施 + 人力 | 量级判断 | |---|---|---|---| | 1,000 万 | 约 $324/月，$3,888/年 | $3,800–5,000/月，$46k–60k/年 | 云端便宜一个数量级 | | 1 亿 | 约 $2,618/月，$31k/年 | 约 $72k–96k/年 | 云端仍便宜 | | 10 亿 | 约 $11.6k/月，$139k/年 | 软件接近零，1–2 FTE 加基础设施不低于 $40 万/年 | 同一数量级，自建仍不省钱 | 这张表只算现金，不含迁移、双跑、功能缺口与回放存储。回放是另一条成本曲线：AWS S3 标准存储 $0.023/GB-月，公网出站 $0.09/GB；一条 10 分钟、2 MB 的录制，100 万条约 2 TB，单月新增存储约 $46，按 12 个月留存累积，年末约 24 TB，第一年平均 12 TB，S3 年费约 $3,400。看起来不贵，但真正的成本在写入、查询与前端重建，不在 S3 账单。 **第三，“免费”有三种陷阱。** License 陷阱：Snowplow 的 GitHub 看起来是 Apache-2.0，生产管道却要商业授权；RudderStack 的 ELv2 允许内部使用，却不允许做成 SaaS 卖给客户；Countly 的 AGPL 加品牌条款，README 又说 non-commercial。运维陷阱：PostHog 自托管“官方不支持”，意味着出问题没有补丁承诺；Matomo 的归档 cron 在大站会变成日级任务；Plausible CE 要维护 ClickHouse。计价陷阱：PostHog 按事件、回放、Flag 分别计费；Umami 把属性也计入事件；Jitsu 只算 active event；RudderStack 的 10M 档价格不在静态页；Snowplow 完全询价。把“月事件量”当成唯一变量，预算一定偏。 **第四，规模阈值只能当经验判断。** 100 万 events/月以下，Umami Cloud、Plausible、Matomo Cloud 足够，PostHog 免费额度也能覆盖，自建不值得；100 万到 1,000 万，PostHog Cloud 的体验与价格最均衡，需要仓库时加 Jitsu 或 RudderStack，回放用 OpenReplay Dedicated；1,000 万到 1 亿，PostHog Cloud 加仓库导出，或 Snowplow/RudderStack 加仓库加 BI，此时“分析界面”和“数据基础设施”要分开买；1 亿以上，自建 ClickHouse/Doris/StarRocks 加管道（见第 07 章），开源的价值在可控与可嵌入，不在省钱。这些阈值是假设，不是厂商承诺；真正的分界线是查询并发、保留期、schema 数量、合规要求四个变量。 **中国团队还有三个额外约束。** 一是 SDK 覆盖：这九家的公开文档以 Web、iOS、Android、Node 为主，未见任何一家官方支持微信小程序、鸿蒙原生、支付宝小程序（待核实）。如果产品主战场在中国超级 App 内，开源方案只能解决服务端管道与分析后端，前端采集仍要自研或接国内厂商。二是数据出境：PostHog Cloud、Plausible Cloud、Umami Cloud、Matomo Cloud 的公开区域以欧美为主；Snowplow、Jitsu、RudderStack、OpenReplay 可私有化，但要自己承担 K8s、对象存储、备份与等保/审计。开源的“数据主权”只在你能运维时成立。三是 license 合规：AGPL 对“通过网络提供服务”有传染性义务，ELv2 禁止托管服务，Snowplow Limited Use 禁止生产；把开源组件嵌进商业产品前，先做 license 清单，不要等融资尽调才发现。 **90 天 POC 只问五个问题。** 数据最终在哪里，云、客户 VPC 还是仓库？这决定候选集，不是功能表。谁拥有 schema，数据工程还是产品经理？前者加分给 Snowplow/RudderStack，后者加分给 PostHog/Umami。最贵的查询是什么，漏斗、留存、路径的并发与时间范围决定存储选型。回放要不要，要就把 OpenReplay 或 PostHog 纳入，不要就别为回放存储买单。退出成本是多少，事件能否全量导出、schema 是否开放、历史数据能否迁移？Snowplow、Matomo、Plausible 在这项上明显更好。 > **判断**：开源 UBA 的真正价值不是“免费”，而是“可审计、可嵌入、可迁移”。如果团队没有至少 0.5 个能维护 ClickHouse 与 K8s 的人，2026 年的理性选择仍是托管服务；开源只作为数据出口与降级方案，而不是主平台。三个条件同时成立时——已有平台团队、事件量足够大、愿意用自建替换掉一部分产品功能——自建才可能划算。缺一个，托管通常更便宜。 ## 参考来源 - [PostHog raises a series D (and a small C)](https://posthog.com/blog/series-d) - [PostHog "E"xciting news: Series E](https://posthog.com/blog/series-e) - [History of PostHog — Hogpedia](https://posthog.com/hogpedia/history-of-posthog) - [PostHog Pricing](https://posthog.com/pricing) - [PostHog Pricing (Markdown, per-unit rates)](https://posthog.com/pricing.md) - [PostHog Self-host docs](https://posthog.com/docs/self-host) - [PostHog architecture](https://posthog.com/docs/how-posthog-works) - [PostHog LICENSE](https://github.com/PostHog/posthog/blob/master/LICENSE) - [PostHog Desktop](https://posthog.com/desktop) - [PostHog Platform Packages](https://posthog.com/platform-packages) - [Snowplow About us](https://snowplow.io/about-us) - [Snowplow Pricing](https://snowplow.io/pricing) - [Snowplow Newsroom](https://snowplow.io/newsroom) - [Snowplow LICENSE (root, Apache-2.0)](https://github.com/snowplow/snowplow/blob/master/LICENSE) - [Snowplow licensing overview](https://docs.snowplow.io/docs/licensing/) - [Snowplow pipeline docs](https://docs.snowplow.io/docs/pipeline/) - [Snowplow Limited Use License](https://snowplow.io/blog/introducing-snowplow-limited-use-license) - [Snowplow Limited Use License 1.1 (docs)](https://docs.snowplow.io/limited-use-license-1.1/) - [Jitsu Pricing](https://jitsu.com/pricing) - [Jitsu LICENSE (MIT)](https://github.com/jitsucom/jitsu/blob/master/LICENSE) - [Jitsu vs RudderStack: Licence and Price](https://jitsu.com/compare/jitsu-vs-rudderstack) - [RudderStack Pricing](https://www.rudderstack.com/pricing/) - [RudderStack Architecture](https://www.rudderstack.com/docs/get-started/rudderstack-open-source/rudderstack-architecture/) - [RudderStack LICENSE (Elastic License 2.0)](https://github.com/rudderlabs/rudder-server/blob/master/LICENSE) - [RudderStack Blog](https://www.rudderstack.com/blog/) - [Matomo Pricing](https://matomo.org/pricing/) - [Matomo About](https://matomo.org/about/) - [Matomo GitHub repository (GPL-3.0)](https://github.com/matomo-org/matomo) - [Matomo auto-archiving docs](https://matomo.org/docs/setup-auto-archiving/) - [Matomo Reseller Partner Programme (2026-09-01)](https://matomo.org/blog/2026/09/matomo-launches-reseller-partner-programme/) - [Matomo Releases](https://github.com/matomo-org/matomo/releases) - [Umami Pricing](https://umami.is/pricing) - [Umami Cloud vs self-hosted](https://umami.is/docs/cloud) - [Umami v3 announcement](https://umami.is/blog/umami-v3) - [Umami GitHub repository (MIT)](https://github.com/umami-software/umami) - [Plausible Pricing](https://plausible.io/#pricing) - [Plausible Analytics](https://plausible.io/) - [Plausible Changelog](https://plausible.io/changelog) - [Plausible GitHub repository (AGPL-3.0)](https://github.com/plausible/analytics) - [Countly Pricing](https://countly.com/pricing) - [Countly 26.01 new architecture](https://countly.com/countly-new-architecture) - [Countly LICENSE (AGPL-3.0 + Section 7)](https://github.com/Countly/countly-server/blob/master/LICENSE.md) - [OpenReplay Pricing](https://openreplay.com/pricing) - [OpenReplay GitHub repository (AGPL/MIT/ee)](https://github.com/openreplay/openreplay) - [OpenReplay Docker deployment docs](https://docs.openreplay.com/en/deployment/deploy-docker/) - [OpenReplay Releases](https://github.com/openreplay/openreplay/releases) - [Open Web Analytics Releases](https://github.com/Open-Web-Analytics/Open-Web-Analytics/releases) - [OWA LICENCE (GPL-2.0)](https://github.com/Open-Web-Analytics/Open-Web-Analytics/blob/master/LICENCE) - [AWS S3 Pricing](https://aws.amazon.com/s3/pricing/) --- # 07 · 开源方案（下）：OLAP、管道与一套能跑起来的自建栈 > 自建 UBA 的成败不在引擎跑分，而在事件模型、去重口径与谁值夜班；栈选错一层，三年后都要用人力补票，且很难回头。 **先给判断：开源自建 UBA，七成工作量不在选引擎，而在事件模型、身份、权限、指标语义和运维；剩下三成，才是引擎与管道。** 这句话不是劝退，而是帮你尽早排除一类错误立项：团队还回答不了“同一个用户在 App、小程序和 Web 上怎么算一个人”，却已经开始比较 ClickHouse 与 Doris 的扫描速度。引擎当然重要，但它只在事件模型确定之后才重要；顺序反了，任何引擎都会被用成慢查询生成器。 本章不给“最强引擎”排名。它提供的是一条排除路径：先用负载特征去掉不合适的选项，再用成本公式算出量级，最后用三套参考栈和一张清单决定买、建还是租。 ## 7.1 事件分析的负载特征 **UBA 的查询难点不是“扫得快”，而是同一份事件被反复以不同窗口、不同身份、不同去重口径重算。** 把这句话想清楚，后面的引擎差异才有意义。 **写入是追加，更新是例外。** 典型 UBA 集群日增几千万到几百亿条事件，这是经验区间，不是厂商承诺；单条 0.3–2 KB。写入以批量追加为主，更新只发生在用户属性、身份绑定、隐私删除等少数场景。这个特征让列存加批量 part 的引擎天然占优，也让“频繁 UPDATE”变成昂贵的例外。 **宽表与半结构化并存。** 一张事件表常有几百个属性列，其中大量是低基数枚举、URL、JSON。列存喜欢“宽而稀疏”，但 schema 漂移会让物化视图和索引反复重建。常见的折中是：事件主表打平 30–50 个高频属性，长尾进 JSON，用户与设备维度单独建表。 **低延迟聚合与高并发同时发生。** 一个看板可能同时发 20–50 个查询，每个扫 7–90 天分区；产品、运营、老板在早上九点打开同一批看板，尖峰并不均匀。引擎要能扛住“少量大查询 + 大量小查询”的混合，而不是只在单查询基准里快。 **去重与迟到是常态。** SDK 重试、客户端离线补传、服务端重复消费都会产生重复事件；移动端迟到几分钟到几天很常见。去重放在摄入端还是查询端，直接决定存储成本与查询复杂度：摄入端要唯一 event_id 与幂等写入，查询端要 FINAL、argMax 或 COUNT(DISTINCT)，后者在十亿级上会把 CPU 翻倍。 **漏斗、留存、路径是序列问题。** 它们不是简单的 GROUP BY，而是“同一用户按时间排序后，判断步骤是否按序发生”。SQL 能写，但窗口函数与自连接会放大扫描和 shuffle；这也是很多团队在 BI 里写漏斗，最后都回到预聚合的原因。 **明细回查与多租户是最后一公里。** 分析发现问题后，用户要下钻到具体用户、会话、事件；同时不同业务线、不同客户的数据要隔离。租户隔离不能靠“多加一个 WHERE tenant_id”解决资源争抢，这一点在 7.8 还会展开。 这六种特征会反过来决定建模。宽表把用户、设备、事件属性全部打平，查询快、写入简单，但属性变更要回溯，列数会膨胀；星型模型把事件、用户、设备、维度拆开，join 多，适合 Doris/StarRocks，不适合 ClickHouse 的大规模 join；JSON/嵌套把长尾属性放一个列，节省列数，但查询要用 JSON 函数，索引与压缩效率下降。没有一种模型适合所有 UBA。 还有一个常被忽略的变量：规模不能只用事件量描述。查询并发、保留期、属性与 schema 数量、租户数量，任何一个翻倍，都会把同一事件量的成本放大。两家公司都写“日增 5 亿”，一家是 3 个租户、保留 90 天、20 个看板；另一家是 300 个租户、保留 2 年、200 个看板——后者需要的不是同一个引擎配置。 > **判断**：先定事件 taxonomy、身份图、会话规则和指标口径，再按负载选引擎；顺序反了，换引擎只是换一个地方变慢。 这也解释了为什么“接入一个数据库就有了 UBA”是误判。ClickHouse 给你查询速度，不给你事件定义、身份合并、漏斗界面、权限模型和指标口径。把这些当成数据库自带的能力，是自建项目最常见的起点错误。 ## 7.2 ClickHouse **ClickHouse 是四种 OLAP 引擎里最像“为不可变事件而生”的一个，也是最容易被误用的一个。** 它的优势集中在单表扫描、压缩率和写入吞吐；它的短板也正好落在 UBA 经常需要的去重、更新、join 和租户隔离上。 ClickHouse 由 ClickHouse Inc 主导，Apache License 2.0；项目 2016 年由 Yandex 开源，2021 年独立为公司 [ClickHouse 仓库](https://github.com/ClickHouse/ClickHouse) [Dealroom 报道](https://dealroom.co/news/146838-clickhouse-arr-passes-350m-as-ai-agents-fuel-database-demand/)。核心是 MergeTree 家族：数据按 ORDER BY 排序写入 part，后台合并，主键索引是稀疏索引，因此“按什么排序”几乎等于“哪些查询会快” [MergeTree 文档](https://clickhouse.com/docs/reference/engines/table-engines/mergetree-family/mergetree)。典型事件表按 tenant_id、event_date、event_name、user_id 排序，按月分区，按 event_date 设 TTL（生存时间），属性尽量打平，JSON 只放长尾。 去重是 ClickHouse 最需要提前设计的地方。ReplacingMergeTree(version) 能做最终去重，但合并时机不确定，查询时要用 FINAL 或 argMax 才能保证口径。这不是缺陷，而是“写入便宜、查询时付账”的取舍；如果业务不能接受查询端补丁，应该在摄入端生成唯一 event_id，并控制重复写入。 分析函数是它的强项：windowFunnel、retention、sequenceMatch、uniqExact/uniqCombined 都能直接用。但它没有内置的漏斗、留存、路径界面，这些要在应用层或 BI 层实现。换句话说，ClickHouse 给你的是计算原语，不是产品。 部署与计价决定了它的成本结构。开源自建之外，还有 ClickHouse Cloud（AWS/GCP/Azure）与 Bring Your Own Cloud；中国大陆区域与合规可用性需要单独确认（待核实）[ClickHouse 定价页](https://clickhouse.com/pricing)。Cloud 存储 25.30 美元/TB/月；计算单价 Basic 0.2181、Scale 0.2985、Enterprise 0.3903 美元/unit/小时；公网出流量 0.1152 美元/GB 起；新用户 300 美元/30 天 [ClickHouse 定价页](https://clickhouse.com/pricing)。定价页只给 unit 单价，没有给 unit 与 vCPU/内存的换算，必须用官方估算器确认，不能把 unit 当 vCPU。 部署形态会改变成本曲线。Cloud 把容量弹性卖给查询峰值，BYOC 把网络、备份、升级拉回自己的云账号；前者适合波动大、运维薄的团队，后者适合数据不能出云账号的组织。自建看起来没有 license，实际是把账单换成了闲置容量、备份和人力，这三项不会出现在云厂商的报价单上。 商业势能是它最容易被忽略的变量。2026 年 1 月估值 150 亿美元，2026 年 8 月 ARR 超过 3.5 亿美元 [Dealroom 报道](https://dealroom.co/news/146838-clickhouse-arr-passes-350m-as-ai-agents-fuel-database-demand/)。它在 2025 年 3 月 13 日收购 HyperDX，补上可观测性界面与会话回放 [HyperDX 收购公告](https://clickhouse.com/blog/clickhouse-acquires-hyperdx-the-future-of-open-source-observability)；2026 年 1 月 16 日收购 Langfuse，进入 LLM 可观测性 [Langfuse 加入公告](https://python-sdk-v3.docs-snapshot.langfuse.com/blog/joining-clickhouse/)。2026 年 9 月 23 日的 26.9 版本加入只追加物化视图的增量刷新、高基数 DISTINCT 落盘等能力 [26.9 发布说明](https://clickhouse.com/blog/clickhouse-release-26-09)。这些动作说明它在从数据库公司变成实时数据平台公司，而不是只卖查询。 口径冲突要并列写。BusinessWire 在 2026 年 5 月的新闻稿称 ClickHouse ARR 2.5 亿美元、4,000 家客户，但该页面无法访问，只能标为待核实 [BusinessWire 新闻稿](https://www.businesswire.com/news/home/20260527813115/en/ClickHouse-Tops-%24250M-ARR-and-4000-Customers-Launches-Claude-Powered-Agents-at-Open-House-2026)。它与 Dealroom 的 3.5 亿美元不是同一时点、同一来源，不能混成一个数。 限制也很具体：多表 join 需要精心设计；ALTER UPDATE/DELETE 是重操作；part 过多、合并跟不上会拖垮写入；多租户资源隔离要靠副本、计算组或独立集群；没有指标语义层。调优方向因此很固定：按天或按月分区，ORDER BY 把租户、事件名、用户放前面，高频过滤属性用跳数索引或 Projection，漏斗与留存预聚合成 AggregatingMergeTree，避免 SELECT * 和跨大表 JOIN，写入用批量或 async_insert 控制 part 数量。 ## 7.3 Doris / StarRocks **Doris 与 StarRocks 常被放在一起，因为它们的共同点很实际：SQL 兼容、更新自然、join 能打，适合“事件表要和订单表、用户表放在一起查”的团队。** 它们不是 ClickHouse 的廉价替代，而是另一种负载形状的答案。 Doris 是 Apache 软件基金会顶级项目，Apache License 2.0，商业化公司 SelectDB（飞轮科技）由创始团队组建 [Doris 仓库](https://github.com/apache/doris)。它采用 FE/BE 架构，FE 管元数据、查询解析和节点管理，BE 管存储与计算；支持 Duplicate、Aggregate、Unique 三种数据模型，Unique 模型支持 merge-on-write 行级更新；同步单表物化视图与异步多表物化视图并存；采集以 Stream Load、Routine Load、Flink/Spark Connector 为主，另有湖仓 Catalog、倒排索引、向量索引 [Doris 4.x 文档](https://doris.apache.org/docs/4.x/getting-started/what-is-apache-doris/)。建表通常按日期分区、按 key 分桶，UV 用 bitmap/roaringbitmap，半结构化用 VARIANT。官方称针对万列宽表做了优化，也给了宽表聚合 5–10 倍向量化提升的说法——后者是厂商自测口径，不是第三方复现。 Doris 的版本节奏很快。4.0.0 于 2025 年 10 月 14 日发布，加入向量索引、AI 函数、SEARCH()、Spill Disk、TopN 懒物化与 SQL Cache [Doris 4.0.0 发布说明](https://doris.apache.org/releases/v4.0/release-4.0.0/)；4.1.0 于 2026 年 4 月 21 日、4.1.5 于 2026 年 10 月 16 日继续补湖仓、AI 资源、Routine Load 与物化视图 [Doris 版本记录](https://doris.apache.org/releases/core/)。官网称 10,000+ 用户 [Doris 官网](https://doris.apache.org/)；SelectDB 文档又称“10 年超 2000 家企业使用”，两个口径不同，都是厂商口径 [SelectDB 企业版介绍](https://docs.selectdb.com/enterprise/4.x/getting-started/selectdb-enterprise-overview)。版本快也意味着升级风险：4.0 之后功能扩张明显，向量/AI 能力较新，生产验证要自己做；升级前先跑回归，不要盲目追最新版。 StarRocks 同样是 Apache License 2.0 [StarRocks LICENSE](https://github.com/StarRocks/starrocks/blob/main/LICENSE.txt)，项目隶属 LF Projects，商业公司 CelerData 在 2026 年 5 月 27 日更名为 PhoenixAI [PhoenixAI 更名报道](https://www.dbta.com/Editorial/News-Flashes/CelerData-Rebrands-as-PhoenixAI-Introduces-Analytical-Engine-Designed-for-AI-Agents-174972.aspx)。架构是 FE/BE/CN，强调 CBO（基于代价的优化器）、向量化 C++ 执行引擎、Primary Key 模型、同步/异步物化视图、Shared-data 存算分离，以及 Iceberg/Hudi/Delta/Paimon Catalog [StarRocks 官网](https://www.starrocks.io/)。它的强项是复杂多表 join、窗口函数、CTE 与湖仓联邦查询；在四个引擎里，它的“多表 + 高并发”最均衡。 StarRocks 的两条风险要写进采购材料。第一是版本质量：4.1.0 的容器镜像存在 BE 启动顺序问题，官方明确建议容器用户不要升级到 4.1.0，等 4.1.1 [StarRocks 4.1 发布说明](https://docs.starrocks.io/releasenotes/release-4.1/)；4.1.6 于 2026 年 9 月 30 日发布。第二是商业主体变化：CelerData 更名 PhoenixAI，并在 2026 年 6 月 11 日宣布 8000 万美元 B 轮，由 Sky9 Capital 领投 [8000 万美元 B 轮报道](https://siliconangle.com/2026/06/11/phoenixai-raises-80m-drive-development-agentic-ai-ready-database-technology/)。这不等于产品会消失，但路线、定价与支持主体都可能变，合同要写清控制权变更条款。技术上的两个坑也要提前知道：多表 join 很吃统计信息，统计不准时执行计划会退化；Shared-data 模式依赖对象存储与本地 cache，cache 命中率直接决定延迟。 两者之间怎么选？如果更新多、业务在中国、需要本地交付与信创适配，Doris 的默认路径更短；如果查询以多表 join、湖仓联邦为主，且团队能接受更复杂的 FE/BE/CN 运维，StarRocks 更合适。别用“谁更像 MySQL”来选，MySQL 协议兼容只降低接入成本，不改变执行模型。两家的商业版——SelectDB 与 PhoenixAI——公开页都没有单价，按云资源、BYOC 或订阅报价，采购时必须拿到书面区间；这也是它们与 ClickHouse Cloud 公开计价的一个差异。 把四种引擎放在一张表里，差异会更清楚。 | 维度 | ClickHouse | Doris | StarRocks | Druid | |---|---|---|---|---| | License | Apache 2.0 | Apache 2.0 | Apache 2.0 | Apache 2.0 | | 定位 | 不可变事件、日志、可观测性 | 更新型实时数仓 | 多表复杂分析、湖仓 | 时间序列预聚合 | | 写入 | 批量追加，强 | Stream/Routine Load，强 | Stream Load，强 | Kafka/Kinesis 原生 | | 更新/去重 | ReplacingMergeTree 最终去重，查询要 FINAL/argMax | Unique Key merge-on-write | Primary Key，部分列更新 | 弱，更新困难 | | 多表 join | 中，需避免大 join | 强 | 四者中最均衡 | 弱 | | 高并发/隔离 | 单表强，租户隔离要设计 | 强，计算组可隔离 | 强，shared-data 可弹性 | 强，但多进程运维重 | | 湖仓 | 中，外部表为主 | 强，4.x 补 Lakehouse | 强，多 Catalog | 中 | | 运维难度 | 高 | 中高 | 高 | 很高 | | 最适合 | 单表聚合、明细回查 | 更新多、中国生态 | join 多、湖仓 | 指标型看板、安全分析 | | 主要坑 | part 过多、join、语义层缺失 | 写入放大、compaction | 统计信息、cache 命中率 | rollup 固定维度、join 弱 | 这张表最重要的不是“谁更强”，而是“谁的强项和你的负载同形”。如果事件表只追加、查询以单表聚合为主、团队能接受 MergeTree 的运维模型，ClickHouse 的性价比最高；如果事件要频繁修正、用户属性要更新、漏斗要和订单表 join，Doris/StarRocks 的复杂度更低；Druid 只在“时间序列 + 预聚合 + 高并发”三者同时成立时值得保留。 关于 benchmark，本章只认两类标签：厂商自测，或第三方。Doris 的 5–10 倍、StarRocks 的“亚秒级”定位、ClickHouse 的单表扫描优势，基本都是厂商自测或厂商口径；第三方在同一数据集、同一查询集、同一并发下的复现，本次没有拿到（待核实）。更可靠的做法是拿自己的 7 天事件数据、自己的 20 条查询、自己的并发做 POC（概念验证），记录 p50/p95、CPU、磁盘、成本五组数字。POC 里必须包含三个坏查询：大漏斗、跨表 join、明细回查；只测 COUNT(*) 的 POC 参考价值有限。 > **判断**：ClickHouse 与 Doris/StarRocks 的差距，不在 10 亿行扫描快 20% 还是 30%，而在去重、更新、join、隔离这四件事上谁让你少写代码、少招人。 ## 7.4 Druid 与湖仓 **Druid 是四种引擎里最专用、也最容易被“实时 OLAP”这个词带进错误场景的一个。** 它为时间序列、预聚合和高并发设计，因此适合指标型看板，不适合做 UBA 的唯一明细引擎。 Druid 的组件比前三个都多：Coordinator 管 segment 分配，Overlord 管摄入任务，Broker 管查询路由，Router 做网关，Historical 提供本地缓存，MiddleManager/Peon 与 Indexer 负责摄入；数据以 segment 为单位放在 deep storage（S3/HDFS），元数据在 MySQL/PostgreSQL，协调依赖 ZooKeeper [Druid 架构文档](https://druid.apache.org/docs/latest/design/architecture/)。它的成本杠杆是 rollup：预聚合之后存储和查询都降，但维度组合被固定，临时下钻要回到原始数据；高基数维度会让 rollup 失效。 Druid 的分析能力偏“时间序列”：time-series、topN、groupBy 很强，SQL 与原生查询都能用，多表 join 弱，复杂明细查询不是它的设计目标。它仍在发版：36.0.0、37.0.0、38.0.0 分别在 2026 年 2 月 9 日、5 月 8 日、10 月 1 日发布 [Druid 官网](https://druid.apache.org/)，38.0.0 含 250+ 项改动 [Druid 38.0.0 发布说明](https://github.com/apache/druid/releases/tag/druid-38.0.0)。但商业重心已经转移：Imply 首页把自己描述为“agentic SIEM 的数据平台”，主推 Lumi 与 Polaris，而不是通用实时分析 [Imply 官网](https://imply.io/)；Polaris 的定价同样按用量或合同报价，公开单价未披露。这不代表 Druid 会停，但代表“买商业支持做通用 UBA”的确定性在下降。所以 Druid 的合理位置是“指标加速层”：把高频、固定维度的看板放进 rollup，把明细留在 OLAP 或湖仓。让它独自承担 UBA 的明细探索，等于用预聚合去回答一个随时会变的临时问题。 湖仓是另一条线，而 Iceberg 是最容易被误解的一个。它不是数据库，也不是查询引擎，而是开放表格式；解决的是“数据归谁、能不能被多引擎读、能不能回溯”，不解决亚秒级查询 [Iceberg 规范](https://iceberg.apache.org/spec/)。它用 snapshot、manifest、data file 三层元数据组织表，支持隐藏分区、schema 演进、时间旅行、branch/tag、REST Catalog，v3 规范加入删除向量与行级血缘；1.12.0 于 2026 年 9 月 30 日发布，V4 规范已在推进 [Iceberg 1.12.0 发布说明](https://github.com/apache/iceberg/releases/tag/apache-iceberg-1.12.0)。 生态在往标准化走。Apache Polaris 作为 Iceberg REST Catalog 已进入 ASF，支持 Doris、Flink、Spark、StarRocks、Trino 等多引擎 [Polaris 官网](https://polaris.apache.org/)；Databricks 在 2024 年宣布收购 Iceberg 创始团队公司 Tabular，加深对生态的影响 [Databricks 收购公告](https://www.databricks.com/company/newsroom/press-releases/databricks-agrees-acquire-tabular-company-founded-original-creators)。对 UBA 的含义是：事件真相层可以放在 Iceberg，serving 仍然要 OLAP。 但 Iceberg 的日常运维不轻。流式写入会不断产生小文件，manifest 也会膨胀；不合并的话，查询 planning 时间会超过扫描时间。另一个坑是 catalog：不同引擎对 REST/Glue/Hive/Nessie 的支持不一致，跨引擎写要做权限与提交冲突测试。事件表通常按 event_date、tenant_id 分区，按 event_time 排序；写入端要做小文件合并、快照过期、孤儿文件清理。选 Iceberg 之前先回答三个问题：谁负责 compaction，Catalog 用哪一个，哪些引擎需要写。三个问题没有答案，湖仓就会变成“能存不能查”的归档桶。 warehouse-native 指平台不搬走事件，只把指标计算下推到客户数仓。它的代价也不只是查询费。事件要先进对象存储，延迟从秒变分钟；每次查询都扫外部表，cold start 与 metadata planning 会吃掉体验；指标定义要跟 dbt/数仓版本走，产品侧改一个口径要发一次数据 PR。它把成本从存储转到计算和治理，但没有消灭成本。 > **判断**：Iceberg 是归档与复用的契约，不是 serving 层。把它当查询引擎用，最后会在延迟和 metadata planning 上付出代价。 ## 7.5 Kafka / Flink **Kafka 和 Flink 是自建栈里最容易被“顺便装上”的两个组件，也是最容易把固定成本抬高的两个。** 它们解决的是“事件怎么流、怎么带状态算”，不是“事件怎么被查询”。 Kafka 是分布式事件流平台，做事件总线和可回放日志，不是分析数据库。4.0.0 于 2025 年 3 月 18 日发布，是第一个完全运行在 KRaft 模式的主版本，同时 GA 了 KIP-848 消费组协议、预览了 KIP-932 队列语义 [Kafka 4.0 公告](https://kafka.apache.org/blog/2025/03/18/apache-kafka-4.0.0-release-announcement/)。此后 4.1.0（2025-09-02）、4.2.0（2026-02-17）、4.3.0（2026-05-22）、4.3.1（2026-06-25）基本按每年三个版本的节奏推进 [Kafka 下载页](https://kafka.apache.org/community/downloads/)。 容量估算的顺序是先算日字节与峰值倍数，再按目标单分区吞吐反推分区数，最后定副本与保留。分区不是越多越好：Controller 元数据、rebalance、文件句柄都会随分区数上升。Tiered Storage 可以把冷数据移到对象存储，降低本地盘成本，但跨区流量仍然按 GB 计费。对多数 UBA，Kafka 的价值是“多下游、可重放、削峰”，不是“更快”；如果只有一个下游、没有重放需求，直接写 OLAP 或对象存储会更简单。 Kafka 的 exactly-once 经常被误读。KIP-98 提供的是幂等生产者加事务：生产者可以跨多个 TopicPartition 原子写，消费者用 read_committed 只读已提交消息 [KIP-98](https://cwiki.apache.org/confluence/spaces/KAFKA/pages/66854913/KIP-98+-+Exactly+Once+Delivery+and+Transactional+Messaging)。这只保证 Kafka 内部的读写；如果 sink 是 ClickHouse、MySQL 或 S3，仍要靠两阶段提交、幂等 upsert 或去重键。 Flink 是有状态流处理引擎，做实时 ETL、会话化、去重、CEP（复杂事件处理）和实时告警。它的事件时间与 Watermark、窗口、Keyed State、Checkpoint、Savepoint、RocksDB/ForSt 状态后端，都是为“状态一致性”服务的 [Checkpoint 文档](https://nightlies.apache.org/flink/flink-docs-stable/docs/ops/state/checkpoints/)。当前主线是 2.x，稳定版 2.3.0，1.20.5 仍是 LTS；Flink CDC 3.7.0 于 2026 年 10 月 10 日发布，加入可插拔模型 API 与 OpenAI 兼容接口 [Flink 官网](https://flink.apache.org/)。 端到端 exactly-once 同样不能想当然。Flink 能保证“状态更新 exactly-once”，但端到端需要 source 参与快照、sink 参与 checkpoint。官方表格写得很清楚：Kafka producer 在事务模式下可以 exactly-once，Elasticsearch/OpenSearch sink 只有 at-least-once [连接器一致性说明](https://nightlies.apache.org/flink/flink-docs-stable/docs/connectors/datastream/guarantees/)。所以“上 Flink 就有 exactly-once”是错的，必须端到端设计。 Flink 的隐性成本在状态。RocksDB 状态越大，checkpoint 越久，恢复越慢；要把状态按 key 设计、设 TTL、避免全量窗口。另一个判断标准是状态规模：会话化与去重需要按用户 key 保存状态，状态越大，checkpoint 与恢复越贵；如果只是窗口聚合，很多工作可以在 OLAP 的物化视图里完成。Checkpoint 存 HDFS/S3，Savepoint 用于升级与回滚，两者不要混用。人才也稀缺：能调大状态、checkpoint 和反压的人，比会写 SQL 的人少得多。 > **判断**：如果业务能接受 1–5 分钟延迟，CDC（变更数据捕获）加 OLAP 微批通常比 Kafka + Flink 便宜一个数量级；只有“会话超时 30 分钟要实时切分”“欺诈要在秒级拦截”“多流 join 不能等批”这类需求，才值得上 Flink。 ## 7.6 BI 与语义层 **Superset、Metabase、Grafana 都不解决指标口径。** 它们是指标消费端；口径在事件 taxonomy、dbt/数仓模型或自建语义层里。把这个顺序搞反，最后会得到四个看板里的四个“活跃用户”。 | 工具 | 定位 | 语义层强度 | 计价锚点 | 适合 | |---|---|---|---|---| | Superset | SQL-first BI | 弱–中 | 免费/托管报价 | 内部报表、数据团队 | | Metabase | 易用 BI/嵌入 | 中 | 100/575 美元/月起 | 业务自助、SaaS 嵌入 | | Grafana | 可观测性 | 弱 | 免费/Cloud | 监控、日志、SLO | | GrowthBook | 实验平台 | 中（数仓指标） | 40 美元/席位/月起 | 增长实验 | GrowthBook 不是 BI，把它放进这张表，是因为它和 BI 消费同一套数仓指标，也最容易被误当成“分析平台”。Grafana 则是另一种边界：AGPL-3.0，13.2.4 于 2026 年 10 月 13 日发布，适合看 pipeline、日志与 SLO，不适合业务漏斗 [Grafana 仓库](https://github.com/grafana/grafana)。 Superset 是 Apache 项目，SQL Lab、Dataset、Chart、Dashboard、Alert/Report、行级安全、缓存和 40+ 可视化类型都有 [Superset 官网](https://superset.apache.org/)；6.1.0 于 2026 年 5 月 13 日发布 [Superset 6.1.0 发布说明](https://github.com/apache/superset/releases/tag/6.1.0)。它的语义层是“数据集 + 指标”的轻量实现，不是集中治理的指标层；漏斗、留存、路径没有专用界面，需要写 SQL 或接外部工具。它适合做内部看板层，不适合当 UBA 产品。 Metabase 核心是 AGPL，enterprise 目录为商业许可；自建改造要遵守 AGPL 的网络使用条款，闭源嵌入需商业授权 [Metabase 仓库](https://github.com/metabase/metabase)。它的查询构建器、原生 SQL、Dashboard、Model、Metric、Metabot、Embedding SDK 对业务用户更友好；64.1 于 2026 年 10 月 7 日发布。定价是 Starter 100 美元/月（年付 90 美元/月），Pro 575 美元/月（年付 517.50 美元/月），Enterprise 起价 20,000 美元/年；超出包含用户数后 12 美元/用户/月，AI 服务 3.75 美元/百万 token [Metabase 定价](https://www.metabase.com/pricing)。它的 Model 与 Metric 也只是轻量语义层，跨团队强制治理仍然缺位。 GrowthBook 核心 MIT，enterprise 目录为商业许可，属于 open core [GrowthBook 仓库](https://github.com/growthbook/growthbook)。它是 warehouse-native 的实验平台与功能开关，不做事件采集与存储，只读数仓里的曝光与指标；Pro 40 美元/席位/月（最多 30 用户），Managed Warehouse 有 100 万事件/月的免费额度，2M 之后按 30 美元/百万计 [GrowthBook 定价](https://www.growthbook.io/pricing)。5.1.0 于 2026 年 9 月 22 日发布，加入上下文老虎机（beta）、漏斗指标、托管 MCP 与 OAuth [GrowthBook 5.1.0 发布说明](https://github.com/growthbook/growthbook/releases/tag/v5.1.0)。它是实验工具，不是通用 UBA。 语义层通常有三种落法：数仓里的宽表/汇总表，最简单但复用差；dbt/指标层，定义集中但需要工程化；自研指标服务，最灵活但成本最高。UBA 的指标比 BI 指标更复杂：同一个“活跃用户”要区分设备、账号、合并身份，还要区分自然日、滚动 7 天、滚动 30 天。把这些口径写进代码而不是文档，才有机会统一。语义层也不是买一个工具就能解决：需要有人对指标命名、口径、维度、权限负责；否则 Superset 的 Dataset、Metabase 的 Model、GrowthBook 的 Metric 只会把同一套混乱复制三遍。 > **判断**：如果 UBA 要可复用，指标定义必须先进数仓或语义层，再被 BI 和实验工具消费，而不是反过来。 ## 7.7 三套参考栈 **下面三套栈是“能跑起来”的配置，不是报价单。** 它们的作用是让你在立项时把组件、人力、月成本放在同一张纸上，而不是先买一个引擎再补周边。 | 栈 | 事件量假设 | 组件 | 人力 | 月成本假设 | 适用 | |---|---|---|---|---|---| | 轻量 | <5,000 万/日，保留 30–90 天 | ClickHouse Cloud Basic 或单集群 Doris；无 Kafka/Flink；Metabase 或 Superset；GrowthBook Cloud | 0.5–1 人 | 1,000–5,000 美元 | MVP、单产品、少量租户 | | 标准 | 1–10 亿/日，保留 6–12 个月 | Kafka 3 broker + Tiered Storage；Flink 会话化/去重；ClickHouse/Doris/StarRocks 集群；Iceberg 归档；Superset；GrowthBook | 3–6 人 | 1.5 万–5 万美元 | 中型 UBA、多业务线 | | 超大规模 | >50 亿/日，保留 1–3 年 | Kafka 多集群 + MirrorMaker；Flink 多集群；OLAP 多集群/多计算组；Iceberg + Polaris/Unity；Trino/Spark；自研前端 | 10–20 人 | 10 万美元以上 | 大型平台、多租户 SaaS | 三套成本都是假设，不是厂商报价。轻量栈按 ClickHouse Cloud Basic 的存储 25.30 美元/TB/月、计算 0.2181 美元/unit/小时估算；标准栈按 3 副本 Kafka、3 节点 OLAP、对象存储与 Flink 常驻集群估算；超大规模栈不含自研前端的人力。实际价格受区域、折扣、保留时长、查询并发影响，必须用云厂商估算器复核。 轻量栈刻意不上 Kafka/Flink。这个量级下，直接写入或每小时微批足够；Kafka 的 3 副本和 Flink 的常驻 slot 会把固定成本抬高。标准栈上 Flink 的前提是会话化、去重、实时告警至少有一个是硬需求；如果只是看板刷新，用 OLAP 的 Routine Load 或物化视图更简单。 标准栈加 Iceberg 不是为了“更先进”，而是为了两件事：原始事件留一份可回溯的真相，以及让 Trino/Spark/StarRocks 这些引擎不必各自存一份。代价是 compaction 与 Catalog 运维。超大规模栈的分水岭不是事件量，而是租户数量与合规要求。 超大规模栈之所以要多集群，也不是因为单集群跑不动，而是因为故障域和租户隔离：一个租户的脏查询、一次回填、一个版本的回归，都不应该影响全部客户。 一个反证是：连“一体化产品”也没有逃开这套组合。PostHog 的公开架构是 Django 负责 Web/API、Rust 服务负责 capture/flags/replay、Kafka（云上用 WarpStream）做总线、ClickHouse 存事件与分析、Aurora PostgreSQL 存元数据、Redis/Valkey 做缓存、S3 存放回放与导出 [PostHog 架构文档](https://posthog.com/docs/how-posthog-works)。Plausible 的社区版要同时维护 PostgreSQL 与 ClickHouse [Plausible 仓库](https://github.com/plausible/analytics)；Umami 用 PostgreSQL 单库，适合轻量场景 [Umami 仓库](https://github.com/umami-software/umami)。所谓“开箱即用”，只是把选型与运维藏在了产品后面。 **三套栈的分界线不是事件量本身，而是你是否需要为实时性、租户隔离和合规单独付费。** 轻量栈上 Kafka+Flink，通常是把钱花在不需要的地方。 ## 7.8 成本模型与运维 **自建栈的账，先算存储，再算查询，最后算人力；多数立项材料只算第一项。** 这不是财务细节，而是选型结论的分水岭：同样的事件量，存储可能只占账单的一小半，人力才是长期项。 存储公式： ``` 存储 TB = 日事件数 × 单条字节 × 压缩后比例 × 副本数 × 保留天数 ÷ 10^12 ``` 其中“压缩后比例”指压缩后大小 ÷ 原始大小。举例：10 亿条/日 × 1 KB/条 = 1 TB/日原始数据；按 8 倍压缩 = 125 GB/日；3 副本 = 375 GB/日；保留 365 天 = 136.9 TB。按 ClickHouse Cloud 存储 25.30 美元/TB/月，约 3,464 美元/月 [ClickHouse 定价页](https://clickhouse.com/pricing)。这还没算查询计算、出流量、备份和 compaction。 查询成本有两种算法： ``` 查询成本 ≈ 日查询数 × 平均扫描 GB × 每 GB 扫描单价 或 ≈ 平均并发 × 单查询 CPU 秒 × 核时单价 ``` 按扫描计价的引擎用前者，按资源计价的引擎用后者。ClickHouse Cloud 的计价单位是 compute unit，Scale 档 0.2985 美元/unit/小时 [ClickHouse 定价页](https://clickhouse.com/pricing)；如果按 8 个 unit 常驻估算，约 1,744 美元/月，但 unit 与 vCPU/内存的换算要以官方估算器为准，不能直接当 vCPU 用。 Kafka 的存储是“日字节 × 副本数 × 保留天数”，Tiered Storage 可以把冷数据移到对象存储；Flink 的成本主要是常驻 slot、状态大小与 checkpoint 存储；Iceberg 的成本主要是对象存储请求、元数据与 compaction。**真正的隐性成本是人力**：一个能调 ClickHouse part/merge、Flink checkpoint、Kafka ISR（副本同步状态）的工程师，在中国市场年薪约 40–80 万元，在美国约 15–25 万美元（估算，非官方数据）。 把三项放在一起，3 年 TCO 可以写成：`3 年 TCO ≈ 月基础设施 × 36 + 人力年成本 × 3 + 一次性迁移与双跑成本`。以标准栈为例：月基础设施 5 万美元 × 36 = 180 万美元；4 名工程师 × 15 万美元/年（美国口径下限，估算）× 3 = 180 万美元；合计约 360 万美元，云资源与人力各占一半。换成中国团队，绝对值下降，但人力仍是不能省的那一半。 > **判断**：自建栈的 3 年 TCO 里，软件许可通常是 0，云资源占 30–50%，人力占 30–50%（估算）。只算服务器价格的自建方案，通常会低估 2–3 倍。 多租户是运维里最容易欠债的部分。常见做法有三种：共享表加 tenant_id，成本最低、隔离最弱；共享集群加独立数据库或计算组，折中；独立集群，隔离最好、成本最高。UBA 的租户差异大，建议按租户分层：大客户独立计算组，小客户共享池；查询队列按租户配额；行级权限在查询引擎或语义层做，不要只在前端过滤。资源组、查询超时、并发上限三件套必须同时有，否则一个租户的脏查询就能拖垮全站。 保留与删除要按事件类型分层：原始事件 90–180 天，聚合结果 2–3 年，用户级明细按合规要求删除。GDPR 的删除请求要能定位到 user_id 并传播到 Kafka、OLAP、Iceberg、备份；只删 OLAP 不够。审计日志本身也要保留，否则无法证明删除发生过。 数据质量的三个源头通常不在引擎：SDK 版本不一致导致字段缺失、身份合并把两个人并成一个、时区/时间戳把事件放到错误的分区。前两个要在采集与身份层解决，第三个要在建表时统一 UTC 并保留原始时区。任何 OLAP 都不能替你修这些问题。 降本手段按性价比排序：先做 TTL 与冷热分层，再做预聚合与列裁剪，最后才考虑换引擎。换引擎的迁移成本，通常高于一年的存储差价。 七个失败模式值得贴在墙上： - **part 太多**：小批量高频写入让合并跟不上，查询变慢。 - **查询时去重**：每次 FINAL 或 COUNT(DISTINCT)，CPU 翻倍。 - **多租户共用一套资源**：大租户全表扫描，小租户全部超时。 - **回填打爆线上**：历史重跑和实时写入抢 CPU。 - **schema 漂移**：属性类型变化导致物化视图失效。 - **没有语义层**：同一个指标在四个看板里有四个数。 - **过度流式**：为了“实时”上 Flink，结果 90% 的查询是 T+1。 ## 7.9 选型清单 **把前面的内容压成一张可执行的清单：先排除，再按约束排序，最后用 POC 验证三个坏查询。** 不要从“哪个引擎最强”开始，从“哪类负载不该用哪个引擎”开始。 | 场景 | 首选 | 备选 | 主要理由 | |---|---|---|---| | 事件只追加、单表聚合为主、有 OLAP 运维 | ClickHouse + 自研前端 | ClickHouse Cloud/BYOC | 单表性价比高，join/更新/语义层要自己补 | | 事件要修正、用户属性常更新、要和订单表 join | Doris/StarRocks | SelectDB/PhoenixAI 商业版 | 更新与 join 自然，SQL 兼容，代价是运维与商业绑定 | | 数据不能出仓、要长期保留、多引擎复用 | Iceberg + Trino/StarRocks | Hudi/Delta | 开放与归档成本低，但不是 serving 层 | | 已有数仓、实验为主、不想养管道 | warehouse-native（Snowflake/BigQuery + GrowthBook） | 托管 ClickHouse | 上线快，成本随查询增长 | | 日增 <5,000 万、团队 <3 人 | 托管/SaaS | 轻量 ClickHouse Cloud | 自建现金成本通常更高 | 前四条路线的共同点是：都把 OLAP 当执行引擎，把事件模型当产品。区别只在数据放在哪、谁负责运维、指标定义归谁；最后一行不是技术路线，而是规模阈值。 落地前用十个问题做排除： 1. 峰值/日均事件量、单条字节、迟到比例、重复比例各是多少？ 2. 查询以单表聚合、明细回查、多表 join 哪类为主？p95 延迟目标是多少？ 3. 是否需要行级更新/删除？RBAC（基于角色的访问控制）、列级脱敏与审计能否满足合规？ 4. 租户数量与最大租户占比？是否需要独立计算组？ 5. 端到端 exactly-once 是否硬要求？sink 有哪些？ 6. 回填窗口多长？能否在不影响线上查询的情况下重跑 90 天？ 7. 部署形态：公有云、私有化、BYOC、信创？数据能否出境？ 8. 团队是否具备 Java/C++/K8s/on-call 能力？谁值夜班？ 9. 3 年 TCO：存储、计算、出流量、支持、人力各多少？ 10. 版本升级节奏与回滚方案？最近一次破坏性变更是什么？ 90 天路线可以压成四段。第 1–2 周定事件 taxonomy、身份规则、会话规则、10 个核心指标，先写“指标字典”，不管引擎。第 3–4 周搭最小管道，建事件表与 7 天回填，用 1% 流量验证去重与迟到。第 5–8 周实现事件分析、漏斗、留存、路径四条查询，把常用查询做成物化视图或预聚合，压测 50 并发。第 9–12 周接 Superset/Metabase 做内部看板，接 GrowthBook 做实验，补权限、审计、监控、备份、成本看板，写 runbook。 三个不要：不要用厂商 benchmark 当 SLA；不要在没有指标字典时上 AI NLQ（自然语言查询），错误答案会更快；不要把所有租户、所有查询放在一个集群里。 POC 的设计比 POC 的结论重要。拿自己的 7 天事件数据、自己的 20 条查询、自己的并发，记录 p50/p95、CPU、磁盘、成本；必须包含大漏斗、跨表 join、明细回查三个坏查询。只测 COUNT(*) 的 POC，换来的只是一个会骗人的数字。 采购与自建的决策线可以写得很硬：团队少于 3 个数据工程师、事件量小于 5,000 万/日、没有强合规要求，优先托管或 SaaS；有 5 人以上平台团队、事件量过亿、数据不能出网，再考虑自建。自建不是省钱，是用人力换控制权；把这句话写进立项材料，能避免一半的失败项目。 ## 参考来源 - [ClickHouse Pricing](https://clickhouse.com/pricing) - [ClickHouse GitHub Repository](https://github.com/ClickHouse/ClickHouse) - [ClickHouse MergeTree 文档](https://clickhouse.com/docs/reference/engines/table-engines/mergetree-family/mergetree) - [ClickHouse acquires HyperDX（2025-03-13）](https://clickhouse.com/blog/clickhouse-acquires-hyperdx-the-future-of-open-source-observability) - [Langfuse joins ClickHouse（2026-01-16）](https://python-sdk-v3.docs-snapshot.langfuse.com/blog/joining-clickhouse/) - [ClickHouse ARR passes $350M（Dealroom，2026-08-25）](https://dealroom.co/news/146838-clickhouse-arr-passes-350m-as-ai-agents-fuel-database-demand/) - [ClickHouse release 26.9（2026-09-23）](https://clickhouse.com/blog/clickhouse-release-26-09) - [ClickHouse Tops $250M ARR（BusinessWire，页面无法访问，待核实）](https://www.businesswire.com/news/home/20260527813115/en/ClickHouse-Tops-%24250M-ARR-and-4000-Customers-Launches-Claude-Powered-Agents-at-Open-House-2026) - [Apache Doris 官网](https://doris.apache.org/) - [Apache Doris 4.x Overview](https://doris.apache.org/docs/4.x/getting-started/what-is-apache-doris/) - [Apache Doris Release Notes](https://doris.apache.org/releases/core/) - [Apache Doris 4.0.0 Release](https://doris.apache.org/releases/v4.0/release-4.0.0/) - [SelectDB Enterprise 介绍](https://docs.selectdb.com/enterprise/4.x/getting-started/selectdb-enterprise-overview) - [Apache Doris GitHub Repository](https://github.com/apache/doris) - [StarRocks 官网](https://www.starrocks.io/) - [StarRocks 4.1 Release Notes](https://docs.starrocks.io/releasenotes/release-4.1/) - [StarRocks LICENSE](https://github.com/StarRocks/starrocks/blob/main/LICENSE.txt) - [CelerData Rebrands as PhoenixAI（DBTA，2026-05-27）](https://www.dbta.com/Editorial/News-Flashes/CelerData-Rebrands-as-PhoenixAI-Introduces-Analytical-Engine-Designed-for-AI-Agents-174972.aspx) - [PhoenixAI raises $80M（SiliconANGLE，2026-06-11）](https://siliconangle.com/2026/06/11/phoenixai-raises-80m-drive-development-agentic-ai-ready-database-technology/) - [Apache Druid 官网](https://druid.apache.org/) - [Apache Druid Architecture](https://druid.apache.org/docs/latest/design/architecture/) - [Apache Druid 38.0.0 Release](https://github.com/apache/druid/releases/tag/druid-38.0.0) - [Imply 官网](https://imply.io/) - [Apache Kafka 4.0.0 Release Announcement](https://kafka.apache.org/blog/2025/03/18/apache-kafka-4.0.0-release-announcement/) - [Apache Kafka Downloads](https://kafka.apache.org/community/downloads/) - [KIP-98: Exactly Once Delivery and Transactional Messaging](https://cwiki.apache.org/confluence/spaces/KAFKA/pages/66854913/KIP-98+-+Exactly+Once+Delivery+and+Transactional+Messaging) - [Apache Flink 官网](https://flink.apache.org/) - [Flink Fault Tolerance Guarantees](https://nightlies.apache.org/flink/flink-docs-stable/docs/connectors/datastream/guarantees/) - [Flink Checkpoints](https://nightlies.apache.org/flink/flink-docs-stable/docs/ops/state/checkpoints/) - [Apache Iceberg 1.12.0 Release](https://github.com/apache/iceberg/releases/tag/apache-iceberg-1.12.0) - [Apache Iceberg Specification](https://iceberg.apache.org/spec/) - [Apache Polaris 官网](https://polaris.apache.org/) - [Databricks to Acquire Tabular](https://www.databricks.com/company/newsroom/press-releases/databricks-agrees-acquire-tabular-company-founded-original-creators) - [Apache Superset 官网](https://superset.apache.org/) - [Apache Superset 6.1.0 Release](https://github.com/apache/superset/releases/tag/6.1.0) - [Metabase Pricing](https://www.metabase.com/pricing) - [Metabase GitHub Repository](https://github.com/metabase/metabase) - [GrowthBook Pricing](https://www.growthbook.io/pricing) - [GrowthBook GitHub Repository](https://github.com/growthbook/growthbook) - [GrowthBook 5.1.0 Release](https://github.com/growthbook/growthbook/releases/tag/v5.1.0) - [Grafana GitHub Repository](https://github.com/grafana/grafana) - [PostHog 架构文档](https://posthog.com/docs/how-posthog-works) - [Plausible GitHub Repository](https://github.com/plausible/analytics) - [Umami GitHub Repository](https://github.com/umami-software/umami) --- # 08 · 核心模块（上）：事件、身份与会话，才是平台的地基 > 一条事件要过七道关口，每一道都在改写它。平台真正的资产不是 SDK 和图表，而是可解释的事件契约与可审计的身份图谱。 **先给判断：埋点平台 80% 的长期成本，不在 SDK、存储和图表的报价单上，而在事件被定义之前、身份被合并之后。** SDK 可以换，引擎可以换，图表可以重画；事件叫什么、属性是什么类型、两个 ID 该不该合并、一次使用从哪里算起，这四件事一旦上线，就会成为所有漏斗、留存、人群和实验的隐含前提。 先做一道算术题。同一批事件，按 `device_id` 去重、按 `user_id` 去重、按付费账户去重，会得到三个不同的日活，而且每个都能自圆其说。埋点平台的大部分争议不是“采集失败”，而是三个定义被当成了一个。 本章沿一条事件的实际路径走：它怎样被发出、被命名、被合并、被切分会话、被验收、被同意约束，最后落到十条能写进研发流程的规范。 ## 8.1 一次事件的完整旅程 一条事件从用户手指落下到出现在看板上，要穿过七道关口，每一道都在改写它。 ![图 8-1 · 一次事件的七个关口](/assets/diagrams/event-lifecycle.svg) 图 8-1 把七道关口从左到右排开，并在每道关口下标出最常见的失败。它想说明的不是“链路很长”，而是：**没有任何一道关口能独立保证语义正确，语义是在传递中被逐步改写的。** 采集端丢了一个属性，接入端补了一个默认值，加工端又把时区当成 UTC，最后看板上的“昨天”已经不是用户经历的“昨天”。 | 关口 | 这一关做什么 | 最典型的失败 | 该看的指标 | 谁负责 | |---|---|---|---|---| | 01 SDK 采集 | 生成 `event_id`、补上下文、读同意状态、排队重试 | 漏埋、重复、PII 误采 | 发送成功率、SDK 版本分布 | 客户端 / 前端 | | 02 Collector 接入 | 鉴权、限流、解压、schema 初检、bot 过滤 | 返回 200 但没入库；流量峰值被打挂 | 2xx 率、p95、拒收率 | 平台 / SRE | | 03 队列缓冲 | 削峰、解耦、保留可回放 | 热点分区、积压、保留期太短 | consumer lag、分区吞吐 | 数据平台 | | 04 加工 | enrichment、身份合并、会话切分、去重 | 迟到数据改历史、合并不可逆 | checkpoint、状态大小、迟到 P95 | 数据工程 | | 05 建模 | 事件表、用户表、会话表、维度与指标 | 同名不同义、指标定义打架 | 口径变更记录、plan 覆盖率 | 数据治理 | | 06 存储 | 分区、副本、TTL、冷热分层 | part 过多、合并落后、删除不彻底 | 扫描字节、part 数、删除时长 | 数据平台 | | 07 查询与行动 | 漏斗、留存、人群、实验、告警 | 查询慢被绕过、洞察无法行动 | 查询 p95、采用率、行动转化 | 分析 / 产品 | 治理不在这条链路的某一层，它横切每一层：同意在 SDK 生效，schema 在接入与加工校验，审计在存储与查询留痕。把治理留到“最后再加”的项目，最后都要重跑历史。 **四个时间戳，别只留一个。** Snowplow 把一条事件的时间拆开：设备产生 `dvce_created_tstamp`、设备发出 `dvce_sent_tstamp`、Collector 接收 `collector_tstamp`、落库 `load_tstamp`，并明确“迟到”至少有两种——离线导致的 late sent，和批处理/管道导致的 late loaded（[Snowplow 迟到数据](https://docs.snowplow.io/docs/modeling-your-data/modeling-your-data-with-dbt/package-mechanics/late-arriving-data/)）。只保留一个时间戳的团队，第一次补数就会开始争论“昨天的报表为什么变了”：因为“昨天”指的是设备时间、接收时间还是落库时间，从来没有被定义过。 **接入层应该只做三件事：认人、验形、落盘。** 认人是 write key 与域名白名单；验形是 schema 版本、必填字段、属性类型与大小上限；落盘是批量写队列，成功返回 202，失败返回可重试的 429 或 503。这里有一个廉价但致命的错误：重试时在 Collector 里重新生成 `event_id`，于是每一次重试都变成一条新事件，重复率随网络质量一起上升。幂等键必须由客户端生成，并贯穿所有重试。Snowplow 把链路拆成 Collect → Validate → Enrich，坏事件进 bad stream，而不是让 Collector 做业务判断（[Snowplow 管道](https://docs.snowplow.io/docs/pipeline/)）。 **客户端不保证送达。** Segment 的 analytics.js 最多缓存 100 个事件，页面关闭时用 `keepalive` 刷队列，而 keepalive 的载荷上限是 64 KB，队列超过这个体积就可能丢一部分（[analytics.js](https://www.twilio.com/docs/segment/connections/sources/catalog/libraries/website/javascript)）。所以“采集成功率”不是 SDK 的宣传指标，而是要在接入层用接收量除以发送量、按小时对账的运维指标。 > **判断**：事件时间、接收时间、落库时间是三个不同的真相。只留一个，迟到、乱序、补数、会话重算都会变成无法解释的报表差异；留了三个却不定义哪个用于报表，只是把争论从“数据不准”升级为“口径不同”。 ## 8.2 埋点方式与取舍 **覆盖率与语义质量成反比，这是埋点方式的第一性事实。** 越自动，越容易收到一堆没有业务含义的点击；越手动，越容易漏掉没被想到的路径。选型不是选“最好的一种”，而是选一组配比。 | 方式 | 覆盖率 | 语义质量 | 前期成本 | 长期成本 | 典型风险 | |---|---|---|---|---|---| | 手动埋点 | 低—中 | 高 | 中 | 中，随版本漂移 | 漏埋、命名不一致、发版后失效 | | 全埋点（autocapture） | 高 | 低—中 | 低 | 高，属性爆炸与清洗 | 把 UI 结构当语义、误采隐私 | | 可视化圈选 | 中 | 中 | 低 | 中，页面改版即失效 | 选择器脆弱、跨端不一致 | | 服务端埋点 | 取决于业务系统 | 高，字段可信 | 高 | 低—中 | 缺客户端上下文、覆盖不到匿名浏览 | | 日志 / 数仓导入 | 历史全量 | 取决于源系统 | 高 | 高，schema 对齐 | 没有身份、时间语义错、重复 | PostHog 是“高覆盖”的极端样本：全埋点覆盖交互、导航、剪贴板、热图、无效点击、异常、回放、Web Vitals 和生命周期，Web 与 React 默认开启（[PostHog Autocapture](https://posthog.com/docs/data/autocapture)）。这解释了它为什么接得快，也解释了它为什么必须配套屏蔽、遮罩与事件定义治理——自动采集把“要不要收”这个决定推迟到了事后，而事后只能靠删除。 服务端采集则是另一套逻辑。GA4 的 Measurement Protocol 明确“补充而非替代”自动采集：没有 gtag、GTM 或 Firebase 打底，服务端事件无法建立完整的 session 上下文（[GA4 Measurement Protocol](https://developers.google.com/analytics/devguides/collection/protocol/ga4)）。Segment 的 HTTP API 可以把服务端当成第一来源。两者经常被混为一谈，实际含义不同：一个是“补客户端看不见的事实”，一个是“服务端就是主链路”。 一个电商站的最小组合通常长这样：客户端发页面、曝光、加购、结算开始，服务端发支付成功、退款、金额与优惠券核销。客户端负责“用户走到了哪一步”，服务端负责“这笔交易到底成没成”。把金额交给客户端，等于把对账交给了一个可以被改写的环境。 ## 8.3 事件 taxonomy 与 tracking plan **命名规范是最没有技术含量、也最容易被跳过的一节，但它决定了半年后一个新同学能不能不问人就把查询写对。** tracking plan 不是事件清单，它至少要回答四件事：谁在什么条件下发、带哪些属性、属性是什么类型、坏了谁负责。 Segment 的规范很具体：事件名用 Title Case，属性名用 snake_case，事件名采用 Object + Action（如 `Order Completed`）；不要动态生成事件名，不要把值塞进事件名，也不要生成 `feature_1`、`feature_2` 这类属性键（[Segment 最佳实践](https://www.twilio.com/docs/segment/protocols/tracking-plan/best-practices)）。GA4 走另一套：事件名只能字母开头、只含字母数字与下划线、最长 40 字符；每个事件最多 25 个参数，参数值最长 100 字符；用户属性最多 25 个，推荐事件用 `sign_up`、`add_to_cart` 这类 snake_case（[GA4 命名规则](https://support.google.com/analytics/answer/13316687?hl=en)、[GA4 采集上限](https://support.google.com/analytics/answer/9267744?hl=en)）。 两套规范都合理，混用会出事。同一家公司 Web 用 GA4、App 用 Segment，于是 `Add To Cart` 和 `add_to_cart` 同时存在；BI 层要么大小写折叠，把两个语义不同的事件合成一个，要么接受双份。跨国团队最常见的返工不是缺事件，而是同一个事件有两个名字。 | 对象 | 推荐写法 | 常见反例 | 代价 | |---|---|---|---| | 事件名 | `checkout_completed` 或 `Checkout Completed`，全站统一 | `click_btn_1`、`checkout_v2_final` | 事件名变成版本号，半年后没人敢删 | | 属性名 | `payment_method`、`order_id` | `payType`、`paymentMethod`、`pay_type` | 同一含义三种拼写，漏斗要写三段 OR | | 枚举值 | `apple_pay`、`wechat`，词表固定 | `ApplePay`、`applepay`、`AP` | 分组时漏掉一批订单，且不易发现 | | 动态键 | `coupon_code` 一个属性 | `coupon_1`、`coupon_2`、`coupon_3` | 属性爆炸，无法聚合，只能逐个写 SQL | 一份可执行的 schema 大致长这样： ```yaml event: checkout_completed # object_action，snake_case version: 2 owner: growth-checkout status: active # active | deprecated | experimental properties: order_id: {type: string, required: true, format: uuid} payment_method: {type: enum, required: true, values: [card, apple_pay, wechat]} item_count: {type: integer, required: true, min: 1} coupon_code: {type: string, required: false, maxLength: 32} ``` 这段 YAML 不难写，难的是改动管理。Segment 用 `context.protocols.event_version` 让新旧 App 版本并行校验（[Segment 版本](https://www.twilio.com/docs/segment/protocols/tracking-plan/create)）；Snowplow 把 schema 变更分成 major、minor、patch，而且同一个“必填改可选”，在 Redshift 是 breaking，在 Snowflake、BigQuery、Databricks 却不是（[Snowplow 版本规则](https://docs.snowplow.io/docs/event-studio/data-structures/versioning/)）。同一个动作，在不同数仓上的风险等级不同，这件事必须在评审时说出来。 工具层已经把 plan 产品化了，只是路径不同。Avo 把 plan 的分支、审批、codegen 与 Inspector 串起来：Inspector 采集线上事件形状与 plan 对比，按 issue 分类；免费版 2 个 editor、10 万 Inspector events，Team 250 美元/月（年付），加 editor 50 美元/月（[Avo 文档](https://www.avo.app/docs/implementation/devs-101)、[Avo 定价](https://www.avo.app/pricing)）。Mixpanel 的 Data Standards 把命名、描述、owner 做成可评分的合规状态，但只在 Enterprise 提供；Amplitude 的 tracking plan 支持必填、类型、正则和属性组（[Mixpanel Data Standards](https://docs.mixpanel.com/docs/data-governance/data-standards)、[Amplitude Tracking Plan](https://amplitude.com/docs/data/create-tracking-plan)）。它们的共同前提是：有人愿意为“事件定义”签字。没有这个前提，工具只是把 Excel 换成了更贵的 Excel。 > **判断**：tracking plan 不是文档，是跨团队契约。它必须和代码一起进版本库、和发版一起评审、和报表口径一起归档；否则它只会变成一张过期的表，而且是所有人都引用、没人负责的那张。 ## 8.4 属性、版本与数据契约 **属性设计的第一原则不是“多收一点以后有用”，而是“每个属性都能回答一个具体问题”。** 收进来的每个字段都要付三次钱：传输、存储，以及未来每一个要理解它的人。 几个不写进规范就一定会出错的点：金额用整数分或 decimal，不用浮点；时间统一 UTC，另存时区字段；枚举用受控词表，未知值进 `unknown` 而不是自由文本；布尔不要出现 `Y`、`N`、`1`、`true` 四种写法；PII 在 plan 里显式标注，不藏在自由文本里。属性还会自我膨胀：一张事件表打平 200 个属性，扫描字节会翻倍，长尾属性应该进 JSON 或 Map，按需取。这不是存储问题，是查询成本问题——每一次全表扫描都在为“以后可能有用”付费。 更正式的做法是数据契约。Open Data Contract Standard 把 schema、质量规则、SLA、owner、服务级别写进 YAML，作为 plan 与管道之间的中间层（[ODCS](https://bitol-io.github.io/open-data-contract-standard/latest/)）。它的价值不在 YAML 本身，而在它迫使数据生产方与消费方在同一张纸上写下：什么算坏、坏了谁负责、多久修好。 | 变更 | 版本位 | 历史查询会怎样 | 处理方式 | |---|---|---|---| | 新增可选属性 | minor | 不受影响 | 直接发，plan 同步，报表按需接 | | 必填改可选 | minor，部分引擎视为 breaking | 旧数据满足，新数据可能为空 | 下游先加空值分支，再评估引擎兼容 | | 类型 string 改 number | major | 隐式转换或报错，聚合静默出错 | 新属性名双写，旧字段保留一个版本周期 | | 语义变更（如 `plan_type` 值域） | major | `WHERE` 静默返回 0 行 | 换新事件名或新枚举，附映射表 | 版本策略可以压成三句话：新增可选属性升 minor，破坏性变更升 major，语义变更换新名字而不是原地改。事件用 `active`、`deprecated`、`experimental` 三态管理；废弃先双写、再切读、最后删除，不做原地改名。 一个具体反例：把 `plan_type` 的取值从 `pro` 改成 `professional`，在 code review 里像一次文案修改，在历史查询里是一次静默事故——`WHERE plan_type = 'pro'` 从此返回 0 行，看板不会报错，只会变成一条水平线。等有人发现，通常已经过去一个季度。 **一次变更是否破坏性，标准不是“代码会不会报错”，而是“旧查询会不会静默算错”。** 前者在发版时暴露，后者在季度复盘时才发现，代价差一个数量级。 ## 8.5 身份解析 **身份解析（identity resolution）的目标不是“把同一个人合并成一条记录”，而是“在需要的时候能合并，在证据不足时敢不合并”。** 前者是算法，后者是产品。 身份系统通常要处理四类 ID：匿名 ID（`anonymous_id` 或 `device_id`）、登录 ID（`user_id`）、账号或组织 ID（`account_id`、`group_id`）、外部 ID（email、phone、CRM ID）。大多数事故发生在第三类和第四类：把 account 当 user，或者把 email 当唯一键。 各家给出的答案差别很大，而且差别不在“能不能合并”，在“合并失败时怎么办”。PostHog 最保守：匿名事件不创建 person profile，调用 `identify` 才创建并把之前的匿名事件并进来；如果两个档案都已经 identify 过，系统直接拒绝合并并记录 `Refused to merge an already identified user`，因为它无法判断哪个是真身（[PostHog Identify](https://posthog.com/docs/data/identify)）。Amplitude 同时使用 device ID、user ID 与 Amplitude ID，优先 user ID，但标准项目无法把两个已确立 `user_id` 的历史活动合并，只能在未来把新活动归到正确 ID（[Amplitude 身份](https://amplitude.com/docs/data/data-assistant-user-solutions/cross-device-identity-engineering)）。这句话对迁移项目很关键：合并错了，改不回去。 Mixpanel 用 `$device_id` 与 `$user_id` 首次同现形成 identity cluster，Simplified ID Merge 把 canonical distinct_id 固定为 `$user_id`；Original API 每个 cluster 最多 500 个 distinct ID，Simplified 取消了该上限，但迁移必须新建项目（[Mixpanel 身份合并](https://docs.mixpanel.com/docs/tracking-methods/id-management/identifying-users-simplified)、[迁移说明](https://docs.mixpanel.com/docs/tracking-methods/id-management/migrating-to-simplified-id-merge-system)）。Snowplow 是确定性图谱：合并时旧 ID 成为规范 ID 并发出 merge event；如果合并会违反唯一标识约束——例如同一设备出现两个不同 `user_id`——系统不猜，直接为无法归属的标识新建匿名 ID（[Snowplow Merges](https://docs.snowplow.io/docs/identities/concepts/merges/)、[唯一标识](https://docs.snowplow.io/docs/identities/concepts/unique-identifiers/)）。GA4 有三个身份空间（User-ID、device ID、建模），Reporting Identity 可选 Blended、Observed、Device-based，政策明确禁止在未获同意时把已登录与未登录会话 stitch 起来（[GA4 Reporting Identity](https://support.google.com/analytics/answer/10976610?hl=en)、[GA4 政策](https://developers.google.com/analytics/policy?hl=en)）。 身份还会直接进账单。Segment 的 MTU 定义为计费周期内唯一 `userId` 数，加上未关联 `userId` 的唯一 `anonymousId` 数；同一用户跨 source 只算一次，但未登录的 Web 与 App 会各算一个匿名 MTU（[Segment MTU](https://www.twilio.com/docs/segment/guides/usage-and-billing/mtus-and-throughput)）。所以“尽早 identify”既是分析问题，也是成本问题——这也是为什么很多团队在登录墙前就开始要手机号，而这个决定后来往往被隐私团队推翻。 边界案例比主流程更能说明问题： | 场景 | 直觉做法 | 后果 | 更稳的做法 | 判定规则 | |---|---|---|---|---| | 共享设备，B 用户登录 | 把 A 的 `anonymous_id` 并到 B | A、B 的历史混成一个人 | 登出 `reset()`，登录新建 cluster | 设备所有权未验证，不合并 | | 先匿名、后登录 | 登录时重写历史事件的 `user_id` | 不可回滚，审计断链 | 保留匿名 ID，追加 alias/merge 事件 | 只追加映射，不改写事实 | | 同一人两个已登录账号 | 强行 merge | 删除请求无法定位全部数据 | 建 person → account 层级，不合并 user | 账号边界由业务定义，不由算法猜 | | 邮箱大小写或变更 | 把 email 当唯一键 | 重复档案或误并 | 内部 immutable ID，email 只作可更新属性 | 可变属性不进主键 | | 跨域投放页 | 只传 `user_id` | 匿名段丢失、会话断裂 | 传 `device_id` 加 `session_id` | 会话连续性需要两个 ID | | B2B 多成员 | 把 account 当 user | 席位、权限、行为全错 | Group/account 独立建模 | 计费单元不等于行为主体 | | 家庭共享订阅 | 当 user 合并 | 多个人的行为混成一个人 | 单独 `household_id`，只用于计费与内容权限 | 不参与行为身份合并 | 自研系统至少要有一个冲突队列，把“无法判定”的合并请求挂起等人处理，而不是静默取最新值。Snowplow 的唯一标识冲突和 PostHog 的拒绝合并，本质上是把这个队列产品化了；区别只是 Snowplow 会为无法归属的标识新建匿名 ID，而 PostHog 选择保留两个档案。两种都不完美，但都可解释。 > **判断**：身份系统的成熟度，不看它能合并多少，而看它敢拒绝多少。没有“不合并”能力的系统，最终一定会制造一批无法解释的重复用户，而且这些重复会同时出现在报表、人群和账单上。 ## 8.6 会话与归因上下文 **会话是最像事实、其实最像观点的对象。它不在事件里，它在事件之间。** Segment 的六个原语里根本没有 session（[Segment Spec](https://www.twilio.com/docs/segment/connections/spec)）；Mixpanel 明确说会话在查询时计算，改定义会回溯历史（[Mixpanel Sessions](https://docs.mixpanel.com/docs/features/sessions)）；GA4 默认 30 分钟不活动结束，没有最大时长，可以用 `extend_session` 延长（[GA4 Sessions](https://support.google.com/analytics/answer/9191807?hl=en)）；Amplitude 的移动端在进入后台 5 分钟后结束会话（[Amplitude Sessions](https://amplitude.com/docs/data/sources/instrument-track-sessions)）；PostHog 默认超时也是 30 分钟，但最大时长 24 小时（[PostHog Sessions](https://posthog.com/docs/data/sessions)）；Snowplow 把会话做成 `client_session` 实体，移动端前后台可以分别配置（[Snowplow 会话](https://docs.snowplow.io/docs/sources/web-trackers/tracking-events/session/)）。 | 产品 | 默认超时 | 最大时长 | 前后台与重置 | 可重算 | |---|---|---|---|---| | GA4 | 30 分钟不活动 | 无上限 | 进后台开始计时，`extend_session` 可延长 | 否，仅能延长 | | Amplitude | Web 30 分钟；移动后台 5 分钟 | 文档未给固定上限 | 前后台分别计时 | 有限 | | Mixpanel | 30 分钟，可配置 | 未给固定上限 | 可改为事件型或 `session_id` 属性型 | 是，改定义回溯历史 | | PostHog | 30 分钟不活动 | 24 小时 | 同一浏览器/设备，可跨 tab | 部分 | | Snowplow | Web 30 分钟；移动前后台各 30 分钟 | 无上限 | 移动可分别配置 | 是，建模层可重算 | | Segment | 无原生会话 | — | — | 下游自算 | 这张表的重点不是记住数字，而是看最后一列：能不能重算。能重算，会话定义就可以迭代；不能重算，一次配置失误会永久留在历史里。Mixpanel 把重算做成默认能力，代价是“改定义会改历史”，于是任何口径调整都要提前通知报表使用方——这不是技术问题，是协作问题。 跨域是会话断裂的高发场景。Amplitude 的要求很具体：跨域时要把 device ID 和 session ID 一起通过 URL 传过去，只传 device ID 会保留匿名身份，但会丢掉会话连续性（[Amplitude 跨域](https://amplitude.com/docs/data/sources/instrument-track-unique-users)）。 归因窗口在分析层配置，不在采集层。GA4 的 Attribution Settings 默认获客转化 30 天（可选 7 天或 30 天），其他转化 90 天（可选 30、60、90 天），改模型会同时影响历史与未来报表（[GA4 归因设置](https://developers.google.com/analytics/devguides/config/admin/v1/rest/v1alpha/AttributionSettings)）；`session_start` 携带 gclid、UTM、referrer，归因模型是非直接上次点击。这意味着“渠道效果”不是一个采集事实，而是一个可配置的分析结论。把它当成事实写进周报，迟早会和市场部的口径打架。 深链是另一个被低估的上下文来源。Firebase Dynamic Links 已在 2025-08-25 停服，所有 `page.link` 域名与自定义域名链接停止工作；依赖它传递 campaign、邀请码、商品 ID 的团队必须迁移（[Firebase 公告](https://firebase.google.com/support/dynamic-links-faq)）。迁移的不只是链接，还有“用户从哪来”这条上下文——很多团队在迁移后才发现，新用户的渠道归因突然全变成了 direct。 > **判断**：会话是产品语义，不是技术常量。把 30 分钟写死在 SQL 里，等于把一次产品决策固化成了不可审计的假设；正确做法是把它做成可配置、可版本化、可重算的语义层，并在迁移前准备一张口径对照表。 ## 8.7 数据质量与埋点验收 **数据质量不是“校验通过率”，而是“违规事件有没有出路”。** 一条坏事件被挡住，和一条坏事件被悄悄丢掉，在报表上看起来一样，在事故复盘时完全不同。 | 出口 | 代表做法 | 数据去哪 | 能不能捞回 | 适用 | |---|---|---|---|---| | 放行并标记 | Amplitude 标记为 unexpected | 进主表，带标记 | 能，查询时过滤 | 探索期、低风险属性 | | 拒绝写入 | Amplitude 拒绝事件或属性 | 不进表 | 不能，需重发 | 明确不允许的字段 | | 阻断并丢弃 | Segment Schema Controls | 丢弃 | 默认不能，除非转发到隔离 Source | 合规红线、生产环境 | | 隔离待修 | Snowplow failed events | 单独 warehouse 表 | 能，修好后用 SQL 合并 | 长期基础设施 | | 隐藏待审批 | Mixpanel Event Approval | 进库但不可见 | 能，审批后可见 | 新事件治理 | 细节决定这套出口是“治理”还是“事故”。Segment 的阻断只在 cloud-mode destinations 生效，未被转发到隔离 Source 的 blocked events 会被永久丢弃（[Schema Controls](https://www.twilio.com/docs/segment/protocols/enforce/schema-configuration)）。Amplitude 把违规拆成三类：未规划的事件类型、未规划的事件或用户属性、未规划的属性值；每一类都可以选“标记并摄入”或“拒绝”，拒绝事件时不存事件及属性，拒绝属性时保留事件但不存属性，且 Validation Errors 只展示最近 24 小时（[Amplitude Schema](https://amplitude.com/docs/data/configure-schema)）。Mixpanel 的 Event Approval 默认隐藏新事件，管理员审批后才可见；Data Volume Monitoring 用最多 24 个月历史判断预期范围，默认看前一天，可改成两天以容忍摄入延迟，新 Enterprise 项目从 2025-12 起默认开启（[Event Approval](https://docs.mixpanel.com/docs/data-governance/event-approval)、[Volume Monitoring](https://docs.mixpanel.com/docs/data-governance/data-volume-monitoring)）。Snowplow 的 failed events 不写入 atomic 表，失败可能发生在收集、校验、富化、加载四段；最常见的是埋点代码与 schema 不一致，或 schema 没发布到生产 registry，修复后可以合并回去，但该功能不回溯（[Failed Events](https://docs.snowplow.io/docs/fundamentals/failed-events/)）。 **重复与乱序要靠幂等键和重算窗口。** PostHog 的去重键是 uuid、事件名、时间戳与 distinct_id 的组合，重复事件在 ClickHouse 后台 merge 时最终去重，所以重复可能短暂存在；修改事件时 timestamp 必须保持一致，否则不会被去重（[PostHog Events](https://posthog.com/docs/data/events)）。Snowplow 用 `snowplow__days_late_allowed` 控制“设备产生到发出”的最大延迟，用 `snowplow__lookback_window_hours` 给“落库延迟”留缓冲，超过窗口的事件不会被处理。 Bot 与采样是另外两类噪声，而且往往不可见。GA4 自动排除已知机器人与爬虫，依据是 Google 研究与 IAB 的 International Spiders and Bots List，不能关闭，也看不到排除了多少（[GA4 Bot 排除](https://support.google.com/analytics/answer/9888366?hl=en)）；Data Quality 指示器会标注 Unsampled、Thresholding applied、Heavily sampled（例如“基于 8.88% 数据”），阈值由系统决定、不能调整（[数据质量](https://support.google.com/analytics/answer/12856703?hl=en)、[阈值说明](https://support.google.com/analytics/answer/9383630?hl=en)）。对采购的含义是：你看到的不是全量数，而且平台不打算让你知道差多少。 埋点验收应该独立于生产管道。下面这张清单可以直接贴进发版流程： | 检查项 | 通过标准 | 证据 | 谁签字 | |---|---|---|---| | 事件在 plan 中 | 名称、版本、owner、状态齐全 | plan diff | 数据产品 | | 必填与类型 | 必填无空、类型匹配、枚举在词表内 | 校验报表 | 数据工程 | | 身份字段 | 带 `anonymous_id`，登录后带 `user_id` | 抽样 100 条 | 客户端 | | 同意状态 | 带 purpose、CMP 版本、时间戳 | 请求或属性 | 隐私 | | 时间戳 | 设备时间与接收时间差在窗口内 | 迟到 P95 | 数据平台 | | 重复与丢失 | 重复率低于 0.1%，发送与接收差异可解释 | 对账日报 | 数据平台 | | 出口与保留 | 目的地、保留期、删除路径明确 | 数据流图 | 架构 | | 回滚 | 关闭开关后不产生脏数据 | 演练记录 | 发布负责人 | 八项里任何一项没有 owner，都不算“埋点完成”。验收也不该只在上线前做一次：Avo Inspector 这类工具的价值，是把“线上事件形状”持续对比 plan，而不是在发版评审会上对着文档点头。 运行期至少要有六个指标并配 owner：采集成功率（2xx 除以总请求，目标不低于 99.9%）、采集 p95（低于 500 ms）、端到端新鲜度、重复率（低于 0.1%）、schema 违规率（低于 0.5%）、bot 与异常流量占比。这些阈值来自本报告第 10 章的架构建议，需要按业务校准，但“有没有指标”比“指标定在哪”更重要。 > **判断**：最危险的不是脏数据，是静默丢数据。脏数据至少还能在报表上看见异常；静默丢失只会让所有数字一起变小，而且每个人都以为那是业务下滑。 ## 8.8 隐私与同意 **同意不是 banner 上的一个布尔值，而是一组带版本、带目的、可审计的事件属性。** GDPR 的三条底线直接落在埋点上：第 5(1)(c) 条要求数据最小化，只收集与目的相关且必要的数据；第 6 条要求至少一个合法性基础；第 7 条要求同意可证明、可撤回，且撤回与给出一样容易（[GDPR 原文](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679)）。EDPB 05/2020 指南进一步要求同意是自由给出、具体、知情、明确的意思表示（[EDPB 指南](https://www.edpb.europa.eu/documents/guideline/guidelines-052020-on-consent-under-regulation-2016679_en)）。 广告技术有自己的一套语言。IAB Europe 的 TCF 2.2 于 2023-05-16 上线，实施截止从 2023-09-30 延到 2023-11-20，核心变化之一是取消 purposes 3–6 的 legitimate interest 基础，只能选 consent（[TCF 2.2](https://iabeurope.eu/tcf-2-2-launches-all-you-need-to-know/)）。Google 的 Consent Mode v2 在 2023-11 增加 `ad_user_data` 与 `ad_personalization`，与 `ad_storage`、`analytics_storage` 一起构成四种同意状态；EEA 流量若没有把同意信号传给 Google，广告个性化与再营销能力会受限（[Consent Mode](https://developers.google.com/tag-platform/security/guides/consent?hl=en)、[EEA 说明](https://support.google.com/tagmanager/answer/13695607?hl=en)）。 产品侧的落地差异很大。Segment 要求把 consent object 加到所有事件上，再按类别决定路由到哪些目的地；Consent Management 只在 Business 套餐提供，且官方不建议用它管理通信订阅偏好（[Segment Consent](https://www.twilio.com/docs/segment/privacy/consent-management)）。PostHog 提供 opt-out/opt-in、IP 采集开关、autocapture 屏蔽、敏感信息遮罩、cookieless 模式，但这些是采集端控制，不等同于 CMP（[PostHog 数据采集控制](https://posthog.com/docs/privacy/data-collection)）。GA4 对 EU、CH、UK 用户不记录、不存储 IP，只用 IP 做粗粒度地理派生后立即丢弃；User-ID 必须是不可反推的个人标识（[GA4 EU 数据](https://support.google.com/analytics/answer/12017362?hl=en)）。 保留期是隐私设计的一部分，不是运维参数。GA4 用户级数据只能选 2 或 14 个月，其他事件数据标准版为 2 或 14 个月，360 才可选 26、38、50 个月（[GA4 保留策略](https://support.google.com/analytics/answer/7667196?hl=en)）；PostHog 付费版事件保留 7 年、免费版 1 年（[PostHog 定价](https://posthog.com/pricing)）。同一家公司如果同时用两者，“一年后还能不能查到这个人”会有两个答案。 中国是另一套规则。《个人信息保护法》第 6 条要求目的明确、合理，与目的直接相关，采取对个人权益影响最小的方式，限于实现目的的最小范围；第 13 条列出同意、合同必需、法定义务等合法性基础；第 38 条要求跨境提供满足安全评估、标准合同或认证等条件（[PIPL 原文](http://www.npc.gov.cn/npc/c2/c30834/202108/t20210820_313088.html)）。2024-03-22 发布的《促进和规范数据跨境流动规定》给出更具体的门槛：非 CIIO 自当年 1 月 1 日起累计向境外提供不满 10 万人个人信息（不含敏感）可免申报；10 万至 100 万人需标准合同或认证；100 万人以上，或 1 万人以上敏感个人信息，需安全评估（[CAC 规定](https://www.gov.cn/gongbao/2024/issue_11366/202405/content_6954192.html)）。 **同意的技术难点不在收集，而在传播。** 它必须在 SDK 发请求之前生效，并沿身份图谱传播到下游每一个目的地；否则“用户撤回了同意”只是一句 UI 文案，数据该在哪还在哪，而且没有任何一条日志能证明它被删过。 ## 8.9 边缘采集与中国特殊环境 **采集端点已经从一个运维细节，变成了产品能力。** 请求发到哪个域名、走谁的证书、在哪个区域落地，直接决定事件量。 广告拦截是第一方采集最直接的动机。PostHog 官方称反向代理通常能把事件采集量提高 10–30%，具体取决于用户群；它建议使用中性子域，不要带 analytics、tracking、telemetry、posthog、ph 等词（[PostHog 反向代理](https://posthog.com/docs/advanced/proxy)）。这是厂商自测口径，不能当成普遍规律，但方向成立：请求域名是拦截器最直接的信号。Segment 的 Custom Domain 是 Business 套餐能力，提供 HTTPS 第一方子域，支持 DNS 委派或 CNAME，但明确不能用于 device-mode destinations，因为那些 SDK 必须直接请求目的地（[Segment Custom Domain](https://www.twilio.com/docs/segment/connections/sources/custom-domain)）。 Google 在 2025-05-02 开始推送 Google tag gateway for advertisers，让 Google 标签走广告主自己的 CDN、负载均衡或 Web 服务器；官方称已配置广告主信号提升 11%（厂商口径），并计划默认启用 confidential computing（[Google 公告](https://support.google.com/google-ads/answer/16214371?hl=en)）。Cloudflare 在 2025-05-08 宣布集成，把第一方标签配置压缩到几分钟（[Cloudflare](https://blog.cloudflare.com/google-tag-gateway-for-advertisers/)）。 浏览器侧的约束没有消失，只是换了形状。Safari 从 2020-03 起默认阻止第三方 cookie（[WebKit ITP](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/)）；Chrome 在 2025-04-22 决定维持第三方 cookie，不推出新的独立提示，但继续在 Incognito 中默认阻止，并推进 IP Protection（[Privacy Sandbox](https://privacysandbox.google.com/blog/privacy-sandbox-next-steps)）。CNAME cloaking 随之出现：把第三方追踪域名伪装成站点子域，绕过基于域名的拦截；WebKit 曾以限制 CNAME 伪装响应中持久 cookie 的有效期作为反制（[WebKit Bug 215201](https://bugs.webkit.org/show_bug.cgi?id=215201)）。这意味着第一方域名不是一次性配置，而是需要持续监控 DNS、证书与 cookie 行为的工程。 中国把这个问题变得更硬。微信小程序必须先配置通讯域名，只能向指定域名发请求，域名必须 ICP 备案，不能配置父域名，端口必须精确匹配，`api.weixin.qq.com` 不能被配置为服务器域名（[微信网络能力](https://developers.weixin.qq.com/miniprogram/dev/framework/ability/network.html)）。这一条直接排除了“用一个未备案的 SaaS 采集域名”的方案。We分析要求先定义事件再上报，`wx.reportEvent(eventName, data)` 自基础库 2.14.1 起可用（[微信事件管理](https://developers.weixin.qq.com/miniprogram/analysis/wedata/tool/Data_management.html)）。HarmonyOS Analytics Kit 则明确要求 SDK 初始化必须在用户同意隐私协议之后，AAID 在重装、恢复出厂、清除应用数据或调用 `clearCachedData` 时重置（[HarmonyOS 接入](https://developer.huawei.com/consumer/en/doc/HMSCore-Guides/harmonyos-accessing-0000001169634743)）。 信创环境（国产操作系统与浏览器）的采集兼容性缺少公开的逐项清单，本次未能核实，只能标“待核实”（证据等级 C）。可行做法是把国产 OS、浏览器、WebView 内核纳入采集矩阵，逐项验证 Cookie、localStorage、CORS、TLS、证书链、代理与请求体大小，并保留测试记录——不要用“兼容国产化”一句话替代 POC。 **边缘采集的失败不会报错，只会“少一点”。** 域名、证书、备案、反代、同意门控任何一环出问题，损失都直接体现在事件量上；所以它必须有 owner、有对账、有告警，而不是交给某个人的一次配置。 ## 8.10 十条落地规范 前面九节讲的是“为什么会错”，这一节讲“怎么让它不容易错”。十条规范按执行顺序排列，每条都能直接写进研发流程。 1. **先定指标与事件，再写 SDK。** tracking plan 先过产品、数据、工程三方评审，每个事件必须说明它服务哪个指标；没有指标的事件不进 plan。这一条通常能砍掉相当一部分“以后可能有用”的采集。 2. **固定命名与类型。** 事件用 `object_action`，属性用 snake_case；禁止动态事件名与动态属性键；枚举列全，未知值走 `unknown`。命名规范要写进 lint，不要只写进 wiki。 3. **每个事件有 owner、描述、版本、状态。** 用 `active`、`deprecated`、`experimental` 三态；废弃先双写、再切读、最后删除，不原地改名。没有 owner 的事件，半年后一定没人敢动。 4. **客户端只发事实，不发派生指标。** 金额、订单状态、权限、退款以服务端为准；客户端补页面、设备、实验分组这类上下文。客户端算出来的转化率只能用于排查，不能进报表。 5. **匿名 ID 由采集端生成并持久化，登录只做关联。** 登录不重写历史 `user_id`；登出必须 `reset()`；共享设备新建 cluster。合并只能追加映射，不能改写事实。 6. **会话定义写成配置并版本化。** 超时、前后台、跨天、最大时长、campaign 捕获点全部显式；会话表可重算。不要把 30 分钟写死在查询里。 7. **采集端做轻校验，服务端做权威校验。** 必填、类型、枚举、长度在 SDK 与 Collector 先挡一层；完整 schema 在服务端执行；失败进隔离区，不静默丢。 8. **幂等三件套：`event_id`、事件时间、接收时间。** 重试与补数都带同一个去重键；迟到窗口、重算窗口、回放流程写进 runbook，而不是留在某个人的记忆里。 9. **同意状态作为事件属性。** 记录 purpose、category、CMP 版本、时间戳；在发请求前 gate；删除请求要能沿身份图谱定位到所有关联 ID。 10. **把指标、阈值和 owner 一起写进 SLO。** 采集成功率、schema 违规率、身份合并率与孤儿率、重复率、迟到 P95、bot 占比；每个指标有 owner 和告警阈值。没有 owner 的指标，第一次告警就会被静音。 如果只有 90 天，顺序应该是：第 1 至 30 天写 plan 与身份规则，第 31 至 60 天做对账与隔离区，第 61 至 90 天再谈实时与自动化。反过来做——先上实时、先买人群运营——通常会在第三个月发现所有数字都要重算，而重算的前提，恰好是前 60 天没做的那两件事。 > **判断**：如果只能保留一项能力，保留“可解释的事件契约 + 可审计的身份图谱”。SDK、存储、查询、图表都可以换；这两样换了，等于把公司过去三年的所有结论重做一遍。 ## 参考来源 - [Segment Spec Overview](https://www.twilio.com/docs/segment/connections/spec) - [Segment Data Collection Best Practices](https://www.twilio.com/docs/segment/protocols/tracking-plan/best-practices) - [Segment Tracking Plan](https://www.twilio.com/docs/segment/protocols/tracking-plan/create) - [Segment Schema Controls](https://www.twilio.com/docs/segment/protocols/enforce/schema-configuration) - [Segment MTUs, Throughput and Billing](https://www.twilio.com/docs/segment/guides/usage-and-billing/mtus-and-throughput) - [Segment Consent Management](https://www.twilio.com/docs/segment/privacy/consent-management) - [Segment Custom Domain](https://www.twilio.com/docs/segment/connections/sources/custom-domain) - [PostHog Identifying Users](https://posthog.com/docs/data/identify) - [PostHog Events](https://posthog.com/docs/data/events) - [PostHog Sessions](https://posthog.com/docs/data/sessions) - [PostHog Autocapture](https://posthog.com/docs/data/autocapture) - [PostHog Pricing](https://posthog.com/pricing) - [Amplitude Create a Tracking Plan](https://amplitude.com/docs/data/create-tracking-plan) - [Amplitude Track Sessions](https://amplitude.com/docs/data/sources/instrument-track-sessions) - [Amplitude Cross-device Identity](https://amplitude.com/docs/data/data-assistant-user-solutions/cross-device-identity-engineering) - [Amplitude Schema Settings](https://amplitude.com/docs/data/configure-schema) - [Mixpanel Sessions](https://docs.mixpanel.com/docs/features/sessions) - [Mixpanel Identifying Users](https://docs.mixpanel.com/docs/tracking-methods/id-management/identifying-users-simplified) - [Mixpanel Event Approval](https://docs.mixpanel.com/docs/data-governance/event-approval) - [GA4 Event Naming Rules](https://support.google.com/analytics/answer/13316687?hl=en) - [GA4 Data Retention](https://support.google.com/analytics/answer/7667196?hl=en) - [GA4 Sessions](https://support.google.com/analytics/answer/9191807?hl=en) - [GA4 Reporting Identity](https://support.google.com/analytics/answer/10976610?hl=en) - [Google Analytics SDK and User ID Policy](https://developers.google.com/analytics/policy?hl=en) - [GA4 Measurement Protocol](https://developers.google.com/analytics/devguides/collection/protocol/ga4) - [GA4 Attribution Settings](https://developers.google.com/analytics/devguides/config/admin/v1/rest/v1alpha/AttributionSettings) - [Snowplow Pipeline](https://docs.snowplow.io/docs/pipeline/) - [Snowplow Schema Versioning](https://docs.snowplow.io/docs/event-studio/data-structures/versioning/) - [Snowplow Identities: Merges](https://docs.snowplow.io/docs/identities/concepts/merges/) - [Snowplow Identities: Unique Identifiers](https://docs.snowplow.io/docs/identities/concepts/unique-identifiers/) - [Snowplow Session Tracking](https://docs.snowplow.io/docs/sources/web-trackers/tracking-events/session/) - [Snowplow Late-arriving Data](https://docs.snowplow.io/docs/modeling-your-data/modeling-your-data-with-dbt/package-mechanics/late-arriving-data/) - [Snowplow Failed Events](https://docs.snowplow.io/docs/fundamentals/failed-events/) - [Avo Developer Overview](https://www.avo.app/docs/implementation/devs-101) - [Open Data Contract Standard](https://bitol-io.github.io/open-data-contract-standard/latest/) - [Google Consent Mode](https://developers.google.com/tag-platform/security/guides/consent?hl=en) - [Google EEA Consent Mode](https://support.google.com/tagmanager/answer/13695607?hl=en) - [IAB Europe TCF 2.2](https://iabeurope.eu/tcf-2-2-launches-all-you-need-to-know/) - [EDPB Guidelines 05/2020 on Consent](https://www.edpb.europa.eu/documents/guideline/guidelines-052020-on-consent-under-regulation-2016679_en) - [GDPR Full Text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679) - [中华人民共和国个人信息保护法](http://www.npc.gov.cn/npc/c2/c30834/202108/t20210820_313088.html) - [促进和规范数据跨境流动规定](https://www.gov.cn/gongbao/2024/issue_11366/202405/content_6954192.html) - [Google Tag Gateway for Advertisers](https://support.google.com/google-ads/answer/16214371?hl=en) - [Privacy Sandbox: Next Steps](https://privacysandbox.google.com/blog/privacy-sandbox-next-steps) - [WebKit ITP: Full Third-Party Cookie Blocking](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/) - [Firebase Dynamic Links Deprecation FAQ](https://firebase.google.com/support/dynamic-links-faq) - [微信小程序网络能力](https://developers.weixin.qq.com/miniprogram/dev/framework/ability/network.html) - [微信小程序数据管理](https://developers.weixin.qq.com/miniprogram/analysis/wedata/tool/Data_management.html) - [HarmonyOS Analytics Kit 接入](https://developer.huawei.com/consumer/en/doc/HMSCore-Guides/harmonyos-accessing-0000001169634743) --- # 09 · 核心模块（下）：从漏斗到 Agent，分析如何变成行动 > 漏斗、留存、路径的差别不在图表，而在窗口、计数单位与重入；这些默认值决定 AI 给出的是洞察，还是更快的错误。 同一批事件，三家平台可以给出三个不同的注册转化率，而三家都没有算错。差别不在查询引擎，在四个默认值：计数单位（用户、会话还是事件）、时间窗口（从哪一步起算、重复进入是否重置）、属性归属（取事件发生时的值还是用户当前的值）、行动权限（能不能把人群送出去、能不能改实验分组）。 这四件事没有行业标准，只有厂商默认值。迁平台时最先变的不是图表，是漏斗的分母与留存的同期群（cohort）；对账时最先对不上的不是转化率，是分子分母。2026 年，这件事变得更贵：计价单位从 MAU 转向事件量，回放从独立品类变成套件标配，实验与 flag 被并进分析平台，AI 从问答走到定时监控与执行动作（[Amplitude 定价](https://amplitude.com/pricing)、[Mixpanel 2025 年定价公告](https://mixpanel.com/blog/mixpanel-pricing-1m-free-events-autocapture/)、[PostHog 定价](https://posthog.com/pricing)）。功能清单越来越长，默认值越来越难看见。 > **判断**：分析模块的竞争已经从“能不能算”移到“默认值是否与业务周期一致”。漏斗窗口 7 天还是 30 天，决定了你把谁记为失败；留存 cohort 是新用户还是活跃用户，决定了曲线是升还是降。采购与迁移的第一件事不是比图表，是把这些默认值逐条写进合同附件。 本章把分析拆成五个原语和九个模块，先讲数学假设与产品陷阱，再讲行动层，最后给一张按模块而不是按厂商的选型表。厂商路线差异留给第 2、3 章；这里只关心一件事：这个数字能不能被复核。证据以公开文档完整的四家国际平台为主；中国厂商的模块默认值公开资料少，只能进 POC 与合同，本章按待核实处理。 ## 9.1 分析原语：五个参数决定所有模块 **所有分析模块都是五个原语的组合：计数、去重、窗口、顺序、分配。** 事件分析是计数加分组；漏斗是计数加窗口加顺序；留存是去重加周期；路径是顺序加剪枝；归因是分配；人群是去重加规则。看懂这五个原语，功能表上的大多数差异会从“能力有无”变成“参数取值”。 把模块拆成三层，争论会清楚很多。计算层负责扫描、聚合、连接、去重，ClickHouse、Doris、Spark 都能做，差异在性能与成本；语义层负责指标定义、身份解析、会话切分、渠道分类与 cohort 口径，它决定“同一个问题为什么答案不同”；行动层负责人群下发、实验、引导、告警与 Agent，它决定分析能不能变成动作，也决定替换成本。功能清单只覆盖计算层，采购真正要比的是语义层的默认值与行动层的权限模型。 | 契约 | 它决定什么 | 最容易出事的模块 | 改一次会发生什么 | |---|---|---|---| | 计数单位 | 一个人、一次会话，还是一条事件算一次 | 漏斗、留存、人群 | 同期的“转化人数”可以差出倍数，历史报表不可比 | | 时间窗口 | 从哪一步起算、看多久、是否重置 | 漏斗、留存、归因 | 窗口从 7 天改到 30 天，“流失”变“转化” | | 属性归属 | 取事件发生时的值，还是用户当前的值 | 人群、归因、分组 | 用今天的标签解释去年的行为，人群不可复现 | | 行动权限 | 能不能写、写给谁、谁批准 | CDP、实验、引导、Agent | 一次误发人群或误改 flag，比一张错报表贵得多 | 四个契约要落地，靠的不是文档，是指标对象。一个可用的指标至少有：ID、名称、定义、事件与过滤、窗口、计数单位、owner、版本、SQL、校验用例。图表引用指标版本，改定义产生新版本，旧报表仍可复现。没有这一层，“转化率”只是三个看板上三个同名的数。指标还要有血缘：它由哪些事件、哪些属性、哪段 SQL 生成；上游事件改名或删除，哪些看板会受影响。没有血缘，治理只能靠人记。 ## 9.2 漏斗：分母、窗口与重入 **漏斗（funnel）的定义只有一句话：一组有序或无序的步骤，加一个转化窗口。** 用户从第一步进入，在窗口内完成全部步骤即算转化。设 E 为窗口内进入第一步的人数，C_k 为完成第 k 步的人数，整体转化率是 |C_K|/|E|，相对转化率是 |C_k|/|C_{k-1}|。 这里有一个容易被忽略的数学条件：只有在“单次进入、步骤嵌套、无排除”时，整体转化率才等于各步相对转化率的乘积。一旦允许重入、任意顺序或中途排除，连乘就会高估或低估。多数漏斗截图没有告诉读者它属于哪种情况。 三家的默认值不同，而且都能自洽。Amplitude 按“最长且最早”的转化序列给每个用户计数：先找完成步骤最多的序列，再取其中最早的一条；勾选 hold constant by session 后，统计单位从用户变成“用户 × 会话”（[Amplitude 漏斗文档](https://amplitude.com/docs/analytics/charts/funnel-analysis/funnel-analysis-how-amplitude-computes-conversions)）。Mixpanel 默认 7 天窗口，最长 366 天或 12 个会话；计时从第一次 Step 1 开始，后面重复的 Step 1 不会重置；重入分 default 与 optimized re-entry，计数单位分 Uniques、Totals、Sessions（[Mixpanel 漏斗文档](https://docs.mixpanel.com/docs/reports/funnels/funnels-advanced)）。PostHog 提供 sequential、strict order、any order 三种顺序；排除步骤会把这些人从整个漏斗里剔除，而不只是从某一步剔除（[PostHog 漏斗文档](https://posthog.com/docs/product-analytics/funnels)）。 | 维度 | Amplitude | Mixpanel | PostHog | |---|---|---|---| | 漏斗计入 | 去重用户，按最长且最早的序列 | Uniques / Totals / Sessions | 去重用户（文档以 unique users 示例） | | 窗口与起算 | 可配置；按会话锁定后单位为用户×会话 | 默认 7 天，最长 366 天或 12 会话；从首次 Step 1 起算 | 按洞察配置，文档未列统一默认值（待核实） | | 重入 | 取决于计数单位与 hold constant | default 与 optimized re-entry | 文档未强调（待核实） | | 排除步骤 | 待核实 | 不能放在首尾 | 被排除者从整个漏斗剔除 | 最常见的错误不是算错，是窗口选错。B2B 试用、保险投保、家装决策的周期经常超过 14 天，7 天窗口会把“后来转化”记成“未转化”。举个只用于说明逻辑的例子：某用户 1 月 1 日进入漏斗，1 月 10 日完成最后一步。7 天窗口记为未转化，30 天窗口记为转化；如果他在 1 月 5 日又触发一次第一步，Mixpanel 默认不会重置计时，optimized re-entry 会把第二次进入当成新漏斗。同一个人的结果可能相反，两张报表都没有算错。 还有三个更隐蔽的：分母漂移——日期范围内发生 Step 1、但 Step 2 落在范围外，报表会把后者算成流失；属性归因错位——前端事件有 browser、后端事件没有，按 browser 拆分时默认取 first touchpoint，会把后端步骤的人分到错误桶里；身份未合并——Mixpanel 明确提示 ID Merge 最长需要 24 小时，合并前当天的漏斗可能少算转化（[Mixpanel FAQ](https://docs.mixpanel.com/docs/reports/funnels/funnels-faq)）。日报里那些“今天转化率掉了”，有一部分只是身份还没合并。 所以顺序不能反：先用路径发现真实序列，再定义漏斗。反过来做，得到的是设计者想象中的流程，不是用户走出来的流程。 ## 9.3 留存：cohort 定义比曲线形状重要 **留存（retention）回答的是：完成某个起始事件的人，在第 n 个周期是否回来完成返回事件。** N-day 留存 R_n = |A_n|/|C|（C 为 cohort 人数），只数第 n 个周期恰好回来的人；滚动或无界留存 U_n = |∪A_m|/|C|（m ≥ n），数第 n 个周期及以后回来过的人。前者可升可降，后者单调不增，两条线不能画在同一张图上比较。 半衰期 h = min{n : U_n ≤ 0.5}，比“Day 30 留存”更适合跨产品比较，因为它不依赖某个固定周期。但它不适合回答“第 7 天发生了什么”：前者是生存分析，后者是周期行为，混用会让团队在“留存变好”和“留存变差”之间反复横跳。 cohort 定义比曲线形状重要。Amplitude 默认看新用户，以用户触发起始事件的日期作为入口，Return On or After 指第 7 天及以后回来的人，支持最多 100 个自定义 bracket（[Amplitude 留存文档](https://amplitude.com/docs/analytics/charts/retention-analysis/retention-analysis-interpret)）。Mixpanel 的 cohort 是“在该周期内做过 A 事件的人”，同一个人可以在多个周期里各算一次，默认 On or After，另有 On、On or Before、Streak 三种（[Mixpanel 留存文档](https://docs.mixpanel.com/docs/reports/retention)）。PostHog 提供 first time、first ever occurrence、recurring 三种 cohort 口径，返回口径分 On 与 On or after，均值分 weighted 与 simple（[PostHog 留存文档](https://posthog.com/docs/product-analytics/retention)）。同一张留存表，三种入口，三条曲线。 最常见的错误有五个：起始事件选“任意事件”，人人 100% 留存；分母用 DAU 而不是 cohort，把“活跃”混成“留存”；新老用户混算，渠道结构变化被误读成产品改进；右删失——最近的 cohort 还没走完 Day 30 就画曲线，末尾自然下垂；低频产品用日留存。前四个是定义与呈现问题，最后一个是用错周期：先用使用间隔（usage interval）看自然使用周期，再决定看周留存还是月留存。 留存常被当作 product-market fit 的证据，但高留存也可能来自强制使用、合同绑定或推送。判断 PMF 至少要看三件事：自然使用周期内的留存、主动行为的比例、付费或推荐的意愿。单看一条曲线，结论会很脆。 > **判断**：漏斗与留存没有行业标准，只有厂商默认值。迁平台时最先变的不是图表，是这两个数；对账时不要先比转化率，先比分子分母——入口人数、各步人数、窗口内完成人数。分子分母都对上，比率才有意义。 ## 9.4 路径：Sankey 的宽度不是转化率 **路径（path）图把会话内的事件序列聚合成有向图：节点是事件或页面，边是转移，宽度是人数。** 路径数量随深度指数增长，所以任何可视化都在做剪枝：只显示 top N、设最小人数、合并通配符、清理动态 URL。PostHog 的 Paths 支持 pageview、screen、自定义事件和 SQL 表达式，也支持 wildcard group、path cleaning、排除事件与最小/最大人数（[PostHog Paths](https://posthog.com/docs/product-analytics/paths)）；Mixpanel 的 Flows 用 Sankey，默认展示锚点事件之后的 3 步，可向前或向后扩展（[Mixpanel Flows](https://docs.mixpanel.com/docs/reports/flows)）。 读图有三个陷阱。第一，节点高度是人数，不是转化率；没有分母，宽节点只说明“到过的人多”。第二，采样会让长尾路径消失：1% 采样下，真实占比 0.05% 的路径期望只剩零头，“没人走”可能只是没被采到。第三，路径是共现，不是因果；用户先看帮助文档再付费，不等于帮助文档促成付费。 路径图最有价值的用法不是看全图，是看分叉点：在哪个节点分叉、分叉后哪条支路的人更少、少的那条是不是因为缺引导。把它与漏斗的 drop-off 对齐，比盯着一张密不透风的 Sankey 有用。最小可用是一条锚点事件、前后各 3 步、一个最小支持阈值、一套 URL 清洗规则，并在图上注明是否采样。无限下钻的全景路径和“自动发现最佳路径”都是伪需求：前者没人看得完，后者没有对照。 | 原语 | 最小定义 | 最常见错误 | 上线验收 | |---|---|---|---| | 漏斗 | 入口事件、2–5 步、转化窗口、计数单位 | 窗口短于决策周期；重入口径不一致；排除被当全局过滤 | 换一种计数单位，结果差异能解释 | | 留存 | 起始事件、返回事件、周期、cohort 分母 | 起始事件选“任意事件”；右删失未标注；低频产品用日留存 | 最近 cohort 标了“未完成”，分母可复算 | | 路径 | 锚点事件、前后步数、最小支持阈值 | 把节点宽度当转化率；采样吞掉长尾；把共现当因果 | 图上写明采样率与最小人数 | ## 9.5 人群与画像：时间语义决定名单 **人群（cohort）是按属性规则或行为规则圈出的用户集合，可用于分析过滤、下发与实验分层。** 它看起来只是筛选器，实际上是分析平台里最像承诺的对象：一旦人群被送到广告平台或 CRM，它就不再是一张图，而是一份要花钱的名单。 三种时间语义决定名单。Amplitude 把窗口分为 During（选定日期范围内，滚动更新）、Since（从某天起累计）、Within（每个用户首次使用后的 X 天内）。同一个“过去 30 天活跃”，During 每天漂移，Since 只增不减，Within 对每个用户固定（[Amplitude cohort 文档](https://amplitude.com/docs/analytics/define-cohort)）。选错语义，人群规模会随报表日期变化，而运营看到的只是“人数又变了”。 属性覆盖是第二个坑。Mixpanel 明确写：用户属性只保存最新值，含用户属性的人群条件用“当前值”，即使该值在历史上已经变化。这意味着“2024 年 1 月的上海用户”这类人群，今天重建会得到不同结果；历史属性必须显式加时间与度量，否则不可复现（[Mixpanel cohorts](https://docs.mixpanel.com/docs/users/cohorts)）。画像同理：用户表存的是“现在”，分析要的是“当时”；没有版本，画像只能服务当下运营，无法解释历史。 能力差异在计数方式与规则组合上。Amplitude 支持六种计数：次数、相对次数、属性总和、属性去重值、历史次数、区间内次数；Mixpanel 支持行为条件、AND/OR 组合与 CSV 静态导入，CSV 人群不会随时间更新；PostHog 的 cohort 可做漏斗与留存的过滤器，但一次只能用一个 cohort 做漏斗拆分，因为用户可能同时属于多个人群（[PostHog 漏斗文档](https://posthog.com/docs/product-analytics/funnels)）。 RFM 与 LTV 是最容易被做成“伪精确”的两件事。RFM 的常见做法是把 R、F、M 各分五档，拼成 125 组；分位点必须固定，否则本月的高价值用户到下月会被重新定义。LTV 的简化式是 ARPU × 毛利率 × 平均生命周期，平均生命周期用留存曲线下的面积估计，而不是用 1/churn 拍一个数。预测人群多数是 propensity（会不会发生），不是 uplift（营销带来的增量），两者在投放决策上不能互换。 **人群不是标签的容器，是带时间戳的查询结果。** 人群太小，广告平台匹配率低；多个人群叠加，重复计数。最小可用是 3–5 条规则、明确时间窗、可保存、可导出、注明更新频率。 ## 9.6 归因：模型是表层，ID 是底层 **归因（attribution）是把一次转化的功劳分配给路径上的触点。** 模型决定分配规则，lookback 决定哪些触点有资格，渠道映射决定触点归到哪个桶。五个常见模型在单次转化内的学分之和都是 1，但不同模型之间不可加总——这是归因报表最常被误用的地方。 | 模型 | 分配规则 | 适用 | 主要偏差 | 什么时候会骗你 | |---|---|---|---|---| | First-touch | 首个触点 100% | 品牌拉新 | 高估上游，低估转化页 | 自然转化全记在第一次曝光上 | | Last-touch | 末个触点 100% | 直接响应 | 高估收割渠道 | 品牌词与 direct 抢走全部功劳 | | Linear | 所有触点均分 | 触点同等重要 | 稀释关键触点 | 长路径上每个触点都显得平庸 | | Position | 首尾各 40%，中间均分 | 强调开场与收尾 | 中间触点被低估 | 内容与社群渠道长期背锅 | | Time-decay | 越近权重越高 | 短决策周期 | 忽略早期种草 | 长周期业务里早期触点消失 | 一次转化若有四个触点，linear 每个 25%，position 首尾各 40%、中间各 10%，last-click 全给最后一个。渠道排名通常不同。这是模型差异，两张报表都没有算错。 GA4 的真实产品面比行业印象窄。归因报告只提供三种模型：data-driven、paid and organic last click、Google paid channels last click；除全 direct 路径外，direct 访问不获得归因学分；data-driven 用转化与未转化路径训练，转化后 7 天内可重新归因（[GA4 归因说明](https://support.google.com/analytics/answer/10596866?hl=en)）。归因设置里的 lookback 对 first_open 与 first_visit 默认 30 天（可改 7 天），其他关键事件默认 90 天（可选 30 或 60 天）（[GA4 归因设置](https://support.google.com/analytics/answer/10597962?hl=en)）。行业常说“六种模型随便选”，GA4 的产品里并没有这个选项。 Amplitude 的渠道分类器是另一类问题：规则在查询时逐事件执行，不落库，改规则会改历史报表。这意味着“渠道”不是一个稳定维度，而是当前规则对历史的重新解释；做同比前必须先冻结规则版本（[Amplitude 营销分析文档](https://amplitude.com/docs/analytics/marketing-analytics)）。 移动端的墙更高。ATT 在 iOS 14.5+ 要求授权后才能访问 IDFA，未授权时 IDFA 全零，用哈希邮箱或手机号绕过同样需要授权（[Apple ATT](https://developer.apple.com/app-store/user-privacy-and-data-use/)）。SKAdNetwork 自 iOS 11.3 起提供安装验证，v4 自 iOS 16.1 起可用；对 App Store 广告，Apple 已要求改用 AdAttributionKit（iOS 17.4+）：三次转化窗口、按人群匿名阈值分层、安装转化中最多 5 个非获胜网络的回传，且不含用户级标识（[AdAttributionKit](https://developer.apple.com/documentation/AdAttributionKit)、[SKAdNetwork](https://developer.apple.com/documentation/StoreKit/SKAdNetwork)）。平台归因与应用内归因因此不可能完全对上。 归因回答“谁拿到了功劳”，增量回答“如果没有这个触点，转化会不会发生”。前者可以用规则算，后者需要对照或因果模型。把归因当增量，最常见的后果是给本来就会转化的人重复发券。六个高频错误：lookback 短于决策周期、把多个广告平台报告的转化直接相加、忽略 direct 与品牌词的蚕食、用 last-click 评估品牌广告、改完渠道分类器直接做同比、把 SKAdNetwork 的转化值当收入。 > **判断**：归因的瓶颈已经从模型转向 ID 与同意。模型选择是治理问题——先冻结 lookback 与渠道分类器版本，再谈 first-touch 还是 data-driven；没有统一 ID 的“全渠道归因”，只是把三份不可加总的报表放进同一个看板。 ## 9.7 回放与热图：默认遮罩就是合规成本 **回放的真实差异不是“能不能录”，是“默认遮住什么”；热图的差异在它依赖哪种采集。** Web 回放记录 DOM 快照与增量变更，在播放器里重建页面；移动端没有 DOM，通常直接录屏或按帧捕获。Mixpanel 明确区分这两件事：Web 采集 DOM 结构与变更，本质是重建；移动端采集实际屏幕像素，包含滚动、轮播、自动滚动（[Mixpanel 回放文档](https://docs.mixpanel.com/docs/session-replay)）。这个差异决定体积、性能与遮罩方式都不同。 Web 回放的链路是初始化快照、DOM 变更、输入事件、鼠标与滚动、网络请求与控制台，播放器按时间戳重放。任何一个环节采样或丢失，回放就会与事件对不上。移动端按帧捕获，体积更大，通常需要更激进的采样与更长的上传间隔，因此更不适合“全量”。回放也从独立品类变成了套件标配：Amplitude Free 含每月 1 万条回放，Mixpanel Free 同样含每月 1 万条，FullStory Free 给到每月 3 万 sessions（[Amplitude 定价](https://amplitude.com/pricing)、[Mixpanel 2025 年定价公告](https://mixpanel.com/blog/mixpanel-pricing-1m-free-events-autocapture/)、[FullStory Free 计划](https://help.fullstory.com/hc/en-us/articles/360020623354-FullstoryFree-Plan)）。差异化因此转到隐私默认值、移动端采集与采样控制。 | 厂商 | 默认遮什么 | 遮罩边界与灰区 | 保留与采样 | |---|---|---|---| | Mixpanel | 所有非输入文本、输入框；图片与视频阻断 | 客户端执行，原文不发送 | 全局采样，或按事件触发采集 | | Amplitude | Medium 档：表单字段与文本输入 | 其他文本原样采集；alt、title、placeholder、aria-label、value、data-* 等 HTML 属性不遮 | React Native 远程遮罩可能不稳，建议用 AmpMaskView 手动遮 | | PostHog | 输入框 | 普通文本不遮 | 按 session ID 哈希采样；可按 URL、事件、flag 设触发组 | | Pendo | 三档 Web、两档移动配置（默认档未列明，待核实） | CSS 选择器仅 Web；移动端需 SDK 3.14.0+ 代码规则 | 默认保留 30 天（可扩 90 天），clip 保留一年 | 这张表最值得看的是“遮罩边界与灰区”那一列。Mixpanel 的默认最保守，所有非输入文本都遮（[Mixpanel 隐私控制](https://docs.mixpanel.com/docs/session-replay/session-replay-privacy-controls)）；Amplitude 的 Medium 是默认级别，HTML 属性不在遮罩范围（[Amplitude 隐私设置](https://amplitude.com/docs/session-replay/manage-privacy-settings-for-session-replay)）；PostHog 只遮输入框（[PostHog 隐私控制](https://posthog.com/docs/session-replay/privacy)）；Pendo 的 Web 与移动是两套规则，移动端要用 SDK 3.14.0+ 的代码级规则，默认保留 30 天（[Pendo 隐私文档](https://support.pendo.io/hc/en-us/articles/18049064847515-Session-Replay-privacy)）。很多页面把订单号、邮箱、地址写进 data-* 或 placeholder，遮了输入框不等于遮了这些字段；Mixpanel 的代价则是回放里看不到正文，排查体验问题时要临时放开。 遮罩在客户端执行，这一点决定合规成本落在哪：服务端遮罩意味着原文已经离开浏览器，客户端遮罩意味着规则写在前端代码里，改一次要发版。采购时问“默认遮什么”比问“能不能遮”有用。 采样也要写清楚。PostHog 按 session ID 哈希确定采样，同一会话的决策稳定；触发组可以按 URL、事件、feature flag 分别设置采样率与最短时长（[PostHog 采集控制](https://posthog.com/docs/session-replay/how-to-control-which-sessions-you-record)）。Mixpanel 支持全局采样，也支持“1% 全局加命中 checkout_error 时 100%”这类事件触发采集。回放时间轴与事件时间轴不一致，通常来自时钟、批量上传与 ID merge，不是播放器坏了。 热图（heatmap）的可用性取决于采集前提。PostHog 的 clickmap 依赖 autocapture，scrollmap 依赖 pageleave 事件；免费版只允许采集 3 个页面；热图数据本身不计费，但没有 autocapture 就没有 clickmap（[PostHog 热图](https://posthog.com/docs/toolbar/heatmaps)）。把热图当“用户意图”的证据，是把点击密度当成了注意力。 > **判断**：回放的默认遮罩就是合规成本，采样率就是存储成本。100% 采集与“全量回放”在演示里最好看，在生产里最先撞上隐私审查与账单。回放能指出用户在哪一步停顿，不能解释停顿的原因，更不能证明改版有效。 ## 9.8 告警与异常：先处理季节性，再谈 AI **告警（alert）是对一个已保存指标的定期检查：静态阈值、相对变化，或异常检测（anomaly detection）。** 它看起来是运维功能，实际是分析平台里最容易制造“狼来了”的地方。 检测器要匹配数据形态。计数型指标适合 Poisson 或负二项；连续型且近似正态的适合 Z-score；有离群点的适合 MAD 或 IQR；多维且分布未知的才轮到 Isolation Forest。PostHog 把这几种都摆出来：统计类（Z-score、MAD、IQR、阈值）、机器学习类（Isolation Forest、KNN、LOF、ECOD、COPOD）与集成（AND/OR）。它的 Z-score 与 MAD 默认做一阶差分，目的是把周期性的日、周波动转成变化量，避免把正常高峰当异常；官方建议噪声大的指标把 sensitivity 从 0.9 调到 0.95，并在保存前用模拟器回测（[PostHog 告警文档](https://posthog.com/docs/alerts)）。 用错检测器，灵敏度调得再细也只是在拟合噪声。低流量指标用 z-score，方差估计不稳，应该用 Poisson、负二项或设最小量；不做季节性差分，周一涨就会被判异常。 根因分析（root cause analysis, RCA）是另一层。Mixpanel 的 RCA 先验证异常：用与时间粒度匹配的基线（小时约 24 小时、天约 14 天、周约 9 周、月约 6 个月）算 z-score，2 以上才认为不是噪声；再做同 weekday、同 hour 的季节性对照；然后由 LLM 选维度、跑拆分、算贡献度。贡献度的定义是“该段变化除以整体变化”，不是因果效应；置信度是 High、Medium、Low 的标签，不是统计区间。RCA 还有配额：Enterprise 300 次/天、Growth 70 次/天、Free 10 次/天（[Mixpanel RCA](https://docs.mixpanel.com/docs/root-cause-analysis)）。 多重比较是最被低估的问题：100 个 5% 阈值的告警，期望有 5 个误报。告警没有 owner 与 runbook，误报就会被静音，静音之后真异常也没人看。最小可用是 3–5 个核心指标、一个静态阈值加一个同比、明确 owner、静默窗口。全指标异常检测与“AI 自动解释”是伪需求：前者制造噪声，后者制造没有复核的结论。 ## 9.9 CDP、实验与应用内引导：最后一公里 **最后一公里由三个模块组成：把人群送出去（CDP）、把改动做成对照（实验）、把提示放到用户面前（引导）。** 三者共用一套身份，任何一环对不上，前面的分析就停在看板上。 CDP 做三件事：采集与转发、身份解析、人群与下发。mParticle 的公开结构是 Collect、Validate、Connect，身份用 IDSync，质量用 Data Master，人群用 Audiences，出口用 Firehose（[mParticle 文档](https://docs.mparticle.com/)）。它不提供事件语义治理，也不提供探索式分析；把它当分析平台，会得到一堆没有定义的宽表。分析厂商的“轻 CDP”则有硬限额：Mixpanel 的 Cohort Sync 支持一次性、每小时、每天、实时四种节奏，但每个项目最多 60 个动态同步、每个人群最多 1,000 万用户、只导出 6 个匹配字段（distinct_id、名、姓、partner_user_id、email、phone），且只有付费计划能保存 cohort（[Cohort Sync](https://docs.mixpanel.com/docs/cohort-sync)）。这够做“把高价值人群推给 Braze”，不够做企业级 CDP。PostHog 把 CDP 做成 Data pipelines：sources 进、transformations 改、destinations 出（[PostHog CDP](https://posthog.com/docs/cdp)）。 实验由三段组成：分配（flag 或随机化）、曝光（exposure 事件）、度量（事件、漏斗、仓库表）。2026 年 5 月 5 日，Amplitude 宣布接手 Statsig 的品牌与客户，并继续维护其云版与 warehouse-native 平台；Statsig 团队则在 2025 年 9 月 2 日加入 OpenAI（[Amplitude 与 Statsig](https://amplitude.com/blog/amplitude-and-statsig-partnership)、[Statsig 公告](https://statsig.com/blog/openai-acquisition)）。实验因此更像分析套件的一层，而不是独立品类。PostHog 的 Experiments 直接复用 flag 与事件，支持 Bayesian 与 frequentist，变体可关联回放（[PostHog Experiments](https://posthog.com/docs/experiments)）。Amplitude Experiment 用 mSPRT 做序贯检验，允许随时查看结果；但它对 uniques 至少要有 25 个转化、每组 100 个曝光才计算 p 值与置信区间，对 average 与 sum 指标要求每组 100 个曝光（[Amplitude 序贯检验文档](https://amplitude.com/docs/feature-experiment/under-the-hood/experiment-sequential-testing)）。这些是计算门槛，不是功效保证。 实验要先看样本比例失衡（sample ratio mismatch, SRM），再看指标。SRM 的常见原因是分配日志丢失、曝光事件重复、某个变体加载失败。guardrail 指标要提前定，不能等主指标显著后再找补。序贯检验解决的是“可以随时看”，不解决“同时看很多指标”带来的多重比较。 应用内引导的测量偏差更明显。Pendo 把引导分为 overlay 与 embedded：overlay 支持激活条件、排序与节流，embedded 只能随页面展示、不受排序影响；overlay 报告首次与重复查看，embedded 只报告首次查看（[Pendo 指南文档](https://support.pendo.io/hc/en-us/articles/27240321140763-Guides-overview)）。被引导的人往往是已经活跃的人，没有 holdout 就无法区分“引导有效”与“本来就活跃”。常见错误也集中在这里：把 cohort sync 当实时；实验曝光与转化事件的时区、身份不一致；只看引导点击率不看留存；CDP 人群与仓库人群更新频率不同导致对不上。 ## 9.10 AI 与 Agent：能力阶梯与可验证性 **AI 在产品分析里已经走完“能问答”的阶段，正在进入“能监控、能执行”。** 2025 年 6 月 10 日 Amplitude 发布 AI Agents，到 2026 年 Q2 已形成 Global Agent 加四类专用 Agent 的结构（[Amplitude 发布](https://amplitude.com/press/ai-agents)、[Q2 财报](https://investors.amplitude.com/news-releases/news-release-details/amplitude-announces-second-quarter-2026-financial-results)）；Mixpanel Agent、Pendo Agent Mode、PostHog AI 也先后落地（[Mixpanel Agent](https://docs.mixpanel.com/docs/mixpanel-agent)、[Pendo Agent Mode](https://www.pendo.io/pendo-blog/agent-mode-pendo-experience/)、[PostHog AI](https://posthog.com/docs/posthog-ai)）。问题是可验证性没有同步提升。 | 级别 | 能力边界 | 公开代表 | 必要控制 | 采购时问什么 | |---|---|---|---|---| | 辅助查询 | 自然语言转查询、生成图表；不解释指标口径 | Amplitude Fast（2–10 秒、2–4 次工具调用）、Mixpanel Agent | 只读；展示查询与口径 | 能不能看到生成的 SQL 与引用的指标版本 | | 自动洞察 | 多步调查、根因、定时监控与主动推送；结论仍是假设 | Amplitude Investigate（4–5 分钟、10 次以上调用）、专用 Agent 定时跑；Mixpanel RCA | 基线、季节性、贡献度、置信标签；去重与静默 | 异常怎么验证、贡献度是不是因果 | | 自动行动 | 建人群、发实验、改 flag、提 PR、触发引导 | PostHog AI 建 flag 与 PR；Mixpanel Agent 建人群与报表；Amplitude 专用 Agent | 人工审批、审计日志、回滚路径 | 做错时谁负责、多久能回滚 | | 自动优化 | 无人值守地调整策略 | 未见公开生产证据 | 目标函数、停止条件、人工兜底 | 有没有可审计的目标函数与停止条件 | 同一个“AI”标签下，四家的写权限差了一个量级。Amplitude 的 Global Agent 提供三种模式：Fast 2–10 秒、2–4 次工具调用；Default 30–60 秒、4–6 次；Investigate 4–5 分钟、10 次以上（[Agent Modes](https://amplitude.com/docs/amplitude-ai/agent-modes)）。四类专用 Agent（Dashboard、Session Replay、Website Conversion、Customer Feedback）按计划运行，把结果推到 Agent Inbox、邮件或 Slack；涉及终端用户影响的动作需要人工批准（[专用 Agent](https://amplitude.com/docs/amplitude-ai/specialized-agents-overview)）。Mixpanel Agent 能建报表、建人群、分析回放、解释实验结果、跑 RCA，并有每日 RCA 配额。Pendo Agent Mode 明确只读、不写环境、不训练模型、不访问原始事件流。PostHog AI 能读项目数据、建看板、告警、flag，连仓库提 PR。神策把 Agent 定义为“L4 级”，但同样需要人设定目标与边界（[发布会报道](https://www.geekpark.net/news/366666)）。 评估至少要六个维度：语义正确、来源可查、可复现、权限一致、成本与延迟、升级路径。一个可执行的评估集是 20 个真实问题，每个问题有标准答案与参考 SQL；记录首次正确率、需要人工修正的比例、平均工具调用次数、平均延迟、权限越界次数；每两周重跑，模型或提示词变更后必须重跑。没有这张表，“AI 很好用”只是演示现场的印象。 PostHog 复盘一年 agent 经验时给了三条反直觉结论：eval 不足以覆盖真实多步任务，需要看生产 trace；把推理过程藏起来会让用户更不信任；顺序任务拆给子 agent 往往更差，因为每层抽象都丢上下文（[PostHog 复盘](https://posthog.com/blog/8-learnings-from-1-year-of-agents-posthog-ai)）。这三条对买家同样成立：演示看的是能力上限，生产看的是失败率与可解释性。五个常见错误：用 NLQ 替代指标治理；不展示查询与口径；Agent 有写权限但没有审批与审计；用 LLM 做统计推断；只看 demo，不看真实 trace。 > **判断**：AI 的能力上限由语义层决定。没有指标对象、没有查询溯源、没有权限继承的 Agent，只是把“猜口径”自动化了；它让错误更快抵达决策，而不是让决策更准。 ## 9.11 模块选型：按验收方式，不按功能数量 **模块的成熟度不等于可用性。** 到 2026 年，事件分析、漏斗、留存、路径、回放、告警在主流平台上都已商品化，真正的差异在默认值与退出成本；人群、CDP、实验、引导决定分析能不能变成动作；AI 决定这些动作能跑多快、由谁负责。 按验收方式，大部分模块可以归入三类：账本型（事件分析、漏斗、留存）要求可复算，同一查询今天与下周跑出的历史区间一致；证据型（路径、回放、归因、告警与 RCA）要求可追溯，图上写明采样率、遮罩范围与分类器版本；动作型（人群、CDP、实验、引导、AI）要求可回滚，做错时有人负责、有审计、能撤回。这张表给的是动作，不是评分；评分卡与 TCO 在第 11 章。 | 模块 | 要冻结的默认值 | 建议动作 | 失败长什么样 | |---|---|---|---| | 事件分析 | 计数单位、属性来源、时区与日界 | 先做指标对象，再买工具 | 两个看板两个数，会上先吵口径 | | 漏斗 | 窗口起点、重入、排除范围 | 签约前用同一份事件跑三家 | 转化率不可比，迁移后历史作废 | | 留存 | cohort 定义、返回口径、右删失 | 先测使用间隔再定周期 | 最近 cohort 永远下垂 | | 路径 | 采样率、最小人数、URL 清洗 | 只看分叉点，不买“全景路径” | 长尾消失被当成“没人走” | | 人群 | 时间语义、历史属性、更新频率 | 每周复算，先确认下发目的地 | 名单漂移，投放重复 | | 归因 | lookback、分类器版本、direct 处理 | 冻结版本再做同比 | 渠道排名随规则变化 | | 回放与热图 | 默认遮罩、采样率、保留期 | 先定遮罩再开录，专用工具即可 | 合规事故，或账单随留存翻倍 | | 告警与 RCA | 检测器、季节性、owner | 3–5 个指标，先手工后自动 | 告警疲劳，真异常没人看 | | CDP 下发 | 同步频率、字段、失败重试 | 已有 CDP 就别买轻 CDP | 把小时级同步当实时 | | 实验 | SRM、guardrail、多重比较 | 套件内够用，统计要求高再单买 | 先看主指标，后找 guardrail | | 引导 | 曝光口径、holdout、排序 | 归入产品运营工具 | 点击率高，留存没变 | | AI | 只读/可写、审批、审计 | 只读先行，写权限最后给 | 更快地产生可信的错误 | 自建的顺序由依赖关系决定，不由难度决定：事件模型、事件分析、漏斗、留存、人群、回放、实验、AI。没有事件语义，漏斗与留存只是两段 SQL；没有稳定的人群，实验与引导无法复用；没有回放与事件对齐，AI 看到的“用户行为”只有半张图。AI 放最后，因为它放大的是语义层的能力，也放大语义层的错误。 选型会上最值得问的六个问题：漏斗窗口从哪一步起算、重复进入会不会重置；留存默认 cohort 是新用户还是活跃用户、右删失怎么标；人群用当前属性还是历史属性、窗口是 During、Since 还是 Within；渠道分类器是查询时算还是落库、改规则会不会改历史；回放默认遮哪些字段、HTML 属性与 URL 参数遮不遮；AI 能不能看到查询与口径、动作要不要审批、审计在哪里。六个问题里有两个答不上来，就先别签。 还有一条来自产品边界的经验：Pendo 的 Track Event 上限 5,000 条，看似短板，反而降低了它的语义锁定——上限越低，能沉淀在平台里的自定义事件越少，替换越容易（[Pendo Track Events](https://support.pendo.io/hc/en-us/articles/360032294151-Track-Events)）。反过来，功能最全的平台往往在第三年最难换掉。模块选型的终点不是“功能最多”，是“每个模块都能被单独替换，而语义不必重来”。 > **判断**：分析模块的价值不在“能算”，在“能被复核”。账本型模块要可复算，证据型模块要可追溯，动作型模块要可回滚；三者都过，才轮到 AI 提效。做不到这三件事的平台，功能越多，第三年的迁移成本越高。 ## 参考来源 - [Amplitude — Pricing](https://amplitude.com/pricing) - [Amplitude — How Amplitude computes conversions through funnels](https://amplitude.com/docs/analytics/charts/funnel-analysis/funnel-analysis-how-amplitude-computes-conversions) - [Amplitude — Interpret your retention analysis](https://amplitude.com/docs/analytics/charts/retention-analysis/retention-analysis-interpret) - [Amplitude — Define a new cohort](https://amplitude.com/docs/analytics/define-cohort) - [Amplitude — Sessions, channels, and attribution](https://amplitude.com/docs/analytics/marketing-analytics) - [Amplitude — Manage privacy settings for Session Replay](https://amplitude.com/docs/session-replay/manage-privacy-settings-for-session-replay) - [Amplitude — Agent Modes](https://amplitude.com/docs/amplitude-ai/agent-modes) - [Amplitude — Specialized Agents overview](https://amplitude.com/docs/amplitude-ai/specialized-agents-overview) - [Amplitude — Sequential testing for statistical inference](https://amplitude.com/docs/feature-experiment/under-the-hood/experiment-sequential-testing) - [Amplitude — Debut of Amplitude AI Agents, 2025-06-10](https://amplitude.com/press/ai-agents) - [Amplitude — Amplitude and Statsig partnership, 2026-05-05](https://amplitude.com/blog/amplitude-and-statsig-partnership) - [Amplitude — Q2 2026 financial results, 2026-08-05](https://investors.amplitude.com/news-releases/news-release-details/amplitude-announces-second-quarter-2026-financial-results) - [Mixpanel — Funnels advanced concepts](https://docs.mixpanel.com/docs/reports/funnels/funnels-advanced) - [Mixpanel — Funnels FAQ](https://docs.mixpanel.com/docs/reports/funnels/funnels-faq) - [Mixpanel — Retention](https://docs.mixpanel.com/docs/reports/retention) - [Mixpanel — Flows](https://docs.mixpanel.com/docs/reports/flows) - [Mixpanel — Cohorts](https://docs.mixpanel.com/docs/users/cohorts) - [Mixpanel — Cohort Sync](https://docs.mixpanel.com/docs/cohort-sync) - [Mixpanel — Session Replay](https://docs.mixpanel.com/docs/session-replay) - [Mixpanel — Session Replay privacy controls](https://docs.mixpanel.com/docs/session-replay/session-replay-privacy-controls) - [Mixpanel — Root Cause Analysis](https://docs.mixpanel.com/docs/root-cause-analysis) - [Mixpanel — Mixpanel Agent](https://docs.mixpanel.com/docs/mixpanel-agent) - [Mixpanel — Simpler pricing, 2025-02-03](https://mixpanel.com/blog/mixpanel-pricing-1m-free-events-autocapture/) - [PostHog — Funnels](https://posthog.com/docs/product-analytics/funnels) - [PostHog — Retention](https://posthog.com/docs/product-analytics/retention) - [PostHog — User paths](https://posthog.com/docs/product-analytics/paths) - [PostHog — Alerts](https://posthog.com/docs/alerts) - [PostHog — PostHog AI](https://posthog.com/docs/posthog-ai) - [PostHog — 8 learnings from 1 year of agents, 2026-10-16](https://posthog.com/blog/8-learnings-from-1-year-of-agents-posthog-ai) - [PostHog — Session replay privacy controls](https://posthog.com/docs/session-replay/privacy) - [PostHog — Control which sessions you record](https://posthog.com/docs/session-replay/how-to-control-which-sessions-you-record) - [PostHog — Heatmaps](https://posthog.com/docs/toolbar/heatmaps) - [PostHog — Data pipelines (CDP)](https://posthog.com/docs/cdp) - [PostHog — Experiments](https://posthog.com/docs/experiments) - [PostHog — Pricing](https://posthog.com/pricing) - [Pendo — Guides overview](https://support.pendo.io/hc/en-us/articles/27240321140763-Guides-overview) - [Pendo — Session Replay privacy](https://support.pendo.io/hc/en-us/articles/18049064847515-Session-Replay-privacy) - [Pendo — Agent Mode, 2025-10-07](https://www.pendo.io/pendo-blog/agent-mode-pendo-experience/) - [Pendo — Track Events](https://support.pendo.io/hc/en-us/articles/360032294151-Track-Events) - [FullStory — FullstoryFree Plan](https://help.fullstory.com/hc/en-us/articles/360020623354-FullstoryFree-Plan) - [Google Analytics — Get started with attribution](https://support.google.com/analytics/answer/10596866?hl=en) - [Google Analytics — Select attribution settings](https://support.google.com/analytics/answer/10597962?hl=en) - [Apple — App Tracking Transparency](https://developer.apple.com/app-store/user-privacy-and-data-use/) - [Apple — AdAttributionKit](https://developer.apple.com/documentation/AdAttributionKit) - [Apple — SKAdNetwork](https://developer.apple.com/documentation/StoreKit/SKAdNetwork) - [mParticle — Documentation](https://docs.mparticle.com/) - [Statsig — Statsig is joining OpenAI, 2025-09-02](https://statsig.com/blog/openai-acquisition) - [极客公园 — 发布会报道](https://www.geekpark.net/news/366666) --- # 10 · 参考架构：把事件流做成可查询、可治理、可负担的系统 > 架构没有标准答案，只有对写入、查询、实时性、隔离和成本的明确取舍；三套栈，对应三种规模与组织能力。 架构讨论很容易滑向引擎选型：ClickHouse 还是 Doris，Kafka 还是 Pulsar。但真正决定一套埋点分析平台能否活过三年的，是五个更早的约定：一条事件在哪一层变成不可变事实；谁有权在采集端拒绝它；一次查询要扫多少字节；哪个租户的故障可以影响别人；合同结束时数据能不能带走。这五个问题没有答案，换什么引擎都只是在给一条没有责任链的系统加速。 本章给出一套可以拿去评审的参考架构：八层责任链、五张核心表、五种部署模式、四档实时性、一个成本公式，以及三套按规模分档的栈。它们不是某家厂商的最佳实践，而是从公开文档、定价页和故障边界里反推出来的最小共识。 ## 10.1 分层架构：先定义不可变的那一层 一条事件从 SDK 到看板要经过八道手。评审时第一个问题不该是“用哪个引擎”，而是“这一层坏了，上一层的什么能力会消失”。 ![图 10-1 · 埋点分析平台参考架构](/assets/diagrams/reference-architecture.svg) | 层 | 职责 | 典型实现 | 先坏在哪里 | 要观测什么 | |---|---|---|---|---| | 采集 | 鉴权、限流、schema 校验、脱敏、批量、背压 | Snowplow Collector、PostHog capture、自建 Go 服务、API Gateway | 流量尖峰打满连接；校验失败静默丢事件 | 4xx/5xx、p95 延迟、拒收率、批量大小 | | 队列 | 缓冲、解耦、重放、顺序 | Kafka、Kinesis、Pulsar、S3 加队列 | 分区倾斜；保留期太短无法回放 | consumer lag、分区吞吐、存储增长 | | 流处理 | enrichment、身份、会话、去重、迟到数据 | Flink、Kafka Streams、ClickHouse Kafka Engine | 状态膨胀；checkpoint 超时；sink 重复 | checkpoint 时长与失败率、状态大小、反压 | | 存储 | 事实、维度、会话、聚合、TTL | ClickHouse、Doris、StarRocks、Iceberg、BigQuery | part 过多；合并跟不上；更新口径错 | part 数、合并队列、扫描字节、磁盘 | | 语义 | 事件命名、属性类型、指标口径、版本 | 自建 metadata、dbt、LookML、Cube | 同名不同义；版本漂移 | 口径变更记录、覆盖率、验收通过率 | | 查询 | 预聚合、缓存、队列、隔离 | 物化视图、Projection、Query Cache、资源组 | 大查询拖垮集群；缓存返回旧数 | p95/p99、排队时长、内存峰值、扫描量 | | 应用 | 看板、漏斗、留存、路径、告警 | 自建、Superset、Metabase、厂商 UI | 口径不可解释；下钻断链 | 查询采用率、错误率、下钻成功率 | | 治理 | 血缘、质量、审计、保留、删除 | OpenMetadata、自建、厂商控制台 | 删除不彻底；审计缺口 | 质量分、DSAR 时长、保留合规 | 这张表最容易被读成技术清单，其实它划的是四个故障域。采集与队列负责“不丢”，流处理负责“可重放的状态”，存储负责“不可变事实”，语义与查询负责“口径和速度”。分层的分界线不是技术栈，是事件是否可变。采集层只做鉴权、校验、限流、落盘；流处理只做可重放的状态计算；存储层保留不可变事实；语义层承担口径。把 enrichment 放进采集，collector 就有状态，一个地理库变慢会拖垮入口。把口径写进 SQL，换引擎时就要重写所有看板。 > **判断**：分层的目的不是把图画整齐，而是让每一层可以单独替换、单独回滚、单独计量。做不到这三件事的“分层”，只是把单体拆成了更多部署单元。 ## 10.2 采集与接入：只做认人、验形、落盘 采集网关的职责应该被压到最小：认人是 write key、token、域名白名单；验形是 schema 版本、必填字段、属性类型、大小上限；落盘是批量写队列，成功返回 202，失败返回可重试的 429 或 503。 返回码就是合同。202 表示“已接收”，不等于“已入库”；客户端重试必须带同一个 `event_id`，否则重复无法收敛。很多团队在 collector 里重新生成 ID，重试一次就多一条。背压也必须向前传：队列满时正确做法是拒绝并给 `Retry-After`，而不是把内存吃满。Kafka producer 的 buffer 满了会阻塞发送，阻塞会沿着 collector 的线程池一路放大，最后表现为“所有租户一起超时”。 采集端不应该做 enrichment。地理库、UA 解析、身份拼接、风控规则都会让它从无状态变成有状态。Snowplow 把链路拆成 Collect、Validate、Enrich 三段，坏事件进 bad stream，而不是让 collector 做业务判断，这个拆分值得抄[Snowplow 管道文档](https://docs.snowplow.io/docs/pipeline/)。边缘采集能降低首跳延迟，但日志、采样、PII 脱敏、版本发布仍要单独治理；对 100 亿/月以上的量，它的主要价值是吸收尖峰和就近终结 TLS。 同意状态必须成为事件模型的一等字段。EDPB 在 2024-10-07 通过的最终指引把 ePrivacy 第 5(3) 条的“终端设备存储与访问”扩展到 localStorage、像素、指纹和 SDK 标识[CNIL 对指引的说明](https://www.cnil.fr/fr/le-cepd-adopte-des-lignes-directrices-pour-clarifier-la-notion-de-tracage-de-la-directive-eprivacy)。CNIL 给出的免同意窄门是：唯一目的、匿名统计、不跨站、不转第三方；它建议 cookie 不超过 13 个月、数据不超过 25 个月[CNIL 受众测量豁免](https://www.cnil.fr/fr/cookies-solutions-pour-les-outils-de-mesure-daudience)。多数产品分析 SDK 默认写第一方 cookie 并生成跨会话 ID，落在同意区。Google 的 Consent Mode 在拒绝期间发送不带 cookie 的 ping，它是信号传递，不是同意管理，仍要配 CMP[Consent Mode 文档](https://support.google.com/analytics/answer/10000067)。 PII 也很少从“姓名字段”正门进来。URL query 里的邮箱与 token、autocapture 抓到的 DOM 文本、会话回放的输入框，都是入口。哈希不是匿名化，无盐 SHA-256 的邮箱可以被彩虹表反查；IP 截断到 /24 或 /48 仍可用于城市级定位，仍属去标识化。GA4 对欧盟、瑞士、英国用户不记录 IP，而是在 EU 域与服务器写入前丢弃[GA4 IP 处理](https://support.google.com/analytics/answer/12017362)；Heap 提供 IP 与地理位置采集的关闭开关[Heap 安全页](https://www.heap.io/platform/security)。 采集层的成熟度，看它敢拒绝多少流量，而不是能接住多少流量。一个只会返回 200、只会加机器、不会区分坏事件与坏客户的入口，会把所有治理成本推给下游。 ## 10.3 流处理：状态是成本，不是吞吐 队列的第一个决定是分区键。Kafka 只保证分区内有序、分区之间并行，所以顺序只到 key。会话切分要按 `user_id` 分区；按 `event_id` 分区会打散顺序，按租户分区会让大租户变成热分区。 保留期是回放窗口，不是归档。Kafka 的 retention 到期就删；要长期保留，要么 tiered storage，要么落 S3 或 Iceberg。KIP-405 已合并，并从 Kafka 3.9 起标记为 production-ready，但同一份 KIP 明确不支持 compacted topic 与 tiered storage 组合，也不支持 JBOD[KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405:+Kafka+Tiered+Storage)。 Flink 的容错靠 checkpoint：barrier 注入 source，算子对齐后快照状态，失败时回到最近一次完成的 checkpoint 并重放 source[Flink 状态文档](https://nightlies.apache.org/flink/flink-docs-stable/docs/concepts/stateful-stream-processing/)。这套机制有三个直接成本项。状态大小：身份图谱、会话窗口、去重集合都在 state 里，RocksDB 放磁盘不等于免费。Checkpoint 间隔：间隔短恢复快、重复少，但 I/O 与 CPU 开销高；官方明确默认关闭，需要显式开启。对齐：多输入算子在 barrier 处要对齐，unaligned checkpoint 把 in-flight 数据也写进状态，用 I/O 换延迟。 流里值得做的事，按投入产出排序只有四件。第一，schema 校验与坏事件分流，别让一条脏数据阻塞整个分区。第二，enrichment，只做“查询时必须用到”的字段，能批处理做的不要放流里。第三，会话切分，按 `user_id` keyBy，事件时间加 gap 窗口，迟到超过 allowed lateness 的进 side output。第四，去重，用 `event_id` 加状态 TTL，且 TTL 必须大于“最大可能迟到加重放窗口”，否则重放时会把已去重的事件再放过去。 身份解析是最容易低估的。匿名 ID 到登录 ID 的合并本质是图问题。流里做实时合并只能处理简单情况；复杂合并要离线图计算加版本化映射表，流里只查表。把图算法塞进 Flink 状态，结果通常是状态越来越大、checkpoint 越来越慢、合并结果还不一致。 Exactly-once 是端到端合同，不是组件开关。Flink 官方表格显示，Elasticsearch、OpenSearch、DynamoDB、Kinesis 等 sink 仍是 at-least-once，只有 Kafka sink 在事务生产者下才是 exactly-once[Flink sink 保证](https://nightlies.apache.org/flink/flink-docs-stable/docs/connectors/datastream/guarantees/)。Kafka 的 KIP-98 则是“生产者视角”：幂等生产者保证单会话内不重复，事务保证跨分区原子写，但消费者侧不能保证一个已提交事务的所有消息被一起消费[KIP-98](https://cwiki.apache.org/confluence/display/KAFKA/KIP-98+-+Exactly+Once+Delivery+and+Transactional+Messaging)。工程上要的是幂等键、可重放、对账，而不是一个开关。 流处理的钱主要花在状态上，不是花在吞吐上。状态越大，checkpoint 越慢，恢复越久，回滚越不敢做；最后不是系统撑不住，是团队不敢发版。 ## 10.4 存储建模：事实不可变，派生可重建 UBA 的存储建模可以压缩成一句话：事实表不可变，派生表可重建，聚合表可丢弃。 Snowplow 的 `atomic.events` 是一个好参照：一行一个事件，宽表，标准字段加自描述事件与实体列；官方明确“不要修改 atomic 表”，会变化的属性应该在分析时派生、单独存表、再 join[atomic 表文档](https://docs.snowplow.io/docs/fundamentals/warehouse-tables/)。这条规则让 schema 变更、口径修正、引擎迁移时还能重算。 | 表 | 粒度 | 关键列 | 引擎与建模 | 保留 | |---|---|---|---|---| | `event_fact` | 一条事件 | `tenant_id, event_id, event_name, event_time, ingest_time, user_id, anonymous_id, session_id, schema_version, consent_state, properties` | MergeTree，按月分区，`ORDER BY (tenant_id, event_name, user_id, event_time)` | 12–24 个月热，之后归档 | | `user_dim` | 一个用户 | `tenant_id, user_id, traits, version, updated_at` | ReplacingMergeTree(version) 或主键表 | 全量 | | `identity_map` | 一次绑定 | `tenant_id, anonymous_id, user_id, valid_from, valid_to, source` | 追加加拉链（SCD2） | 全量 | | `session_fact` | 一个会话 | `tenant_id, session_id, user_id, start, end, duration, entry, exit, pageviews, is_bounce` | 流式产出加离线修正 | 12 个月 | | `agg_daily_event` | 租户 × 事件 × 天 | `tenant_id, event_date, event_name, users, events, sessions` | AggregatingMergeTree 或物化视图 | 按需 | 分区键用时间，不要用租户。按租户分区会让小租户产生大量小 part，大租户产生超大 part；按时间分区才能做 TTL 和冷热分层。排序键把租户放前面，`ORDER BY (tenant_id, event_name, user_id, event_time)` 让同一租户的查询能裁剪 granule。高基数属性不要进排序键，它会把稀疏索引撑大，写入和合并都变慢；用跳数索引、Projection 或预聚合。ClickHouse 的主键索引是稀疏索引，按 granule 定位，不是逐行索引，列顺序直接决定裁剪效率[稀疏索引文档](https://clickhouse.com/docs/guides/clickhouse/data-modelling/sparse-primary-indexes)。 TTL 不是即时删除。ClickHouse 的 TTL 只在合并时触发，`merge_with_ttl_timeout` 默认 14400 秒，也就是 4 小时[TTL 文档](https://clickhouse.com/docs/guides/developer/ttl)。GDPR 或 DSAR 的“立即删除”不能只靠 TTL，需要 lightweight delete 或分区重写，并保留删除审计。一次删除请求至少要覆盖原始事件、用户属性、身份绑定表、人群与人群快照、会话回放片段、导出文件、错误日志、备份，以及已经进入模型训练的数据；备份删除通常按备份周期滚动，合同应写“最长一个备份周期内删除”，而不是“合理努力”[PIPL 全文](http://www.npc.gov.cn/npc/c2/c30834/202108/t20210820_313088.html)。 去重的现实更粗糙。`ReplacingMergeTree` 只在合并时去重；官方明确“不保证没有重复”，要正确结果必须用 `FINAL` 或查询时 `argMax`[ReplacingMergeTree 文档](https://clickhouse.com/docs/engines/table-engines/mergetree-family/replacingmergetree)。`FINAL` 在十亿级明细上会显著放大 CPU 和内存，把它用在所有看板，等于把成本乘 2–5 倍（经验估算，需按查询实测）。更稳的做法是写入端幂等：`event_id` 作为幂等键，存储只做最终收敛，关键指标用 `uniqExact(event_id)` 或预聚合时去重。PostHog 也用 ReplacingMergeTree，但官方文档直接写明“应避免写入重复数据，去重不是保证”[PostHog ClickHouse 架构](https://posthog.com/docs/how-posthog-works/clickhouse)。 > **判断**：明细表是资产，聚合表是缓存。把聚合当真相，改口径时就没有退路；把 TTL 当删除，是把合规问题误认为数据库配置。 ## 10.5 查询与预聚合：只覆盖承认重要的那几十个问题 预聚合不是“建个物化视图就快了”，它有三种代价：新鲜度、存储、刷新成本。 ClickHouse 的普通物化视图是插入触发器：只在插入时转换“本次插入的块”，`GROUP BY` 只在这个块内聚合，跨块聚合要靠 `AggregatingMergeTree` 在合并时继续[CREATE VIEW 文档](https://clickhouse.com/docs/sql-reference/statements/create/view)。这意味着明细迟到、补数、修数不会自动回到 MV，需要重放或重建；Refreshable MV 靠定时刷新，`APPEND INCREMENTAL` 只支持单张普通 MergeTree 源表，且拒绝 JOIN、UNION、子查询、视图和表函数。 Doris 的物化视图分同步和异步：同步 MV 写入时增量维护，异步 MV 由刷新任务 `INSERT OVERWRITE`，明确最终一致；窗口函数、`UNION ALL`、`LIMIT`、`ORDER BY`、`CROSS JOIN` 都不能透明改写[Doris MV 概览](https://doris.apache.org/docs/query-acceleration/materialized-view/overview)[异步 MV 文档](https://doris.apache.org/docs/query-acceleration/materialized-view/async-materialized-view/overview)。StarRocks 的异步 MV 适合 SPJG 形态的查询加速；[查询队列](https://docs.starrocks.io/docs/administration/management/resource_management/query_queues/)默认关闭，需要显式开启。 预聚合的正确姿势是四条。只覆盖 Top 20–50 个高频、稳定、可解释的查询。明细表永远保留，MV 可重建，schema 变更要有回滚脚本。对“必须实时”的指标用流式聚合，对“必须准确”的指标用明细重算，不要让同一个 MV 同时满足两者。监控 MV 的刷新延迟、失败率、存储放大；MV 数量超过 50 个时，刷新本身会变成负载。 查询缓存和预聚合不是一回事。它缓存中间结果，不改变数据模型。StarRocks 的 query cache 默认关闭，只对聚合查询生效，不支持异步 MV、外部表和高基数 GROUP BY；每个 BE 独立缓存，默认 512 MB，LRU 淘汰，表截断或结构变更会失效[查询缓存文档](https://docs.starrocks.io/docs/using_starrocks/caching/query_cache/)。缓存适合高并发、低基数看板；明细下钻命中率低时反而增加开销。多租户下缓存 key 必须带租户和权限。 漏斗、留存、路径的 SQL 模式，决定查询层能不能复用。漏斗按 `user_id` 分组、按 `event_time` 排序，用 `windowFunnel` 或自连接判断步骤是否在窗口内按序发生。留存先算每个用户的 `first_seen`，再按 day N 与活动表 join，关键是新老用户口径和时区。路径在 session 内按时间排序，用 `lead`/`lag` 或数组展开生成前后节点。ClickHouse 提供 `windowFunnel`、`retention`、`sequenceMatch` 等参数聚合函数[参数聚合函数](https://clickhouse.com/docs/sql-reference/aggregate-functions/parametric-functions)，但它们的语义与产品口径未必一致：`windowFunnel` 默认要求事件时间递增、在同一窗口内匹配；`retention` 返回的是按条件的布尔数组，不是现成的留存率。把这些函数直接当产品指标，常在没有数据时返回 0，或把乱序事件算错。工程上要在 SQL 外面包一层口径定义，并用一组已知答案的测试用例验收。 预聚合覆盖哪些查询，等于公开承认哪些问题重要。Top 20–50 之外的长尾，应该用明细、采样和查询配额解决，而不是再建一个 MV。 ## 10.6 五种架构模式：数据在哪，责任就在哪 把市场上的做法归成五类，比按厂商列功能更能指导决策。五种模式的差别不只是部署位置，还有实时性、隔离责任、单位成本和退出能力。 | 模式 | 数据在哪里 | 实时性 | 多租户 | 单位成本 | 退出能力 | 适合 | |---|---|---|---|---|---|---| | SaaS 多租户 | 厂商云 | 秒到分钟 | 厂商负责，租户共享 | 按事件、MTU、席位 | 取决于导出 API | 快速上线、无强合规 | | 私有化 | 客户机房、专有云 | 秒到小时 | 客户自己 | 许可加硬件加人力 | 最强，数据在本地 | 金融、政务、军工 | | warehouse-native | 客户数仓 | 分钟到小时 | 数仓权限 | 存储便宜、查询按扫描 | 强，原始表可带走 | 已有数仓、SQL 能力强 | | composable | 客户自建管道 | 秒到小时 | 自建 | 组件加人力 | 最强，组件可换 | 平台团队、超大规模 | | lakehouse | 对象存储加表格式 | 分钟到小时 | catalog 与引擎 | 存储最便宜、计算弹性 | 强，开放格式 | 归档、跨引擎、AI | SaaS 的架构价值不在功能，而在把采集、存储、升级、合规、值班打包。PostHog 是一个可读样本：事件不直接写 ClickHouse，而是从 Kafka 拉取，经 `kafka_events` 表引擎与物化视图进入 `sharded_events`（ReplicatedReplacingMergeTree）；person 表在每个节点复制一份以避免跨网络 JOIN[PostHog ClickHouse 架构](https://posthog.com/docs/how-posthog-works/clickhouse)。取舍是：Kafka 表引擎解耦摄入与写入，ReplacingMergeTree 接受最终去重，复制换来查询简化但放大内存成本。 私有化的难点不是装一个 ClickHouse，而是升级、备份、监控、故障恢复和许可证。Snowplow Community Edition 是一个典型：官方给出的规模约 100 事件/秒，AWS 约 200 美元/月、GCP 约 240 美元/月[Snowplow 自建文档](https://docs.snowplow.io/docs/get-started/self-hosted/)。但同一页明确：Community Edition 受 SLULA 约束，不得用于生产。Snowplow 从 2024-01-08 起把核心管道的新版本改用 SLULA，2024-12 的 v1.1 进一步把生产使用划到商业授权之外[许可公告](https://snowplow.io/blog/introducing-snowplow-limited-use-license)[许可 FAQ](https://docs.snowplow.io/docs/licensing/limited-use-license-faq/)。这就是“开源自建”的陷阱：基础设施看起来便宜，许可证把生产使用挡住了。 私有化也不自动解决合规。远程运维、遥测、离线补丁、云端模型都可能把数据带出去；合同应写明“默认无外网回传，任何回传需书面批准并可审计”。在中国，私有化还要面对等保 2.0、密评与信创清单，“支持信创”要拆成可测试条目：在目标环境跑通采集、查询、导出、升级[GrowingIO 私有化页](https://www.growingio.com/solutions/Private)。跨境则由人数门槛决定路径：非关键信息基础设施运营者累计出境不满 10 万人免申报，10 万到 100 万人走标准合同或认证，100 万人以上或 1 万人以上敏感个人信息走安全评估[网信办跨境规定](https://www.cac.gov.cn/2024-03/22/c_1712776611775634.htm)。 warehouse-native 把成本从存储转到查询纪律。GA4 的 BigQuery Export 是最大众化的入口：标准属性每天最多导出 100 万事件，360 属性每天最多 200 亿；流式导出是 best-effort、没有完整性 SLO[GA4 BigQuery Export](https://support.google.com/analytics/answer/9358801?hl=en)。它的成本结构不同于 SaaS：存储便宜，查询按扫描计费，因此“一个看板刷一次等于扫 30 天全表”是致命模式。warehouse-native 不是更便宜，而是把固定成本变成可变成本；它奖励分区裁剪、聚簇、预聚合和查询治理，惩罚 `SELECT *` 加大时间范围加高并发。自建管道的钱花在组件、值班和扩容，warehouse-native 的钱花在扫描和查询治理；前者是固定成本，后者是可变成本。 composable 是 Kafka 加 Flink 加 ClickHouse 或 Doris 加自建应用加语义层。优势是每一层都能替换，劣势是集成成本归你：schema registry、dead-letter、重放工具、租户配额、备份恢复、升级窗口、on-call，缺一项都会在第 6–12 个月变成瓶颈。AWS 的 Clickstream Analytics 参考实现给出一条可部署路径：ALB、ECS、MSK、Kinesis、S3、EMR Serverless、Redshift、QuickSight，官方称无 license 费用，只付 AWS 服务用量[Clickstream on AWS](https://aws.amazon.com/solutions/implementations/clickstream-analytics-on-aws/)。 lakehouse 的价值是一份数据、多引擎读、可回溯，不是低延迟看板。把 Iceberg 当 serving 层，查询延迟和并发通常撑不住。正确用法是原始事件落 S3 或 Iceberg 作为唯一真相和重算源，ClickHouse、Doris、StarRocks 做 serving 并按需回灌，归档、审计、AI 训练读 Iceberg。lakehouse 解决复用，不解决低延迟。 SaaS 与私有化的分界是：无强合规、想快速上线，选 SaaS；数据必须留在场内、且能承担升级与值班，选私有化。 多租户不是加 `tenant_id`，而是决定故障域；四种做法的隔离度与成本一起上升。 | 层级 | 做法 | 爆炸半径 | 适用 | |---|---|---|---| | L0 | 共享表加 `tenant_id` 加行策略 | 一个大查询拖垮所有租户 | 长尾小客户 | | L1 | 共享集群加资源组、工作负载组 | 同机其他租户受影响 | 大多数 SaaS | | L2 | 计算组、独立仓库、独立 ClickHouse 服务 | 限于该计算组 | 大客户、合规客户 | | L3 | 独立集群、独立账号、独立区域 | 仅该租户 | 金融、政务、跨国 | > **判断**：SaaS 与私有化的差别，不是“数据在哪”，而是“谁负责升级、备份、删除和值班”。把私有化当合规证书，会把四项责任一起买回来，却不一定买到相应的团队。 ## 10.7 实时 vs 批：先写新鲜度 SLO，再决定付几倍 实时不是二选一，而是四档。先把“实时”拆成可验收的延迟，再谈架构。 | 档位 | 端到端延迟 | 典型实现 | 成本倍数（估算） | 值得的场景 | |---|---|---|---|---| | 真实时 | 小于 1 秒 | Flink 或 KSQL 加内存或实时 OLAP | 5–10 倍 | 风控、反欺诈、实时出价 | | 准实时 | 1–60 秒 | Kafka 加 Flink 或 ClickHouse Kafka Engine | 3–5 倍 | 告警、实验曝光、实时个性化 | | 微批 | 1–15 分钟 | 调度器加微批写入 | 1.5–3 倍 | 运营看板、会话近实时 | | 批 | 1–24 小时 | dbt、Spark、数仓调度 | 1 倍 | 经营报表、留存、财务对账 | 成本倍数是经验估算，包含计算、存储、监控和人力，不是官方数字；真实倍数要用自己的查询组合压测。 值得实时的判据只有四个。决策窗口小于 1 分钟，晚 10 分钟结论就失效；动作能自动执行，实时告警要能触发工单、封禁、推送，如果最后还是人看报表，实时没有意义；数据量可控，实时链路的状态和反压成本随 key 基数上升，高基数用户画像不适合放流里；可接受近似，实时看板通常允许 1–5% 误差，财务口径要求精确就走批。 反例是把“昨天出了多少单”做成秒级。它会让 Flink 状态、Kafka 分区、ClickHouse 合并都为一个没人看的数字付钱。另一个误判是“实时等于更快”：它牺牲修正能力，迟到、重复、口径变更都更难回补；流处理重跑要停流、回放、去重。 Lambda 与 Kappa 的旧争论，在 UBA 里可以这样落地。Lambda 把批层和速度层并列，同一指标有两套代码，优点是批层能修正、速度层能低延迟，缺点是两套代码、两个真相。Kappa 只保留流层，靠日志重放修正，优点是只有一套代码，缺点是重放窗口受 retention 限制、状态重建贵。今天更常见的是“流式摄入加批式重算”：原始事件进对象存储或湖，流负责分钟级，批负责小时级、天级的修正，把“修正”放在湖上。选型时问三个问题：修正窗口多长、重放成本多少、两套代码能不能维护。 实时是溢价，不是默认值。80% 的“实时”需求，实际是“准实时加可接受的新鲜度”；把新鲜度写成 5 分钟的 SLO，比笼统说“实时”更能省钱。 ## 10.8 成本模型：账单的五个乘数 月度基础设施成本可以写成： ``` C = 采集与传输（事件数 × 单条字节 × $/GB） + 存储（原始字节 × 压缩比⁻¹ × 留存月数 × $/TB/月） + 计算（查询与流处理资源 × 小时 × $/unit-hour） + 出口（跨区与公网 GB × $/GB） + 运维（人力、值班、工具） ``` 换成“每千事件成本”更好比较：`单位成本 = C ÷ (月事件数 ÷ 1000)`。下表单价为 2026-10-18 抓取；这不是厂商报价，而是自建或云资源的成本；不含产品研发、支持、合规认证，也不含迁移期的一次性投入。 | 项目 | 单价 | 计价单位 | 来源 | |---|---|---|---| | ClickHouse Cloud 存储 | 25.30 美元/TB/月 | 存储 | [ClickHouse 定价](https://clickhouse.com/pricing) | | ClickHouse Cloud 计算 Scale | 0.2985 美元/unit/小时 | 计算 | 同上 | | ClickHouse 公网出口 | 0.1152 美元/GB 起 | 出口 | 同上 | | S3 Standard | 0.023 美元/GB/月 | 存储 | [S3 定价](https://aws.amazon.com/s3/pricing/) | | S3 Glacier Instant Retrieval | 0.004 美元/GB/月 | 存储 | 同上 | | BigQuery on-demand | 6.25 美元/TiB 扫描 | 查询 | [BigQuery 定价](https://cloud.google.com/bigquery/pricing) | | BigQuery 活跃逻辑存储 | 约 23.55 美元/TiB/月 | 存储 | 同上，按 GiB-hour 换算 | | BigQuery slot（Enterprise） | 0.06 美元/槽小时 | 计算 | 同上 | | Snowflake credit（Standard/Enterprise/BC） | 2/3/4 美元 | 计算 | [Snowflake 定价](https://www.snowflake.com/en/pricing-options/) | ClickHouse 的 unit 是计费单位，官方没有给出它与 vCPU、内存的换算，不要直接拿它做容量规划。BigQuery 的存储单价按 GiB-hour 报价，上表做了换算，实际账单以官方为准。 按单条事件 1 KB、压缩 4 倍、留存 12 个月、ClickHouse Cloud Scale 估算。 1 亿事件/月约 330 万/天、38/秒均值、峰值 5 倍约 190/秒。原始 100 GB/月，压缩后 25 GB/月，12 个月 0.3 TB；存储约 7.6 美元/月，计算 2 units 乘 0.2985 乘 730 约 436 美元/月，合计约 444 美元/月。 10 亿事件/月约 3,300 万/天、386/秒均值、峰值约 1,930/秒。原始 1 TB/月，压缩后 250 GB/月，12 个月 3 TB；存储约 76 美元/月，计算 8 units 约 1,743 美元/月，出口 1 TB 约 115 美元/月；ClickHouse 小计约 1,934 美元/月，加 Kafka、Flink、应用与 Redis，合计约 2,500–4,000 美元/月，每千事件约 0.0025–0.004 美元。 100 亿事件/月约 3.3 亿/天、3,858/秒均值、峰值约 19,300/秒。原始 10 TB/月，压缩后 2.5 TB/月，12 个月 30 TB；存储约 759 美元/月，计算 48 units 约 10,459 美元/月，出口 3 TB 约 346 美元/月；ClickHouse 小计约 11,564 美元/月，加 Kafka、Flink、应用、对象存储，合计约 16,000–22,000 美元/月，每千事件约 0.0016–0.0022 美元。 三个算例的共同结论是：存储占比不到 7%，计算占大头。所以“冷数据放 S3 能省很多”通常不成立：S3 Standard 每 TB 23 美元，ClickHouse 每 TB 25.30 美元，几乎同价；只有 Glacier Instant Retrieval 的每 TB 4 美元才有明显差异。真正省钱的是减少扫描、减少副本、减少常驻计算。 同样 10 亿事件/月换成 warehouse-native：3 TB 存储按 BigQuery 活跃逻辑存储约 70 美元/月；一次 30 天全表扫描约 1 TB，按 6.25 美元/TiB 计约 6.25 美元；每天 1,000 次全表查询约 187,500 美元/月，即使分区裁剪把扫描降到 5%，仍约 9,375 美元/月。100 个 Enterprise slot 约 4,380 美元/月，能否覆盖取决于查询复杂度，必须回放实测。Snowflake 按 credit 计费，同样 workload 要实测 credit 消耗，不能拿存储单价直接比较。 降本清单按 ROI 排序，前四条通常能拿回大部分收益。 1. 按时间分区加分区裁剪，看板默认 7 天或 30 天，查询必须带时间谓词。 2. 只保留必要列，长尾属性进 JSON 或 Map，别把 200 个属性打平成宽表。 3. 预聚合 Top 查询，把 30 天漏斗、留存做成日聚合，查询从扫 10 亿行变成扫 30 行。 4. 采样，路径、探索、异常检测用 1–10% 采样，关键指标不采样。 5. TTL 加冷热分层，明细 90 天、聚合 24 个月、原始归档 S3 或 Glacier。 6. 压缩编码，低基数用 LowCardinality，时间戳用 Delta，价格用 ZSTD。 7. 控制 part 数，批量写入每批 1–10 万行，避免小批高频。 8. 查询网关限流，每租户并发、扫描字节上限、超时，大查询进队列。 9. 结果缓存，同一看板 5 分钟内复用，缓存 key 带租户和权限。 10. 同区部署，计算和存储同区，跨区看板用只读副本。 隐藏成本也要进预算：一次 schema 变更可能重算 12 个月；迁移期双写让成本变成 1.5–2 倍，持续 3–6 个月；日志、指标、trace 的存储可能达到事件存储的 10–20%；2–3 名平台工程师的年成本，通常超过 10 亿事件/月的基础设施；出口按 GB 计费。 > **判断**：存储便宜是幻觉，重复扫描才是账单。把“每次查询扫多少字节”做成和“每天摄入多少事件”同级的指标，成本治理才算开始。 ## 10.9 可观测性与 SLO：先能对账，再谈可用 UBA 的 SLO 不只是“服务活着”，还包括“数字对得上”。八个指标应该出现在同一张看板上。 | 类别 | 指标 | 定义 | 建议目标（需按业务校准） | |---|---|---|---| | 可用性 | 采集成功率 | 2xx 除以总请求 | ≥ 99.9% | | 延迟 | 采集 p95 | collector 处理时间 | < 500 ms | | 延迟 | 端到端新鲜度 | now 减 max(event_time) | 实时 < 1 分钟；批 < 2 小时 | | 正确性 | 重复率 | 重复 event_id 除以总事件 | < 0.1% | | 正确性 | schema 违规率 | 坏事件除以总事件 | < 0.5% | | 查询 | 查询 p95 | 查询网关到结果 | < 3 秒（30 天看板） | | 成本 | 每千事件成本 | 日成本除以日事件乘 1000 | 按预算设阈值 | | 治理 | DSAR 完成时长 | 从请求到删除证明 | 按法定期限，[GDPR](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679) 一般 1 个月，CCPA 45 天 | 对账要做三层。计数对账：源端发送数、队列写入数、存储行数，按小时或天、按事件名、按租户，差异超过 0.1% 告警。去重对账：`count(*)` 与 `uniqExact(event_id)` 对比，差异突然变大说明重试或重放异常。指标对账：新旧平台的 DAU、漏斗转化率、留存率，按同一时间窗、同一人群、同一口径对比，差异要能解释到“口径”，而不是“大概”。对账任务要幂等、可重跑、有基线，结果进同一张质量看板。 告警要分级，也要带影响面。P0 是采集成功率低于 95% 持续 5 分钟、新鲜度超过 30 分钟、查询错误率超过 5%；P1 是重复率超过 1%、某租户事件量环比下降超过 50%、Kafka lag 超过 10 分钟；P2 是 MV 刷新、part 数、存储增长异常；P3 是成本与慢查询变化。没有“哪些租户、哪些看板、哪些事件”的告警，最后都会被静音。 没有对账的管道等于没有管道。一个只能证明“服务在跑”、不能证明“数字对得上”的平台，在第一次口径争议时就会失去信任。 ## 10.10 迁移：搬的是语义，不是文件 迁移不是把数据搬过去，而是把语义、身份、口径、权限一起搬过去。七个阶段，每个阶段都有退出标准。 | 阶段 | 做什么 | 退出标准 | 产物 | |---|---|---|---| | 0 盘点 | 事件、属性、量级、留存、下游、身份、PII | 清单完整，业务 owner 确认 | 事件字典、数据流图 | | 1 映射 | 旧事件到新事件、类型、时区、空值 | 映射表评审通过 | mapping sheet、schema | | 2 双写 | SDK 或服务端 fan-out，同一 event_id | 双写 7 天，差异低于 0.5% | 双写开关、采样对比 | | 3 回填 | 历史导出、转换、分区写入 | 回填完成，行数对账 | 回填脚本、批次记录 | | 4 对账 | 计数、去重、指标三层 | 关键指标差异低于 1%，可解释 | 对账报告 | | 5 切读 | 看板与 API 切到新平台 | 切读 14 天，无 P0 | 切读清单、回滚开关 | | 6 停旧 | 停止写入、只读保留、导出归档 | 合同保留期结束 | 删除证明 | 阶段 0 最容易被跳过，也最贵。事件字典不只是事件名列表，还要有谁负责、什么时候触发、属性类型、是否含 PII、下游谁在用、保留多久。没有这些，阶段 1 的映射会变成猜谜，阶段 4 的对账会变成吵架。 平台会消失，这不是假设。Universal Analytics 在 2023-07-01 停止处理命中，2024-07-01 删除数据；360 属性有一次延期到 2024-07-01，BigQuery 历史回填请求截止 2024-06-30[GA4 替代说明](https://support.google.com/analytics/answer/11583528?hl=en)。Contentsquare 在 2023-12-07 完成对 Heap 的收购[收购公告](https://contentsquare.com/press/contentsquare-completes-acquisition-heap/)。Amplitude 在 2025-07-10 收购 Kraftful[Amplitude 公告](https://amplitude.com/press/amplitude-acquires-kraftful)。并购期的风险不是产品立刻消失，而是 roadmap、合同主体、数据区域、支持团队一起变。 双写有三个容易忽略的细节。第一，同一 `event_id`：旧管道和新管道写同一个 ID，才能做去重对账，不要让两边各自生成 UUID。第二，影子读：新平台先只读，跑 2–4 周历史查询对比，用同一批看板 SQL 比较结果和耗时。第三，分层对账：总行数、事件名、用户与会话、指标，越往下越难，但越能定位问题。 回滚不是“再切回去”这么简单，要满足三个条件。旧管道还在写，或至少还能写，否则切回去只能恢复旧数据，恢复不了切换期间的新数据。新数据能反向导出，切换期间写进新平台的事件要能按时间窗导出并灌回旧平台，否则回滚会丢一段。看板有双版本，同一张看板在两边都有定义，切读时只改路由，不改语义。回滚演练要在切读前做。 | 类别 | 检查项 | 验收证据 | |---|---|---| | 盘点 | 事件字典含 owner、触发时机、属性类型、PII 标记；身份映射可导出 | 评审记录与导出样例 | | 映射 | 时区、空值、枚举、金额精度有明确规则 | mapping sheet | | 双写 | 两条管道使用同一 event_id | 抽样比对报告 | | 回填 | 历史数据按天、按事件名对账，字节数一致 | 批次记录 | | 对账 | 计数、去重、指标三层差异低于 1% 且可解释 | 对账报告 | | 切读 | 回滚开关能在 1 小时内切回 | 演练记录 | | 合同 | 原始事件、身份映射、看板定义可全量导出；删除有 SLA 与证明 | 导出与删除演练 | 采购时就要把退出条款写清楚：原始事件能否全量导出，格式、频率、是否含 schema；导出是否收费、是否限速；删除是否有证明、多少天内完成、备份是否包含；身份映射能否导出，这是最容易被锁死的资产；看板、漏斗、人群定义能否导出为 SQL 或 JSON；停服或被收购时的过渡期与支持义务。 > **判断**：迁移的难点是历史语义，不是数据搬运。不能导出原始事件和身份映射的平台，迁移成本会高于重新采集；把退出能力写进合同，比压价更能降低长期 TCO。 ## 10.11 三套参考架构：三种规模，三种组织 三套方案都假设：事件 1 KB、压缩 4 倍、留存 12 个月、按 ClickHouse Cloud 公开计价；实际要按自己的事件大小、查询模式、合规要求重算。成本是基础设施估算，不含人力。 | 档位 | 事件量 | 均值与峰值 | 核心组件 | 月成本（估算） | 团队 | 关键风险 | |---|---|---|---|---|---|---| | 轻量 | 少于 1 亿/月 | 38/秒、190/秒 | 单节点 ClickHouse 或 SaaS | 400–700 美元 | 1–2 人兼职 | 单点故障、备份 | | 标准 | 10 亿/月 | 386/秒、1,930/秒 | Kafka 加 Flink 加 ClickHouse 6 节点 | 2,500–4,000 美元 | 2–3 人 | 热分区、合并、状态 | | 超大 | 100 亿/月 | 3,858/秒、19,300/秒 | Kafka 分层加 Flink 加多套 ClickHouse 加 Iceberg | 16,000–22,000 美元 | 6–10 人 | 元数据、恢复、成本 | ### 轻量：少于 1 亿事件/月 假设 330 万/天、38/秒均值、峰值 190/秒；少于 50 个租户；12 个月留存；1–2 名兼职运维。 首选 SaaS，除非数据主权不允许。PostHog 公开的云区域是美国弗吉尼亚和欧盟法兰克福，选之前先确认数据驻留要求[PostHog 定价](https://posthog.com/pricing)。自建最小栈是单节点 ClickHouse（4 vCPU、16 GB、500 GB SSD）加 S3 备份加 Metabase 或 Superset；采集用 Snowplow Collector 或自建 Go 服务；不引入 Kafka 和 Flink。如果必须实时，用 ClickHouse Kafka Engine 直接消费，不上 Flink。 自建约 400–500 美元/月，主要是 ClickHouse Basic 2 units 的 320 美元与应用监控；SaaS 按量可能接近 700（估算）。 失败模式是单节点磁盘满、没有副本、schema 变更没有回滚。这个档位最值得投入的不是性能，而是备份演练和 schema 版本管理。 ### 标准：10 亿事件/月 假设 3,300 万/天、386/秒均值、峰值 1,930/秒；200 个租户；12 个月留存；2–3 名平台工程师。 采集用 3 个无状态 collector，前面放负载均衡或 API Gateway，write key 加租户限流。队列用 Kafka 3 broker，按 `tenant_id` 加 `user_id` 分区，保留 7 天。流处理用 Flink 2–4 个 TaskManager，做 enrichment、session、identity 查表；checkpoint 1 分钟，状态放 RocksDB 加 S3。存储用 ClickHouse 3 分片乘 2 副本（6 节点，16 vCPU、64 GB），事件表按月分区，TTL 12 个月；聚合表用 AggregatingMergeTree。查询层加查询网关，做每租户并发与扫描字节上限，Top 20 看板走预聚合。治理层配 schema registry、dead-letter、对账任务、成本看板。 成本约 2,500–4,000 美元/月：ClickHouse 约 1,900 美元，Kafka、Flink、应用约 1,000–2,000 美元，另加人力。 失败模式是大租户热分区、合并落后、Flink 状态膨胀、双写期间成本翻倍。这个档位最常见的返工是“先上实时，后发现 80% 查询是 T+1”，于是流处理变成昂贵的 ETL。把 Kafka 保留期拉到 90 天当归档，最后会在扩容、恢复、跨区复制上一起付钱。 ### 超大：100 亿以上事件/月 假设 3.3 亿/天、3,858/秒均值、峰值 19,300/秒；1,000 个以上租户；24 个月热数据加 7 年归档；6–10 名平台工程师。 队列用 Kafka 6 个以上 broker，开 tiered storage（本地 6 小时，远端 7 天），按租户做配额，避免单租户打满。流处理用 Flink 集群（10–20 个 TaskManager），RocksDB 增量 checkpoint；身份解析改为“流内查表加离线图计算”，不把全图放状态。存储用三套 ClickHouse：热集群 30 天明细，高配，服务实时看板；温集群 12–24 个月明细，低配，服务下钻；冷层用 S3 或 Iceberg 归档，按需回灌。多租户上，大租户独立 compute service 或独立库，小租户共享加 workload group，查询网关做准入控制。预聚合覆盖 Top 50 指标的日、小时聚合，长尾查询走明细加采样。治理层做数据质量、血缘、成本归因、租户级 SLO。 成本约 16,000–22,000 美元/月：ClickHouse 约 11,600 美元，Kafka、Flink、S3、应用约 5,000–8,000 美元，另加人力。 失败模式是热分区、合并与副本恢复、元数据瓶颈、跨区出口、成本失控。到了这个量级，一次全量回填可能就是几十万美元的计算，变更管理必须比代码发布更严格。三套架构的组织含义也不同：轻量买“不用建团队”，标准买“团队能维护”，超大买“组织能治理”；差别在值班、变更、成本和权限的制度密度。 > **判断**：到了 100 亿/月，最大的成本优化不是换引擎，而是少存、少扫、少复制。采样、TTL、预聚合、冷热分层这四件事，比选 ClickHouse 还是 Doris 影响大一个数量级。 ## 参考来源 - [ClickHouse Pricing](https://clickhouse.com/pricing) - [Manage data with TTL (ClickHouse)](https://clickhouse.com/docs/guides/developer/ttl) - [CREATE VIEW (ClickHouse)](https://clickhouse.com/docs/sql-reference/statements/create/view) - [ReplacingMergeTree table engine (ClickHouse)](https://clickhouse.com/docs/engines/table-engines/mergetree-family/replacingmergetree) - [Parametric aggregate functions (ClickHouse)](https://clickhouse.com/docs/sql-reference/aggregate-functions/parametric-functions) - [A practical introduction to primary indexes in ClickHouse](https://clickhouse.com/docs/guides/clickhouse/data-modelling/sparse-primary-indexes) - [PostHog pricing](https://posthog.com/pricing) - [How PostHog works: ClickHouse](https://posthog.com/docs/how-posthog-works/clickhouse) - [Snowplow Limited Use License FAQ](https://docs.snowplow.io/docs/licensing/limited-use-license-faq/) - [Introducing the Snowplow Limited Use License Agreement](https://snowplow.io/blog/introducing-snowplow-limited-use-license) - [Set up Snowplow Self-Hosted](https://docs.snowplow.io/docs/get-started/self-hosted/) - [Configure your Snowplow pipeline](https://docs.snowplow.io/docs/pipeline/) - [Introduction to the atomic events table (Snowplow)](https://docs.snowplow.io/docs/fundamentals/warehouse-tables/) - [KIP-98: Exactly Once Delivery and Transactional Messaging](https://cwiki.apache.org/confluence/display/KAFKA/KIP-98+-+Exactly+Once+Delivery+and+Transactional+Messaging) - [KIP-405: Kafka Tiered Storage](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405:+Kafka+Tiered+Storage) - [Stateful Stream Processing (Flink)](https://nightlies.apache.org/flink/flink-docs-stable/docs/concepts/stateful-stream-processing/) - [Fault Tolerance Guarantees of Data Sources and Sinks (Flink)](https://nightlies.apache.org/flink/flink-docs-stable/docs/connectors/datastream/guarantees/) - [Materialized View Overview (Apache Doris)](https://doris.apache.org/docs/query-acceleration/materialized-view/overview) - [Async Materialized View Overview (Apache Doris)](https://doris.apache.org/docs/query-acceleration/materialized-view/async-materialized-view/overview) - [Query Cache (StarRocks)](https://docs.starrocks.io/docs/using_starrocks/caching/query_cache/) - [Query queues (StarRocks)](https://docs.starrocks.io/docs/administration/management/resource_management/query_queues/) - [BigQuery pricing](https://cloud.google.com/bigquery/pricing) - [Snowflake pricing options](https://www.snowflake.com/en/pricing-options/) - [Amazon S3 pricing](https://aws.amazon.com/s3/pricing/) - [Guidance for Clickstream Analytics on AWS](https://aws.amazon.com/solutions/implementations/clickstream-analytics-on-aws/) - [GA4 BigQuery Export](https://support.google.com/analytics/answer/9358801?hl=en) - [Google Analytics 4 has replaced Universal Analytics](https://support.google.com/analytics/answer/11583528?hl=en) - [Contentsquare Completes Acquisition of Heap](https://contentsquare.com/press/contentsquare-completes-acquisition-heap/) - [Amplitude is acquiring Kraftful](https://amplitude.com/press/amplitude-acquires-kraftful) - [EUR-Lex: GDPR full text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679) - [CNIL: EDPB adopts guidelines on ePrivacy tracking scope](https://www.cnil.fr/fr/le-cepd-adopte-des-lignes-directrices-pour-clarifier-la-notion-de-tracage-de-la-directive-eprivacy) - [CNIL: cookie exemptions for audience measurement tools](https://www.cnil.fr/fr/cookies-solutions-pour-les-outils-de-mesure-daudience) - [Google Analytics: Consent Mode](https://support.google.com/analytics/answer/10000067) - [Google Analytics: IP handling for EU, Switzerland and UK](https://support.google.com/analytics/answer/12017362) - [Heap: Security and Privacy](https://www.heap.io/platform/security) - [CAC: 促进和规范数据跨境流动规定](https://www.cac.gov.cn/2024-03/22/c_1712776611775634.htm) - [中国人大网: 个人信息保护法](http://www.npc.gov.cn/npc/c2/c30834/202108/t20210820_313088.html) - [GrowingIO: 私有化部署](https://www.growingio.com/solutions/Private) --- # 11 · 选型与落地：买什么、建什么、先做什么 > 选型不是选功能最多的，而是选“事件语义、数据主权、退出能力”最匹配的；90 天也不是上线所有看板，而是用两个真实决策证明数据可信。 这一章不给“买哪一家”的答案，而给一套可复核的排除顺序：先过红线，再打分，再算三年 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` [来源](https://posthog.com/docs/data/identify) [来源](https://docs.snowplow.io/docs/identities/concepts/unique-identifiers/) [来源](https://amplitude.com/docs/data/data-assistant-user-solutions/cross-device-identity-engineering)。不能处理“不合并”的系统，最终一定会制造无法解释的重复用户。 **第四，warehouse-native 要分清下推、导入、导出。** Amplitude 的 Snowflake Native 把查询下推到客户仓库，数据不出域；Mixpanel 的 Warehouse Connectors 把仓库数据导入 Mixpanel；Heap Connect、Pendo Data Sync 是导出 [来源](https://amplitude.com/releases/warehouse-native-ga) [来源](https://docs.mixpanel.com/docs/tracking-methods/warehouse-connectors)。三种架构的成本、延迟与退出方式完全不同。采购时让厂商画出数据流，不要只听“我们支持 Snowflake”。 **第五，按“量随什么增长”选计价单位。** 事件量随版本发布增长，MAU 随投放增长，会话随回放与移动端增长。选错计价单位，旺季账单会替你做决定。合同要锁三件事：计价单位、超量单价、续约涨幅上限。 **第六，把回放留存当成第二条价格曲线。** “12 个月回放”通常不是默认能力：PostHog 免费层 1 个月、付费层 90 天，12 个月要买 Boost/Scale；Mixpanel Free/Growth 只有 30 天，7–365 天要进 Enterprise；Amplitude 默认 1 个月，延长是加购 [来源](https://posthog.com/platform-packages) [来源](https://mixpanel.com/pricing/) [来源](https://amplitude.com/pricing)。回放留存通常是单独加购项，且与录制量分开计价，报价单里常写成“高级功能”。 **第七，AI 功能按“读、解释、建议、写”四级评估。** 能读表、能解释图表、能建议动作、能直接写回人群/实验/配置，是四种风险等级。前三级的错误可以纠正，第四级的错误会直接改变用户看到的东西。要求厂商演示“谁批准、怎么回滚、日志在哪里”。 **第八，开源不是“免费版 SaaS”。** 开源省 license，不省 SRE、升级、备份、安全与合规。PostHog 官方把自托管列为“不支持”，Snowplow 自 2024 年起改用 Limited Use License，生产高可用要商业许可 [来源](https://posthog.com/docs/self-host) [来源](https://snowplow.io/blog/introducing-snowplow-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 折算，仅作量级比较 [来源](https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm)。 | 场景 | 采购（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 万美元 [来源](https://posthog.com/pricing) [来源](https://mixpanel.com/pricing/) [来源](https://votefirst.app/en/pricing/amplitude)。三年 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 万元 [来源](https://ebs.szse.cn/cmschengjiaogg/11387.html) [来源](https://www.jinrongzhaobiao.com/news-645f2defdcce5b499ac0973746f8ed76/)。它们对应私有化、有限项目数与一年服务，不能直接换算成国际 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. 是否支持虚拟事件/派生属性？口径变更是否留痕？ **身份与会话** 5. 匿名 ID、登录 ID、设备 ID、账户 ID 的合并顺序是什么？ 6. 共享设备、家庭账号、一人多账号时，如何选择不合并？能否回滚？ 7. 会话超时、前后台、跨天、深链的默认规则是什么？能否版本化重算？ 8. 登出、撤回同意、删除用户后，身份图如何更新？ **分析与行动** 9. 漏斗的有序/无序、窗口、排除、分组默认值是什么？能否导出查询定义？ 10. 留存的 cohort、N-day/unbounded/rolling 口径是什么？右删失怎么处理？ 11. 人群规模、更新频率、身份覆盖率是多少？能否下发到实验/引导/CRM？ 12. 实验曝光是否与分析事件共用同一身份与时间线？能否做 holdout？ **治理与合规** 13. 数据区域有哪些？备份、日志、AI 推理分别在哪里？ 14. 是否支持行级权限、SSO/SCIM、导出审计、管理操作日志？ 15. 删除请求的 SLA 是什么？备份何时删除？能否提供证明？ 16. 客户数据是否用于训练模型？能否关闭？关闭后功能有何变化？ **商业与退出** 17. 计价单位是什么？超量单价、续约涨幅上限、账单封顶能否写进合同？ 18. 回放留存、SSO、审计、区域存储、AI 用量是否另收费？ 19. 控制权变更时，客户是否有终止权？迁移支持期多长？ 20. 能否在签约前做一次完整导出演练？迁移费用谁承担？ ### 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 · 控制力—分析深度矩阵：位置为示意，不是厂商评分](/assets/diagrams/selection-matrix.svg) > **判断**：选型的终点不是“选了谁”，而是“组织是否具备了持续定义、验收、复盘事件的能力”。工具可以换，这套能力换不掉。 ## 11.8 季度复盘：让选型变成持续动作 选型不是一次性采购，而是每季度一次的复盘。建议固定四个问题：第一，过去 90 天有哪些决策是因为数据改变或加速的？第二，哪些指标被重新定义过，为什么？第三，哪些事件没有人用，能否下线？第四，账单与事件量的关系是否可解释？四个问题都答不上来，说明平台正在退化成报表仓库。 复盘要有输出：下季度要下线的事件清单、要补的验收规则、要谈的合同条款、要做的迁移演练。没有输出的复盘，会变成“大家辛苦了”的例会。 把“退出演练”放进年度计划：每年选一个非核心业务，尝试把事件、身份、人群、查询迁移到备选方案，记录时间、成本与数据差异。演练不是为了真的换厂商，而是为了知道换的时候会发生什么。不能带走的资产，在合同签字那天就已经失去了。 ## 参考来源 - [PostHog — Identify](https://posthog.com/docs/data/identify) - [Snowplow — Unique Identifiers](https://docs.snowplow.io/docs/identities/concepts/unique-identifiers/) - [Amplitude — Cross-device Identity](https://amplitude.com/docs/data/data-assistant-user-solutions/cross-device-identity-engineering) - [Amplitude — Warehouse Native GA](https://amplitude.com/releases/warehouse-native-ga) - [Mixpanel — Warehouse Connectors](https://docs.mixpanel.com/docs/tracking-methods/warehouse-connectors) - [PostHog — Platform Packages](https://posthog.com/platform-packages) - [Mixpanel — Pricing](https://mixpanel.com/pricing/) - [Amplitude — Pricing](https://amplitude.com/pricing) - [PostHog — Pricing](https://posthog.com/pricing) - [PostHog — Self-host](https://posthog.com/docs/self-host) - [Snowplow — Limited Use License](https://snowplow.io/blog/introducing-snowplow-limited-use-license) - [BLS — Software Developers](https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm) - [深交所 — 神策分析系统成交公示](https://ebs.szse.cn/cmschengjiaogg/11387.html) - [中国大地保险 — 埋点分析系统招标](https://www.jinrongzhaobiao.com/news-645f2defdcce5b499ac0973746f8ed76/) - [GA4 — Data Retention](https://support.google.com/analytics/answer/7667196?hl=en) - [GA4 — BigQuery Export](https://support.google.com/analytics/answer/9358801?hl=en) - [PIPL 全文](https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm) - [数据跨境流动规定](https://www.cac.gov.cn/2024-03/22/c_1712776611775634.htm) - [NIST — Privacy Framework](https://www.nist.gov/privacy-framework) - [PostHog — Session Replay Privacy](https://posthog.com/docs/session-replay/privacy) - [Mixpanel — Session Replay Privacy](https://docs.mixpanel.com/docs/session-replay/session-replay-privacy-controls) - [Amplitude — Session Replay Privacy](https://amplitude.com/docs/session-replay/manage-privacy-settings-for-session-replay) - [Snowplow — Schema Versioning](https://docs.snowplow.io/docs/event-studio/data-structures/versioning/) - [GA4 — Event Naming](https://support.google.com/analytics/answer/13316687?hl=en) - [Flink — Delivery Guarantees](https://nightlies.apache.org/flink/flink-docs-stable/docs/connectors/datastream/guarantees/) - [ClickHouse — ReplacingMergeTree](https://clickhouse.com/docs/engines/table-engines/mergetree-family/replacingmergetree) - [Pendo — Data Sync](https://support.pendo.io/hc/en-us/articles/18214274061595-Overview-of-Pendo-Data-Sync) - [Heap — Connect](https://www.heap.io/platform/connect) - [Adobe — Customer Journey Analytics](https://helpx.adobe.com/legal/product-descriptions/customer-journey-analytics.html) - [votefirst — Amplitude pricing](https://votefirst.app/en/pricing/amplitude)