1. 选型之前先想清楚你到底在解决什么问题很多团队在选埋点平台的时候第一反应是拉一张功能对比表把神策、PostHog、ClkLog 以及各种开源数据栈的功能逐项打勾然后看谁勾得多就选谁。我见过不止一个团队这么干结果上线三个月后开始骂娘——要么是数据量一上来成本失控要么是业务方想查个漏斗要等数据团队排期三天要么是 SDK 接入之后 App 包体积涨了一大截被用户投诉。问题出在哪出在把“功能表”当成了选型依据而忽略了一个更根本的问题你当前阶段的核心矛盾是什么。埋点平台这个东西本质上解决的是“用户行为数据的采集、存储、查询、分析”这条链路。但不同团队在这条链路上的瓶颈完全不同。一个日活几千的早期产品瓶颈可能是“没人写埋点代码”一个日活百万的成熟产品瓶颈可能是“每天几十亿条事件怎么低成本存下来还能秒级查询”一个强合规要求的业务瓶颈可能是“数据必须留在自己机房”。这三种情况对应的选型答案完全不一样。所以这篇文章不打算给你一张万能的功能对比表而是想把这几个主流方案——神策、PostHog、ClkLog、以及基于开源组件自建的数据栈——各自适合什么场景、背后的技术取舍是什么、实际落地时会踩哪些坑掰开揉碎讲清楚。你看完之后应该能自己判断该选哪个而不是照着别人的推荐抄作业。先给一个粗略的定位后面再展开方案一句话定位典型适用场景神策数据商业化全栈埋点分析平台中大型企业预算充足要开箱即用的分析能力PostHog开源产品分析全家桶中小团队要产品分析会话回放实验能接受云服务或自托管ClkLog轻量级开源埋点分析中小团队要私有化部署需求聚焦在基础行为分析开源数据栈自建完全自主可控的数据管道有数据工程能力的团队要深度定制和成本控制这张表只是起点真正做决策的时候你需要往下看每一层的细节。2. 神策数据功能最全但代价是什么2.1 神策的核心能力与适用边界神策在国内埋点分析这个领域算是老牌选手了它的产品矩阵覆盖了事件分析、漏斗分析、留存分析、用户路径、归因分析、LTV 预测等几乎你能想到的所有分析模型。底层是自研的存储和查询引擎支持实时和离线两条链路。对于业务方来说最大的价值是“自助分析”——产品经理不需要写 SQL在界面上拖拖拽拽就能出报表。但神策的定价模式是按事件量阶梯计费而且通常是年付。这意味着什么意味着你的成本会随着业务增长线性甚至超线性上升。我见过一个日活大概五十万的产品每天产生的事件量在千万级别神策的年费报价在七位数。这个数字对于大厂来说可能不算什么但对于一个还在验证商业模式的中小团队来说基本等于把全年技术预算的一大半砸进去了。所以神策的适用边界其实很清晰你不缺钱你缺的是时间和人。如果你的团队没有数据工程师也没有精力去维护一套自建的数据管道业务方又天天催着要各种分析报表那神策确实能帮你省下大量的人力和时间成本。但如果你是一个精打细算的团队或者你的数据量已经大到按事件计费会让你肉疼那就得慎重了。2.2 神策接入的实操要点神策的接入方式分几种客户端 SDKiOS、Android、Web、小程序等、服务端 SDK、以及通过 API 直接上报。大部分团队会用客户端 SDK 做全埋点自定义埋点结合的方式。这里有一个实操中很容易踩的坑全埋点不是万能的。神策的全埋点也就是自动采集能帮你省去一部分手动埋点的工作但它采集的是控件的点击、页面的浏览这类通用事件对于业务语义强的行为比如“用户完成了实名认证”你还是得手动埋。而且全埋点会产生大量冗余事件直接推高事件量进而推高成本。我的建议是全埋点只用在关键路径的兜底上核心业务事件一律手动埋。手动埋点虽然前期工作量大但事件语义清晰、数据质量高、后续分析的时候不会因为事件命名混乱而抓狂。另外神策的埋点方案设计也就是事件和属性的命名规范一定要在接入前就定好。我见过太多团队接入的时候随便命名什么click_btn_1、event_2这种等到后面业务方要查数据的时候根本不知道这些事件对应什么行为。命名规范这件事前期花一天时间定好后面能省你无数天的排查时间。2.3 神策的成本控制技巧如果你已经决定用神策有几个控制成本的实操技巧第一合理设置采样率。不是所有事件都需要 100% 采集。比如一些高频的曝光事件采样 10% 或者 1% 就足够做统计分析了没必要全量上报。神策支持在 SDK 层面设置采样率这个功能一定要用起来。第二定期清理无效事件。产品迭代过程中很多旧版本的事件会逐渐废弃但 SDK 里可能还在上报。定期 review 事件列表把不再使用的事件下线能省下不少事件量。第三区分实时和离线需求。神策的实时查询成本比离线查询高如果某些报表不需要实时性可以配置成离线计算降低成本。3. PostHog开源产品分析的全家桶3.1 PostHog 的产品形态与核心优势PostHog 是这几年在海外社区很火的一个开源产品分析平台它的定位和神策不太一样——神策更像是一个专业的数据分析工具而 PostHog 更像是一个“产品团队的全家桶”。除了基础的埋点分析事件、漏斗、留存、路径它还集成了会话回放Session Replay、功能开关Feature Flags、A/B 实验Experiments、问卷Surveys等能力。这个全家桶的定位很有意思。对于产品团队来说你不需要在多个工具之间来回切换——看数据用 PostHog看用户录屏用 PostHog做实验也用 PostHog。数据是打通的比如你在会话回放里看到一个用户流失了可以直接跳到这个用户的事件流里看他在流失前做了什么操作。这种体验是割裂的工具组合给不了的。PostHog 的部署方式有两种Cloud 版官方托管和 Self-hosted 版自己部署。Cloud 版按事件量计费有免费额度Self-hosted 版是开源的你可以自己部署在服务器上但需要自己维护。3.2 PostHog 自托管的真实成本很多人看到“开源免费”四个字就兴奋了觉得自托管能省一大笔钱。但实际情况是PostHog 的自托管版本对硬件资源的要求不低。它依赖 ClickHouse 做事件存储、PostgreSQL 做元数据存储、Redis 做缓存、Kafka 做消息队列这一套下来一台 4 核 8G 的机器跑起来会很吃力推荐配置至少是 8 核 16G 起步而且随着事件量增长ClickHouse 的存储和计算资源需求会快速上升。我实测过在一台 8 核 16G 的云服务器上部署 PostHog 自托管版日事件量在百万级别的时候查询响应还算流畅到了千万级别一些复杂的漏斗查询就开始变慢了。如果你要支撑更大的量就得做 ClickHouse 集群这时候运维复杂度就上来了。所以 PostHog 自托管的真实成本不是“零”而是“服务器成本 运维人力成本”。如果你的团队没有熟悉 ClickHouse 和 Kafka 的运维人员自托管可能会变成一个无底洞。3.3 PostHog 的埋点接入与使用心得PostHog 的 SDK 覆盖很全Web、iOS、Android、React Native、Flutter、Node、Python 等主流语言和框架都有。接入方式也比较简单基本上几行代码就能跑起来。这里分享一个实操心得PostHog 的 autocapture 功能要慎用。和神策的全埋点类似autocapture 会自动采集页面上所有的点击事件虽然方便但会产生大量噪音数据。而且 autocapture 采集的事件属性比较通用缺乏业务语义。我的做法是关闭 autocapture只用手动埋点这样数据干净查询也快。另一个心得是关于会话回放的隐私问题。PostHog 的会话回放默认会录制用户的所有操作包括输入框的内容。如果你的产品涉及用户隐私数据比如手机号、地址、支付信息一定要配置好脱敏规则把敏感输入框屏蔽掉。这个在 PostHog 的配置里可以设置但很多人接入的时候会忽略。4. ClkLog轻量级开源埋点分析的务实之选4.1 ClkLog 的定位与技术栈ClkLog 是一个国产的开源埋点分析系统相比 PostHog 的全家桶定位ClkLog 更聚焦在“埋点数据采集 行为分析”这个核心链路上。它的技术栈相对轻量后端基于 ClickHouse 做事件存储和查询前端提供事件分析、漏斗分析、留存分析、用户画像等基础分析能力。ClkLog 最大的特点是部署简单、资源占用低。它不像 PostHog 那样依赖一大堆中间件一台 4 核 8G 的机器就能跑起来对于中小团队来说这个门槛低了很多。而且它是国产项目中文文档和社区支持对国内团队更友好。4.2 ClkLog 适合什么样的团队ClkLog 适合的团队画像很清晰中小规模、有私有化部署需求、分析需求聚焦在基础行为分析。比如你是一个做垂直领域 SaaS 的团队日活几万到几十万需要看用户的注册转化漏斗、功能使用留存、核心路径转化但不需要会话回放、A/B 实验这些高级功能那 ClkLog 是一个性价比很高的选择。但如果你需要更复杂的分析模型比如归因分析、LTV 预测或者需要和 CRM、营销系统做深度集成ClkLog 可能就不太够用了。它的分析能力相比神策和 PostHog 还是偏基础一些。4.3 ClkLog 部署与接入的实操细节ClkLog 的部署方式有 Docker Compose 和手动部署两种。推荐用 Docker Compose基本上几条命令就能把整套服务拉起来。但有几个细节需要注意第一ClickHouse 的资源规划。ClkLog 的查询性能高度依赖 ClickHouse所以 ClickHouse 的资源配置要合理。如果事件量比较大建议把 ClickHouse 单独部署在一台机器上和应用服务分开避免资源争抢。第二数据保留策略。ClickHouse 里的数据会随着时间不断累积如果不设置 TTLTime To Live磁盘很快就会被占满。ClkLog 支持配置数据保留天数建议根据你的分析需求设置合理的保留周期比如原始事件保留 90 天聚合数据保留更久。第三SDK 接入的事件命名。和前面说的一样事件命名规范一定要提前定好。ClkLog 的 SDK 支持自定义事件和属性接入的时候按照业务语义来命名后面分析的时候会顺畅很多。5. 开源数据栈自建完全自主可控的代价与回报5.1 自建数据栈的典型架构如果你对数据有完全的掌控欲或者你的数据量已经大到商业化方案的成本无法接受那自建数据栈是一个值得考虑的选项。典型的自建架构是这样的采集层客户端 SDK 或者服务端埋点把事件数据上报到采集网关传输层Kafka 或者 Pulsar 做消息队列缓冲流量峰值存储层ClickHouse、Doris、StarRocks 等 OLAP 数据库做事件存储查询层基于 OLAP 数据库的 SQL 查询能力自建查询服务展示层自建 BI 看板或者对接 Metabase、Superset、Grafana 等开源 BI 工具这套架构的每一层都有多种技术选型组合起来方案非常多。比如存储层ClickHouse 适合宽表和高吞吐写入Doris 和 StarRocks 在 join 查询上更强选哪个取决于你的查询模式。5.2 自建数据栈的关键技术决策自建数据栈有几个关键决策点每一个都会影响后续的运维复杂度和查询性能。第一个决策事件模型怎么设计。是宽表还是窄表宽表就是把所有属性都放在一张大表里查询快但灵活性差窄表是把事件和属性分开存储灵活但查询需要 join。大部分团队会选择宽表 物化视图的组合兼顾查询性能和灵活性。第二个决策分区和索引怎么建。ClickHouse 的分区键通常按日期来分索引一般用主键索引 跳数索引。分区粒度太细会导致小文件太多太粗又会影响查询裁剪效率。一般建议按天分区如果数据量特别大可以按小时分区。第三个决策数据保留和降采样策略。原始事件数据不可能永久保留通常的做法是原始数据保留 30-90 天之后降采样成聚合数据长期保留。比如把原始事件聚合成“每天每用户每事件的次数”这样数据量能压缩几个数量级。5.3 自建数据栈的隐性成本自建数据栈最大的坑是隐性成本。你看到的成本是服务器费用但看不到的成本包括人力成本至少需要一个数据工程师来维护这套管道包括 Kafka 的运维、ClickHouse 的调优、查询服务的开发时间成本从零搭建到稳定运行通常需要 2-3 个月这期间业务方是没法自助查数据的机会成本数据工程师的时间花在维护管道上就没时间做更有价值的数据建模和分析了所以自建数据栈适合的团队是有专职数据工程师、数据量足够大、对数据有深度定制需求。如果你只是“想省点钱”自建大概率会让你花更多。6. 四个方案横向对比一张表看清关键差异前面分别讲了四个方案的特点这里用一张表做一个横向对比方便你快速定位。对比维度神策数据PostHogClkLog开源数据栈自建部署方式SaaS 为主Cloud 自托管私有化部署完全自建核心优势分析模型全、开箱即用产品分析全家桶轻量、部署简单完全自主可控主要短板成本高、按量计费自托管运维复杂分析能力偏基础人力投入大适用规模中大型企业中小团队中小团队有数据工程能力的团队事件量成本线性增长较高Cloud 按量自托管看服务器服务器成本为主服务器人力成本数据主权云服务数据在厂商自托管可自主完全自主完全自主上手难度低中中低高定制能力有限中等中等完全可定制这张表不是让你直接照着选而是帮你快速排除明显不合适的选项。比如你如果明确要求数据必须留在自己机房那神策的 SaaS 版就直接排除了如果你没有数据工程师那自建数据栈也基本可以排除。7. 选型决策的实操框架7.1 三个问题帮你快速定位与其纠结功能对比不如先回答三个问题问题一你的数据必须私有化吗如果是神策 SaaS 版出局剩下 PostHog 自托管、ClkLog、自建数据栈三个选项。如果否四个都可以考虑。问题二你有专职的数据工程师吗如果没有自建数据栈出局PostHog 自托管也要慎重。剩下神策、PostHog Cloud、ClkLog 三个选项。问题三你的日事件量大概在什么量级百万级以下ClkLog 和 PostHog 都能扛千万级要考虑 PostHog 自托管的资源规划和 ClkLog 的 ClickHouse 调优亿级以上要么上神策如果预算够要么自建数据栈做深度优化。这三个问题回答完你的选项基本就收敛到一到两个了。7.2 混合方案的可行性实际落地的时候不一定非要二选一。我见过一些团队采用混合方案核心业务数据用神策做分析因为业务方需要自助查询原始事件数据同时落到自建的 ClickHouse 里供数据团队做深度分析和建模。这样既满足了业务方的自助需求又保留了数据的自主权。PostHog 和 ClkLog 也可以组合使用PostHog 做产品分析和会话回放ClkLog 做基础的行为数据看板。但要注意两套系统的事件命名和用户标识要统一否则数据对不上会很麻烦。7.3 选型后的迁移成本还有一个容易被忽略的点迁移成本。如果你现在用的是某个方案想换到另一个迁移的难度取决于你的事件数据模型和 SDK 接入方式。如果事件命名规范、用户标识体系是统一的迁移主要是数据导出和导入的工作如果各个系统的事件命名乱七八糟迁移就会非常痛苦。所以我的建议是无论选哪个方案事件命名规范和用户标识体系一定要统一规划。这是数据治理的基础也是未来换方案时能平滑迁移的前提。8. 常见问题与避坑指南8.1 埋点数据不准的排查思路埋点数据不准是最常见的问题排查思路一般是这样的第一步确认 SDK 是否正常上报。可以在客户端抓包看事件是否发到了采集网关。如果没发出去检查 SDK 初始化配置和网络权限。第二步确认采集网关是否正常接收。看网关的日志有没有报错或者丢弃。如果网关做了限流高峰期可能会丢数据。第三步确认存储层是否正常写入。查 ClickHouse 或者对应存储的表看事件是否落库。如果没落库检查 Kafka 消费是否有延迟或者积压。第四步确认查询逻辑是否正确。有时候数据是准的但查询条件写错了比如时间范围、用户筛选条件不对导致看起来数据不准。8.2 事件量暴涨的应对策略事件量突然暴涨可能是业务增长带来的也可能是埋点代码有 bug 导致重复上报。应对策略先确认是真实增长还是异常上报。对比 DAU 和事件量的比例如果比例突变大概率是异常。如果是异常检查最近的发版有没有引入重复上报的 bug比如页面生命周期里重复调用了上报方法。如果是真实增长评估当前方案的成本是否能承受。如果用的是按量计费的 SaaS要考虑是否设置采样率或者升级套餐。8.3 查询性能优化的常用手段查询慢是自建和自托管方案常见的问题优化手段包括预聚合把常用的查询指标提前算好存成物化视图查询的时候直接读结果。分区裁剪确保查询条件能命中分区键避免全表扫描。索引优化根据查询模式建合适的索引比如 ClickHouse 的跳数索引。资源隔离把查询负载和写入负载分开避免互相影响。8.4 数据合规与隐私保护无论选哪个方案数据合规都是绕不开的。几个基本要求用户标识要脱敏不要直接用手机号、身份证号做用户 ID。敏感属性如位置、设备信息要评估采集的必要性非必要不采集。如果涉及跨境业务要确认数据存储位置是否符合当地要求。提供用户数据删除的能力满足用户的删除权请求。9. 我个人的选型建议说了这么多最后给一个我个人的选型建议仅供参考。如果你是中大型企业预算充足业务方需要自助分析选神策。它的分析能力和开箱即用程度确实是国内第一梯队省下来的人力和时间成本能抵消一部分费用。如果你是中小团队需要产品分析会话回放实验能接受云服务选 PostHog Cloud。它的免费额度对早期产品很友好功能也足够全。如果必须私有化再考虑自托管但要做好运维的心理准备。如果你是中小团队要私有化部署需求聚焦在基础行为分析选 ClkLog。它轻量、部署简单、中文支持好是性价比很高的选择。如果你是有数据工程能力的团队数据量大要深度定制自建数据栈。但要想清楚你省下的钱是不是值得投入的人力成本。选型这件事没有标准答案关键是匹配你当前阶段的真实需求。功能表只能告诉你“有什么”但告诉不了你“适不适合”。希望这篇文章能帮你把“适不适合”这个问题想清楚。
