数据埋点：埋点文档/需求的理解和撰写

埋点文档的撰写，各家规范要求各不相同，但是我们理解它的核心后其实都能快速上手。

撰写埋点文档这不是一个人就能完成的工作，撰写的时候，我们需要去请教数据分析师和前端后端研发，大家一起来确立明确的指标，并且让这份文档有可读性而不是自嗨性。

搜索埋点文档，我们都可以搜索出一大堆相关的文档方案。这些方案确实是有用的，但是却忽略了大部分产品本身没有技术背景，很难去看懂或是理解这些文档。

同时大部分公司也不需要那么复杂的埋点文档用于管理埋点，因此对于埋点文档我们理性看待，不要为了装逼而装逼。

一、日常的埋点需求

工作中，埋点数据需求量最大的无疑是产品的营销运营。这类营销运营会分为常态化专题运营和热点营销活动两类。

常态化运营特点是短平快，要周期性的更新活动主题和内容，核心目的是稳固影响力。热点营销活动主打的是以近期热点作为主题，进行以业务目标为导向的活动。

在这种日常活动中就不适合使用那种完整的埋点文档，我们只需要在需求文档中简单的写明你需要的数据，交付给研发的时候在特别说明下即可。

例如：本次埋点需求

1. 统计页面PV（点击浏览量）和UV（去重后的点击浏览量）
2. 统计页面中A、B、C、D四个按钮的点击量（点击的PV）和点击人数（点击的UV）
3. 统计本次活动的业务订购量

甚至可以让研发单独将这部分写成插件，后续活动直接调用即可，这也花不了多少的时候。这样一个能用的埋点需求就完成了。而接下来的实施部分，可以直接交给研发进行处理，你可以在随后的环节中和研发进行讨论确认一些细节。

例如：记录UV的时候，我们是用什么来作为唯一凭证？

1. 手机号：实际能够接收到短信的手机号为准，但会因为需要接受验证码或要求登录从而对参与性要求较高。
2. IP：当前用户访问页面时所在网络的IP地址，会因为切换网络或使用代理进行变更。
3. Cookie：浏览器内保存的标识，包含用户私密信息，可通过服务器进行修改生成，但因大部分手机浏览器不支持而局限。
4. IMEI：移动设备的身份证，具有唯一性。一般需要使用app去获取安卓设备的底层权限，网页H5获取使用，在iOS设备上无法获取。一遍手机都可以修改，需要获取root（最高）权限，在使用软件修改即可。
5. DeviceCheck：iOS设备特有唯一设备码，之前使用uuid，但是因为苹果隐私问题iOS6后就禁止使用了。这个唯一编码只要不退出苹果ID并还原设备，就不会重置，唯一性较高。但是相同的问题，需要app去获取权限，很多H5并不支持。

注：唯一标识，是需求系统的核心指标，常用来作为推荐系统、数据系统等的唯一标识。

二、专业性埋点文档

相比较上面十分随意的埋点需求描述，在大公司面对完善的产品时，因为需求构建复杂的分析体系，就需要使用有深度规范的埋点文档进行管理，以便更好的在各层次中对埋点的理解达成一致。

所以复杂专业的埋点文档一般是公司体系大，产品完善度高的公司才会使用。

1. 存储类型

我们常见埋点文档中出现String、bool、key、value等类型注名，但并不理解他们的含量，这先做一个简单的讲解。

1. String（字符串）：表现直接存储一段文本内容，可以是中文，也可以是英文，我们可用来记录用户搜索的内容获取发表的内容。
2. bool（布尔）：只能表示true（是）和false（否），我们已经用户记录用户是否点击按钮。
3. int（整型）：记录自然数，从-2,147,483,648到2,147,483,647之间的数都可以使用。
4. float（浮点）：这也是我们常说的小数点如1.21、5.20、13.14等等。

除了上面4个类型以外其实还有long、char等等类型，但是为了实用性，我们只要了解上面的4个类型，基本对我们撰写文档来说就没太大的问题了。

在撰写较为专业的埋点文档的时候，我们都需要基于需求去撰写。

例如：我们的目标是想了解一段时间内我们的app使用率是否处于正常水平了解app（H5页面）的唤醒（打开）率以便评估是否处于均值。有了目标之后就进入第二部分事件拆分。为了完成我们的目标，用户会经历哪些操作事件？

我们一一进行拆解。首先用户会先拿出手机，其次打开或登录我们的app（页面），最后再进行其他的浏览、购买行为。

到了这里这就是一个十分简单的登录（浏览）事件，有了事件接下来就需要我们明确数据指标。在登录（浏览）事件中，我们首先要梳理的是哪个指标可以作为用户在我们系统中的唯一标识。

有了标识后我们要明确用户什么样的行为算一个有效的登录，是只需要打开app、加载页面就算，还是需要进行后续滑动、点击等交互行为后才算。这两个确定后我们就可以撰写文档了。

文档撰写每个公司要求都不一样，但是我们按照“便于理解”，“避免争议”的逻辑去写问题就不大。我们先将他们进行分类，本次埋点属于登录（浏览）事件，我们是以用户是否成功浏览页面作为评判标准，那么我们他们归于页面浏览这一大类中。

随后我们进行细化，页面的浏览也会因为页面的繁多而混杂，这里因为我们属于首页内容的浏览，因此它的第二类就算首页页面。有了这两个分类，我们就可以在后续有需要查询埋点的时候快速理解定位埋点，随后就是具体的埋点参数了。

这里假设我们使用IMEI作为用户唯一标识，之后因为我们是需要通过登录情况去了解我们的用户，这里我们可以判断她是否是首次登录，用于删选重复登录的用户，这样一个简单的埋点文档有雏形了。

同时因为代码是字母编码，所以我们要将文档中的中文名称给确定一个英文名称，这样我们后续就知道埋点在系统中叫什么。

不然直接给中文，可能会因为每个人英语水平问题，造成埋点名称各不相同。例如手机号我取名叫number，你取名叫iPhone，他取名叫Telephone number这就乱了。因此我们最好加上他们的英文名称。

2. 扩展：预置属性

到后去业务埋点需求越来越多之后，我们的埋点会越来越多，最后在没有更好的管理下，直接每次找埋点找的崩溃。

所以我们不时对埋点进行整理，将通用的数据进行抽离，将他们单独抽离出来，抽离后形成一张新表，代表每个埋点在搜集数据时，都需要同时收集这张表上的预置内容。

这样后续我们只要慢慢根据我们的目标进行完善埋点即可。

3. 扩展：共性提取（key value）

除了预置属性以外，我们要需要一个代码类型《键值对》（我们理解为一个主键一个数值对应）。为什么理解？因为就算使用预置属性我们还是会面对埋点数据过多的问题，因为一个成熟产品最少都拥有10个以上的页面，更别说更加成熟产品了（淘宝、拼多多）。

面对大量页面不同，统计数据相同的埋点，我们要选择一套高效的管理手段。所以我们需要了解《键值对》（方法都是方便文档管理，而实际数据库存储是由研发设计规划，所以建议及时和研发进行沟通）。

键值对：按照名称，key值，value值进行存储。其中一个名称对应多个key值，一个key值对应多个value值，这里不想去理解key和value代表什么，毕竟我们不是研发。我们只需要他们所对应的格式即可，就像一级分类，二级分类，三级分类一样。

例如：

• 页面浏览（键值对的名称）— 首页页面（键值对的key）— 访问次数（键值对的value）
• 页面浏览（键值对的名称）— 详情页面（键值对的key）— 访问次数（键值对的value）
• 页面浏览（键值对的名称）— 购物车页面（键值对的key）— 访问次数（键值对的value）

（我这种方式我感觉只是文档管理方便，对于研发来说，还是需要看需求是否只是需要总数还是详情来设计数据库存储，一样麻烦。）

三、最后

埋点文档其实没你想象中那么难，也没你想象中那么简单。现在有太多的数据平台，神策、诸葛io、友盟、growingio等等，都是一套的解决方案，从采集到存储以及分析可视化等等。

所以其实去了解下他们的分析解决方案即可，没必要自己进行搭建整个一套，就像我开头说的，如果只是日常需要，就直接写想要什么数据给到研发就行，强行搭建费时费力，并且还不一定好。如果真要搭建那么还需要你多和研发进行沟通，毕竟代码是实现功能的基础。

作者：wcof，在努力做产品不做产品经理的人；微信公众号：Wcof（ID：wcofPM）

本文由 @Wcof 原创发布于人人都是产品经理，未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议。