埋点这件事，别等系统跑起来才想

原创

于 2026-07-26 17:34:46 发布 · 357 阅读

话题

#编程达人挑战赛·第11期

埋点这件事，别等系统跑起来才想

很多系统上线时都说“先加点日志，后面再分析”。过几个月再看，日志确实不少，问题还是回答不了。

用户从哪里来，不知道。注册页打开了多少次，不知道。免费用户为什么没有付费，不知道。某个接口调用量突然涨了，是新用户增长、爬虫、重试风暴，还是某个客户接入脚本写错了，也不知道。

日志不是埋点。日志通常是给工程师排障看的，讲的是“程序发生了什么”。埋点是给产品、运营、增长、风控、计费和工程一起看的，讲的是“用户和业务发生了什么”。

这篇文章不讲某个具体项目，而是把服务埋点这件事拆开：什么服务需要埋点，不同流量阶段怎么做，数据库怎么选，成本怎么算，性能怎么评估，最后用几个真实业务场景把“从用户源头到分析结果”的链路串起来。

埋点到底解决什么问题

埋点最常见的误区，是把它当成“访问量统计”。访问量当然重要，但只看 PV/UV，最多知道门口来了多少人。真正有价值的问题通常更尖锐：

哪个渠道来的用户更容易注册？
注册后多久会完成第一次关键行为？
免费用户在什么地方掉队？
付费前通常调用了哪些功能？
某个版本上线后，错误率上升是集中在一个入口，还是所有入口都变差？
高价值用户和普通用户的行为差异是什么？
一个接口调用量涨了，收入有没有跟着涨，成本有没有失控？

这些问题都有一个共同点：它们不只需要一条日志，而是需要把用户、会话、来源、页面、接口、订单、功能、错误、成本串起来。

所以服务埋点的核心不是“多记一点”，而是建立一条可追踪的事实链：

用户来源 -> 访问页面 -> 注册/登录 -> 激活行为 -> 功能使用 -> 成本消耗 -> 付费/留存

如果这条链断了，再多日志也只能做局部猜测。

哪些服务需要埋点

不是所有服务一上来都需要复杂埋点。埋点设计应该和服务类型、业务阶段、流量规模一起看。

服务类型	最重要的问题	优先埋点
内容站、官网、文档站	流量从哪来，哪些内容带来转化	page_view、referrer、utm、入口按钮、注册点击
SaaS 后台	用户是否真正激活，哪些功能被使用	login、workspace_created、feature_used、invite_sent
电商/订阅服务	漏斗哪里流失，支付失败原因是什么	product_view、checkout_started、payment_succeeded、payment_failed
API 平台	调用量、成功率、耗时、成本、客户价值	api_call、first_api_call、quota_exceeded、billing_usage
B2B 内部系统	关键流程是否完成，审批/任务卡在哪里	workflow_started、step_completed、approval_rejected
高流量网关	峰值、异常、区域分布、计费和风控	request_sample、error_bucket、rate_limited、billable_event

小服务最怕过度设计。刚上线的官网，不需要立刻建 ClickHouse 集群；但至少要有稳定的 anonymous_id、页面访问、关键按钮点击和注册成功事件。反过来，一个每天几百万 API 调用的平台，如果还只靠应用日志和后台 SQL 查账，很快会把业务库拖慢。

先定事件，不要先定数据库

数据库选型很重要，但埋点系统最容易失败的地方不是数据库，而是事件口径。

一个合格的事件至少要回答四个问题：

{
  "event": "api_call",
  "time": "2026-06-29T10:23:45.123Z",
  "user_id": "u_123",
  "anonymous_id": "anon_abc",
  "session_id": "sess_789",
  "source": "web",
  "page": "/pricing",
  "properties": {
    "tool_id": "stock_quote",
    "success": true,
    "latency_ms": 183,
    "credits": 2,
    "plan": "pro"
  }
}

这四个问题是：