开源方案（上）：从 PostHog 到 Snowplow，谁能真正替掉 SaaS

先把结论放在前面。2026 年，能真正替掉一部分 SaaS 的开源项目只有三类：把托管做成主产品、用开源换信任的一体化平台（PostHog）；把 schema 与管道做成别人难以复制的数据基础设施（Snowplow、RudderStack）；以及只替代一个模块、但替代得很彻底的工具（Matomo、OpenReplay、Plausible）。除此之外，“开源”更多是一种采购姿态，不是交付能力。代码可以下载，事件语义、升级路径、CVE 响应和合规责任不能。

这也是本章与功能评测的区别。我们不打勾，而是回答三个问题：这个项目的 license 允许你做什么；社区版与企业版之间被切走的是哪一块；以及当它跑到 1,000 万、1 亿、10 亿事件/月时，账单和值班表长什么样。

6.1 开源地图：三条产品线，四种“开源”#

把 PostHog、Snowplow 和 OpenReplay 放进同一张漏斗功能表，是最常见的起手错误。它们根本不在卖同一种东西。

这张表解释了一个常见误判：Snowplow 的客户名单里有很多大品牌，但它不提供开箱即用的漏斗界面；PostHog 的漏斗很好用，但数据默认留在 PostHog Cloud，而不是你的 Snowflake。前者的分析能力取决于你仓库里的 dbt 模型，后者的代价是数据位置由厂商决定。

判断：先确定你要买的是“分析产品”还是“数据基础设施”，再比较功能。前者看分析体验与计价单位，后者看 schema 治理、投递语义与仓库成本；两者的选型标准几乎不重叠。

License 是第二道分水岭，而且比功能表更能决定“能不能用”。行业里说的“开源”至少有四种含义，对应四种完全不同的风险。

Snowplow 最容易被误读。GitHub 根目录的 LICENSE 仍是 Apache-2.0，但仓库 README 写明：2024-01-08 起，新版本核心管道改用 Snowplow Limited Use License，并且不再为 2024 年 1 月前的版本提供安全补丁。官方 licensing 页面把组件拆得很细，结论是：今天的 Snowplow 不是“Apache-2.0 的 Snowplow”。只看仓库首页的 license 徽章，会得出相反结论。

RudderStack 的 LICENSE 是 Elastic License 2.0：可以内部使用、修改、分发，但不得把软件作为托管或管理服务提供给第三方，也不得绕过 license key。Jitsu 在自己的对比页里把这一点当卖点：“RudderStack 的 license 禁止你把管道放进自己的产品里，MIT 不会。”这句话是竞品口径，但条款本身可以核对。

Countly 的条款更微妙。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 轮，估值 9.2 亿美元，Stripe 领投；同年 9 月 29 日宣布、10 月完成 7,500 万美元 E 轮，估值 14 亿美元，Peak XV Partners 领投。官方史页称截至 2025-10 累计融资约 1.94 亿美元（Hogpedia）。一年两轮、估值涨约五成，说明资本市场买的不是“又一个开源分析工具”，而是它把多个产品塞进同一套事件模型的能力。

产品形态。 模块包括 Product Analytics、Web Analytics、Session Replay、Feature Flags、Experiments、Surveys、Error Tracking、LLM Observability、Data Warehouse、CDP，以及 2026 年初的 PostHog Desktop。真正的差异不是模块数量，而是它们共享 person/event 模型：同一个用户可以从趋势图下钻到回放、Flag 和实验，不需要跨工具拼 ID。对 5–50 人的产品团队，这种“一个合同解决五件事”的体验，通常比自建快得多。

数据与架构。 官方架构文档写得很具体：Django 负责 Web 与 API，Rust 服务负责 capture、flags、replay，Kafka（云上用 WarpStream）做总线，ClickHouse 存事件与分析，Aurora PostgreSQL 存元数据，Redis/Valkey 做缓存，S3 存放回放与导出。这套栈的性能上限很高，但运维复杂度被云服务隐藏了；自建意味着你要同时维护 ClickHouse、Kafka、Postgres 和对象存储四套系统。

计价。 按产品用量计费，无座位费。官方定价的产品分析部分：每月前 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 年；而平台包页面显示，免费层回放只留 1 个月、付费层默认 90 天，要 12 个月回放得买 Boost（$250/月）或 Scale（$750/月）。其二是治理能力单独收费：SSO、SCIM、审计日志这些企业采购的硬门槛，落在 Boost/Scale 平台包里，而不是随事件量附送。把回放与平台包一起算，1,000 万事件/月的年费会从 $3,888 升到接近 1 万美元量级。

自托管是最大的误解。 PostHog 的代码是 MIT（ee/ 除外），理论上可以自建；但官方文档明确写：自托管“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。官方管道文档把这个流程描述为 collect → validate → enrich → good/bad stream → warehouse/BI。

它的核心资产是 schema，不是代码。 每个事件是 canonical event 加 self-describing JSON，带 entity/context、schema 版本与校验。原子事件落到客户自己的仓库，因此可以重跑、回填、用任意 SQL 重新定义指标。这是它相对一体化分析工具的真正优势：分析口径可以随业务变化重算，而不是被厂商的报表模型锁死。代价是分析界面不存在——漏斗、留存、路径都要在 dbt 或 BI 里自己建。

License 把组件切成了四块。 这是采购时最该逐项核对的地方：

也就是说，你可以免费使用 tracker 采集，但要把事件送进生产仓库，Collector、Enrich 和 Loader 都需要商业授权。2024-01-08 是这条线的分水岭：此前的版本不再获得安全补丁，此后的核心管道不再允许生产使用。很多中文资料仍停留在“Snowplow 是 Apache-2.0”，这是本章最需要纠正的过时印象。

商业变化。 2025-05-28 发布 Signals，从“管道”扩到实时受众与触发；2026 年把叙事改为“Customer Context Infrastructure”，面向 AI Agent 提供实时上下文。官方 Newsroom 连续公布 Snowflake、Databricks、AWS 的伙伴奖项，属于厂商口径（B）。这些动作说明它在向上走：不再只卖“把事件送到仓库”，而是卖“仓库里的行为数据能被实时调用”。

定价。 定价页只给 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。产品概念很少：Sites 是推送源，Destinations 是目的地，Connectors 是拉取源（主要是 Airbyte 连接的封装），Functions 用 TypeScript/JavaScript 在事件飞行途中做过滤、富化、路由。它不做分析界面，只把事件送到 PostHog、GA4、Amplitude、ClickHouse、BigQuery 等下游。部署有 Cloud、Dedicated、自托管三档，官方称每一档都可自托管；自托管推荐 Kubernetes + Helm，文档提到 operator 与 function servers（self-hosting）。

它的计价口径值得单独说：按“active event”计费，只有成功送到至少一个目的地的事件才算；被采集但没有投递的事件不计费。定价页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。产品包括 Event Stream（Sources/Destinations）、Transformations（JS/Python）、Tracking Plans、Data Catalog、Profiles（仓库内身份图谱与特征）、Audiences、Lookout（数据质量与异常监控），2026 年又加了 RudderAI，用自然语言操作管道与治理。

架构是控制面与数据面分离：控制面是 SaaS 的 UI 与配置后端；数据面用 Go 编写，依赖 PostgreSQL 做临时事件队列，流程是 Gateway → Processor → Transformation → Router，事件成功投递后从库中删除，官方称“不持久化事件、不存储用户信息”（架构文档）。Profiles 则把身份图谱与特征计算下推到仓库。部署上，数据面可以放在 RudderStack Cloud（US/EU）或客户 VPC，控制面仍在厂商手里。

定价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，商标注册，商业云与插件包由 Matomo 团队运营。官方口径是 140 万网站、190 多个国家，2025 年通过 ISO 27001:2022（About）。它的强区是欧洲、医疗、政府、教育——这些买家首先问“数据在哪里”，然后才问“有没有漏斗”。

功能广度在开源 Web 分析里属于最大的一档：访问统计、目标与电商、漏斗、Users Flow、cohorts、多渠道路径、热图、会话录制、A/B 测试、表单分析、媒体分析、站内搜索、Tag Manager、同意管理、自定义维度、API。Cloud 数据存放在德国法兰克福（定价页），这对数据出境敏感的欧洲客户是直接卖点。

架构决定了它的上限。 数据模型以 pageview/visit/action 为中心，MySQL/MariaDB 存原始日志，报表通过 core:archive 定时预计算成归档表。中小流量下这套模型很稳；大流量下，归档会成为日级任务。官方自动归档文档写得很直白：访问量到“几百/天”以上就建议 cron 每小时跑，数据量大时一次归档“数小时，甚至一天”。这不是配置问题，是 PHP/MySQL 架构的物理约束。

定价。 Cloud 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），大版本节奏偏慢。二是 2026-09-01 推出 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，后端 Next.js/Node，主库 PostgreSQL 12.14+，Docker Compose 可一键起。2025-11-06 的 v3 是转折点：此前它只是轻量 Web 统计，此后补上漏斗、留存、journeys、cohorts、归因、收入；v3.1/v3.2 把热图与会话回放放进自托管，v3.3 加双因素与会话身份拼接，v3.4 加标注、MCP、API key（Blog）。Cloud 定价 Free 每月 10 万 events，Pro $20/月含 100 万，Business $200/月含 1,000 万，回放 $0.005/条，自托管免费。

它的计价有一个细节：pageview、自定义事件、事件属性都计入事件量。埋点越细，账单越高，这一点在选型时经常被低估。功能上，它没有 Flag/实验，权限与审计弱，PostgreSQL 单库有规模上限；Cloud 与 self-host 也有功能差，email reports 只在 Cloud 提供（Cloud 对比）。但对静态站、内容站和小团队，它是这九家里性价比最高的一个。

Plausible：把“极简”做成一种资本结构。 核心 AGPL-3.0，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）。它明确不做回放、热图、实验、CDP。

更值得注意的是它的规模口径：官方首页称 21,000 个付费订阅、313B 页面浏览、10 人团队、自筹资金、盈利（Plausible）。在一个融资新闻密集的赛道里，这是一个反例——不靠融资扩张，靠低客单价和高毛利活下来。代价是功能窄、高流量档价格不透明、CE 明确“community supported”（README），自托管要同时维护 PostgreSQL 与 ClickHouse。

Countly：移动端组合最完整的一档，license 最需要法务。 核心 AGPL-3.0 改 Section 7，要求保留品牌；另有 Flex/Enterprise 商业版。产品覆盖 Advanced Analytics、Adaptivity（A/B、远程配置、推送、应用内消息）、Intelligence（预测与分群）、Crash/Error、User Journeys、Cohorts，官方称 70+ 功能（定价页）。传统 Lite 是 Node.js + MongoDB 的插件式架构；2026-10-01 发布的 26.01 新架构改为“事件流 + 分析型存储 + 分布式查询”，官方宣称支持 1 亿 MAU、十亿级事件，但未公开具体组件。

部署上，Lite 自托管免费；Flex 是私有云，$175/月起，按用量而非座位计费；Enterprise 完全 on-prem，零厂商访问。它的优势是移动/推送/崩溃/远程配置的组合在开源里少见，且私有化彻底；风险是 license 表述冲突——LICENSE 是 AGPL 加品牌条款，README 却写“non-commercial”，商用前必须让法务确认。26.01 的新架构组件不透明，迁移与稳定性也待验证。

OpenReplay：把回放做成可自托管的基础设施。 核心 AGPL-3.0，部分目录 MIT，ee/ 商业许可。产品以 session recording 为中心：DOM 快照与增量、网络请求、控制台日志、source map、协同浏览（Assist）、热图、漏斗、Spot bug 报告。自托管用 Docker Compose 或 Kubernetes/Helm，单机最低 2 vCPU/8 GB/50 GB，官方建议 t3.large 起步（部署文档）。第三方技术拆解称后端为 Go、使用 ClickHouse/Kafka，官方部署页未逐项列明，这条标 C/待核实。

定价自托管免费；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）。它依然不适合作为新产品的主分析平台，但这个例子说明：用“最后一次 commit”判断项目死活，和用 star 判断质量一样不可靠。

轻量段正在分叉。Umami 与 Plausible 卖低 TCO 与隐私，Countly 与 OpenReplay 卖一个可私有化的单模块。它们都能替掉 SaaS 的某一块，没有一家能替掉整套；把它们当“PostHog 平替”，选型会在第三个模块上失败。

6.7 能力对比：功能表之外，看身份与治理#

下面三张表覆盖能力、版本切分与隐私。需要先说明口径：“强/中/弱”是这九家之间的相对比较，不是与全部商业 UBA 比较；Countly 的回放能力官方页面未明确列出，标“待核实”而不是想当然。

这张表最能预测迁移成本的，不是“事件分析”列，而是“治理”列。Snowplow 的 Iglu schema 与 RudderStack 的 Tracking Plans 是资产，迁出时最难，因为事件定义、版本和校验规则都在里面；PostHog、Umami、Plausible 的事件命名靠人，迁出容易，但治理弱；Matomo 与 Countly 的身份模型绑定 cookie/device，跨端合并要额外做。如果你的痛点是“同一用户在 App、小程序、Web 上对不上”，先解决身份，不要先换分析 UI。

第二张表是版本切分。开源项目的“免费”通常不是“功能少一点”，而是“关键能力被切走”。

第三张表是回放与隐私。回放是隐私风险最高的模块，而“无 cookie”只解决标识问题，不解决事件属性里的 PII。

判断：如果法务问“分析工具会不会录到用户密码”，先看回放配置，再看 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/年。

这张表只算现金，不含迁移、双跑、功能缺口与回放存储。回放是另一条成本曲线：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 年的理性选择仍是托管服务；开源只作为数据出口与降级方案，而不是主平台。三个条件同时成立时——已有平台团队、事件量足够大、愿意用自建替换掉一部分产品功能——自建才可能划算。缺一个，托管通常更便宜。