今年最有成就感的事，是自己对产品开发的参与度变深了。最关键的收获是学会了在友盟搭建埋点体系，还掌握了SQL查询数据的能力。有了这两项技能，做产品决策时终于能摆脱“我觉得”，用数据来说话了。

这篇文章先分享一下埋点的实战经验，SQL 怎么学的后面再说。

一、埋点到底是什么

简单说，埋点就是给用户行为装上“追踪器”。

用户每次点击按钮、每次在页面停留、每次输入操作，这些行为都会被技术手段记录下来，发送到服务器，最后变成我们可以分析的数据。整个链路大概是：定义要记录的行为 → 代码捕获 → 数据上报 → 呈现结果。

二、两种基本类型

页面埋点在页面加载时触发，用来统计页面访问量，比如 UV 和 PV。

事件埋点在用户点击页面元素时触发，比如点击某个按钮。把页面埋点和事件埋点结合起来，能算出更有价值的指标。举个例子，商品点击率 = 商品点击 UV ÷ 商品曝光 UV，这个比例能反映用户对商品到底感不感兴趣。

三、埋点命名怎么写

以友盟平台为例，产品经理需要提供埋点文件。命名是有讲究的，按规范来能省很多麻烦。



页面埋点用英文字母加下划线，按层级递进。比如：monitor → monitor.search → monitor_search → monitor_search.back。

事件埋点遵循“页面-行为”的逻辑。还是以首页某个按钮为例：A01-首页 → A0105 点击XX按钮(事件埋点) → A010501-进入XX列表页面(页面埋点)。

按这种方式命名，梳理埋点的时候基本不会出现重复或逻辑混乱的情况。

四、key-value 埋点：更高效的方案

上面说的是常规做法，但如果遇到多入口的场景，就显得有点笨拙了。

比如分享图片功能，可能在七八个页面都有分享入口。按传统方式，每个入口都得单独建一个事件，想想就麻烦。

这时候可以用 key-value 的思路：只定义一个“分享图片”事件，通过 key 标识页面来源，value 标识具体入口。

假设我们要分析所有用户的分享行为，传统方式需要把所有相关事件一个一个找出来，而用 key-value 方式的话，找到“分享图片”这个事件，筛选对应的 value 就行。

这种方案有几个明显好处：

一是好维护。后面迭代新增分享入口，只需加一个 value 值，不用新建事件。



二是分析快。筛选条件和维度都简单很多。

三是省钱。友盟免费版只有 500 个事件配额，能省则省。

不过 key-value 也不是万能的。我的判断标准是：同类多事件或者有扩展可能的事件，才值得用这种方案。

五、埋点怎么落地到 PRD

实际工作中，埋点是产品方案的一部分。我的做法是在 PRD 文档里单独留一块内容。

具体时机是：需求评审完、UI 图纸确定之后，在设计图上直接标注埋点。这样开发同学做页面实现的时候，一眼就能看到埋点需求，不容易漏掉。

标注就按前面说的命名规范来，页面埋点和事件埋点分开标记清楚。

写在最后

以上主要是数据收集层面的方法论，通用性比较强。但我想说的是，埋点只是手段，不是目的。

拿到数据之后怎么分析、怎么解读，让数据指导产品决策，而不是被数据绑架，这才是真正重要的事。希望这篇文章能给你一些启发。