Vibe coding 很热，写出来的东西越来越像样。但好像很少有人聊 vibe coding 产品的数据怎么做。没有数据，写写自用玩具可以，但想进一步规模化和商业化，这个问题始终绕不过去。

英文圈有一些讨论。Value Add VC 和 JustNeeda 分别写过一篇，其核心结论一致：定义北极星指标、只埋 5-10 个核心事件、每周花半小时看数据。这类文章面向的是有一定规模的 SaaS 创业者，和 vibe coding 出来的最小产品之间有些距离。

中文圈相对更少，搜出来的基本是大厂视角的"埋点入门"或"用户行为追踪从入门到实践"，和独立产品不太搭噶。你真去看了，就会陷入很多细节。属高射炮打蚊子。

笔者之前做算法，合作最紧密的业务方正好是产品数据运营和增长团队。回顾这些角色在干什么，对现在自己做的事情很有帮助。但很多人对数据的印象停留在活跃、营收这些大厂概念，更落地的问题反而没人讲：看什么数据、埋点怎么写、数据质量怎么保证。今天借机梳理下，从一个最小产品开始，数据该怎么做。

总的来说，初创产品的数据建设要做的是一件事：从用户行为到迭代决策之间，建一条可获取、可解释、可验证的数据流。整个流程，可以拆为 5 步。

一、先定义好坏，其后才是埋点

很多人一上来就问"接什么埋点 SDK ““GA4 够不够用”。工具当然重要，但数据工作的起点不是数据，是业务思维。大伙儿知道要接入数据，但不清楚为什么接、接入后干什么。闷头干，不是好事。

首先，我们需要定义什么是好、什么是坏，要看的北极星指标是什么。整个项目，有且应该仅有一个核心指标。

定义北极星指标（North Star Metric, NSM）大致两步：

  1. 定义核心价值：在写追踪代码之前，先确定一个能最精准捕捉产品"价值"的单一指标。
  2. 确定具体动作：用户做完哪个动作，我们就认为他获得了价值。这个动作，就是北极星指标。

北极星指标举例：社交软件，每天发送的消息数。旅行 OTA 软件，预订的房晚数。音乐软件，听歌时长。

数据要能证伪、要敢于直面现实。坏就是坏，不必麻醉自己。提前想清楚什么情况下需要调整、什么情况可以继续。标准不一定准，但一定要有。这个标准，应该能够指导决策和行动，如果不能，就不要追踪。

拿笔者自己的项目来说。QuantFull 产品改版前，先定义五段漏斗和四周基线，改版后逐段对比，才能说清楚"到底改好了没有”。另一个项目则是把"支付成功"收紧为"完整内容呈现给用户"，因为只有用户真的看到了结果，才算完成了价值交付。之前有用户支付成功但是交付失败，这个影响就很大了。

顺带提两个常见误区：第一个，过度关注虚荣指标。注册数、下载量、粉丝数这类只增不减的绝对数，好看但不能指导决策。真正有用的指标应该是可比较的比率，比如留存率、转化率、日活占比。第二个，忽视跷跷板效应。我们有一万种方法让点击率上升，但是这可能是强制弹窗、强制跳转，以牺牲用户体验和留存为代价。

二、埋点规范与兜底

定义好了北极星指标之后，下一步就是把它拆解成具体的事件。埋点的核心原则就一条：为决策而埋点，不为数据而埋点。基本上就是上文的延伸，业务逻辑出发，能指导决策的事件才关注；宁可少而精，不要乱铺开。

事件分四类

事件大致分四类：Pageview（自动采集，不用手动埋）、User Actions（按钮点击、表单提交等用户主动操作）、System Events（注册完成、购买、订阅变更等系统状态变化）、Custom Conversions（你自己业务定义的"成功"，比如漏斗终点）。

具体场景上，营销站和产品内侧重不同。营销站关注 cta_clicked、form_submitted、signup_completed 这类转化事件；产品内关注 onboarding_step_completed、feature_used、purchase_completed、subscription_cancelled 这类行为事件。每个事件带上必要的属性（比如 button_text、location、feature_name、reason）。

套到笔者自己的产品上，大概是这样。TrakToken 更偏"工具站"逻辑，核心事件是 model_compared（比了哪几个模型）、pricing_table_filtered（用了哪个筛选条件）、outbound_click（点去哪个模型官网/API 文档）。PageGrok 是个浏览器插件，更偏"产品内"逻辑，核心事件是 extension_installed、feature_used（feature_name 具体到摘要/翻译/哪个功能）、extension_uninstalled（带 reason，如果能采集到的话）。

属性怎么挂

属性大致分四类：Page 类（page_title、page_location）、User 类（user_id、plan_type）、Campaign 类（就是 UTM 那五个）、Product 类（product_id、price 等）。建议统一词表，别每个事件各发明一套字段名。

核心原则：上下文信息放属性里，别塞进事件名。比如不要埋 hero_cta_clicked 和 footer_cta_clicked 两个事件，用一个 cta_clicked 加 location 属性区分就行。

命名规范

固定格式是 object_action，全小写下划线：signup_completed、button_clicked、checkout_payment_completed。同一类动作用一个事件名 + 属性区分场景，不同类动作才用不同事件名。

验证兜底

事件设计完成后，别急着看报表，先验证真实用户环境中的数据能不能送达分析系统。代码调用了埋点函数，不代表数据已经到达。很多时候，数据误差就从这里来。

PageGrok 就踩过这个坑。GA4 被广告过滤规则拦截、缺少安装事件、匿名 ID 不稳定。最终是自建上报中转、补安装分母、稳定匿名 ID、服务端保管密钥，这个问题稍微得到缓解。

外网有个数据：广告拦截器影响了 25-40% 的客户端流量（厂商估计，未经独立审计）。他们推荐的模式是混合采集：客户端自动采集做基线，服务端手动埋点覆盖 10-20 个核心 KPI。核心事件（比如注册）甚至建议客户端和服务端各埋一遍，但用不同的事件名避免重复计数。

三、工具怎么选

2026 年海外开发者流行的做法是"两层分拆"：前者看营销站流量，后者看产品内行为。

网站流量层（有多少人来了、从哪来的）：

  • GA4：功能最全，能做漏斗、留存队列、自定义事件。但配置门槛高，GDPR 合规负担重。容易出现 self-referral，自己域名被记成引荐来源，吃掉其他渠道的功劳。
  • Vercel Analytics：零配置、隐私友好，和部署流程无缝集成。但深度有限，没有漏斗、分群、错误追踪。
  • Microsoft Clarity：免费，无流量上限。提供热力图和会话录制，能看到用户实际操作行为，排查"为什么用户在这里流失"。

产品行为层（用户进来做了什么、留没留下来）：

  • PostHog：2026 年独立产品圈最常被推荐的产品分析工具。免费版每月 1M 事件 + 5K 会话录制。集成了漏斗、留存、特性标记、A/B 测试。开源自托管，如果在意数据主权，这个方向比较对胃口。
  • Mixpanel / Amplitude：功能强大，但定价更偏向于有融资的公司，建议在产生实质营收前跳过。

笔者自己的做法是 Vercel Analytics 做日常监控（零配置直接看），GA4 做深度分析（漏斗和留存），两者交叉验证。从实际采集数据来看，Vercel 的访问用户量级一般比 GA4 多 30-40%，差异主要是地理位置拦截和浏览器插件拦截。

Bing 必应流量

笔者的产品，大量流量从 Bing 来，远比谷歌和百度来得多。初步推测：Bing 的索引现在同时是 Microsoft Copilot 的直接数据源，也是 ChatGPT Search、Perplexity 部分检索结果的来源，所以量比较大。

做 Bing SEO 能很好提高 AI 可见性，想接到这块流量，以下几件事值得做：

  1. 去 Bing Webmaster Tools 提交 sitemap。 Bing 比 Google 更依赖主动提交。
  2. 接 IndexNow。 内容一更新就推给搜索引擎，Bing、Yandex、DuckDuckGo 都认（Google 不认）。一般提交后 3-6 小时 Bingbot 就来爬了，不接的话得等 24-72 小时。
  3. 看 AI Performance 面板。 2026 年 2 月 Bing 上线了这个功能，能看到哪些页面被 AI 回答引用。目前唯一的官方工具。
  4. 别让 CDN 误拦 Bingbot。 Cloudflare 的 Bot Fight Mode 和部分 WAF 规则可能会把 Bingbot 挡掉。

据参考资料：一家清洁服务公司之前完全没提交过 Bing，提交 sitemap 后 30 天内从月访问 2-5 次涨到 700+。

四、口径对齐与数据清洗

数据进入系统后，可不是万事大吉，还需要做数据验收和比对。

笔者在 cang-in-house 项目里就踩过好几个：交易日窗口算错、数据截止日不对齐、夏普率分母选错。这些虽不是埋点问题，但会让你对着错误数据做出错误决策。这类情况，在数据工作中很常见。大厂的数据分析日常，很多时间都花在对口径重新拉数上面。

另一个例子是笔者的某产品，Stripe 的支付成功事件、后端的订单状态、前端的内容解锁页面，三个数据源都记录"支付成功"，实则口径不一：Stripe 记录的是扣款完成，后端记录的是订单状态流转，前端记录的是用户实际看到了内容。三者之间存在时间差和状态不一致，导致同一天的"支付成功"数在三个地方对不上。最终的做法是以"用户实际看到内容"作为唯一口径，其余两个降级为过程监控指标。

还有个容易被低估的干扰：自动化流量已占全网流量的 53%，人类流量只有 47%。有真实案例显示某网站流量"涨了 30%"，人工核查后发现真实用户会话其实降了 8%，涨的全是 AI 爬虫。分析时有条件还是做做爬虫过滤，就跟大厂的小号和工作室不计入日活一个道理。

五、让分析结果回到产品迭代

最后回到落地：根据数据改变产品/策略，再观察新一轮结果。

拿笔者自己的项目举例。根据价格曝光、支付意图、取消支付、内容解锁等事件数据，评估定价方案和挽留策略，再看下一轮数据验证调整效果。

不过整体数据量不大，所以那些 A/B 其实都派不上用处。P 检验有条件可以做做，没条件决策还得自己来。笔者一直秉持一个态度：数据有用，但不是万能的，关键时刻要勇于根据直觉作出决策。

自动化工具

当前 AI Skill 生态在数据运营这块还处于早期。笔者调研了几个主流平台和 GitHub 仓库，值得说的主要是两个方向。

一类是"知识型 skill"，纯 markdown 文件，告诉 agent 该按什么框架做事。典型的是 coreyhaines31/marketingskills（43 个 skill，GitHub 43K+ Star，安装量 281K+）和 clamp-sh/analytics-skills（含 GA4、PostHog 等五个平台的 tool-map）。前者教你"该埋什么点"，后者教你"埋完之后数据怎么看、异常怎么判断"。

另一类是"执行型 skill"，skill + MCP 配对，agent 不只给方案，还能真的连接外部平台操作。比如 hyperfx-ai/marketing-skills，19 个 skill 搭配 100+ 平台集成，能连 Meta Ads、Google Ads 跑数据。不过这类工具的商业意图更明显，本质上是在推自己的 MCP 订阅服务，skill 只是获客入口。

对于独立开发者来说，先装 marketingskills 的 analytics 和 seo-audit 跑一次诊断，比自己从零摸索效率高不少。但什么时候该调定价、什么时候该停止某个功能，这些判断仍然需要人来做。

回到开头

五步分别对应：

  1. 先定义好坏，而不是先埋点
  2. 埋点规范与兜底
  3. 工具选择
  4. 口径对齐与数据清洗
  5. 让分析结果回到产品迭代

整条线串起来，就是从业务问题出发，经过指标定义、数据采集、加工清洗、分析验证，最终回到产品决策，然后进入下一轮循环。

其实整个流程做下来，和大厂数据流也没啥差别了。无非是大厂的规模更大、细节分工更细致。独立产品的优势在于船小好调头，数据到决策的链路短，看到问题就能改。劣势是数据量小、很多结论不置信，没人分锅、更考验决策力。

参考资料

方法论与框架

工具对比

Bing SEO 与 AI 可见性

AI Skill 生态

关于作者