【干货】BAT大佬告诉你如何埋点？

随着互联网时代的到来，各行各业都开始融入“ 互联网+” 的思维。从最开始的TOC的服务&消费型产品，到如今TOB的数字化转型，数据越来越重要。打开京东淘宝，头条抖音，里面琳琅满目的商品推荐，视频推荐。

那么，问题来了，这些算法上千人千面的推荐，是怎么做到的？答案：用户行为数据。

那再深入一些，如何更精准的拿到 用户行为数据？

答案：埋点。

这就是今天我们要讲述的内容：数据埋点。

定义：埋点是用户行为数据的来源。

目前来说，大部分企业对于用户行为数据的获取，都是在各个终端上设置埋点。

通过各种各样的埋点，拿到相应的用户行为数据。用于下游的统计分析和业务迭代。

主流的方式有两种：

第一种：公司自研，在产品的各个页面、（可交互）模块，按照一定的规范，“注入”统计代码。

第二种：第三方统计工具，如友盟，神策，GrowingIO等第三方监测平台的接入。

各个公司随着业务的不断扩大，一般都会选择自研发，并设定相应的埋点规则和统计规则。

我们这期重点就来聊聊“埋点规范”的设计。

一般来说，埋点主要由两个部分组成：公参和业务参数。

什么是公参？通俗来说，就是无论这个业务怎么变，每个埋点中都必须有的值。

举个例子，用户的业务id（如 uid），就是公参用户的手机imei，也是公参。我们可以根据我们的业务形态，及我们一定需要的数据，给出公参。

一般公参有4个要素：用户识别 、设备识别 、 页面识别 、关联识别。

顾名思义，用户的唯一标识。即用户无论在哪台手机（终端）上登陆，我们都能映射到该app下的唯一用户的标识且对应到这个用户上的一些固定信息，如手机号，实验分桶标识等常用信息。

由于用户可能在不同的机型上，所以我们需要记录到设别信息，如imei，手机型号，手机系统等。

特定的页面上的信息，如搜索，我们需要每个页面都透传用户的搜索词如头条，可能需要每一次打开app的行为id，这些特定的，非业务参数信息，都可以记录到页面识别参数里。

由于行为和行为之间，会有链路的串联关系，所以我们需要记录页面之间的关联关系参数。比如：页面和页面之间的关系，我们可以记录 来源页面模块和页面之间的关系，我们可以记录 来源模块如果所有页面流量都有算到某一页面上，那我们可以将 该页面识别（如页面id）透传至需要统计的页面。

业务参数，就是对应到具体的产品模块，展现内容等具体业务上需要统计的内容的映射值。

对于业务参数的设计，我们在下文中会具体讲解如何定业务参数。

每个公司，每个业务都会有独特的埋点方案，但是无论哪种埋点，我们都会有个明确的层级及关系划分。这里主要介绍两种较通用的埋点方案，为大家埋点设计提供一定的参考。

模块式埋点，就是用产品本身，肉眼可见的明确区分的模块，来构建业务参数。

每个app，都由多个页面组成，不同的页面及页面上的功能组合，构建了一个app。

所以，我们可以定义模块式埋点的第一个层级：页面。

具体到某一个具体页面，我们可以较明确的区分出区域，比如微信信息列表页，我们可以较明确的看到三个区域：头部区域（搜索框 & 右上角的加号），中间信息列表区域，底部4个按钮区域。这些明确可以划分的区域，我们可以定义成第二个层级：区域。

而在看这些区域中的具体 可以交互 的内容（或者功能），我们可以定义成第三个层级：按钮。比如头部区域中的搜索框点击，右上角加号的点击中间信息列表区域的聊天窗口点击底部按钮区的四个按钮的点击。

这样，我们把三个层级串联起来，就形成了这样一套业务埋点规则：页面_区域_按钮。

当然，我们可能还需要记录某些具体的业务附加信息。

如点击聊天列表，是点击了群聊，还是好友，我们可以记录一个聊天类型，而对应的如好友id，群聊id，我们也可以记录在附加信息中。

这些附加信息，我们也可以记录到具体的参数值里，但这个参数需要和模块层级埋点区分，不能埋在同一个值中，这点需要注意。

比如上文所述的微信的埋点，我们可以这样标记：

我们按照上述结构，将页面&区域&按钮链接在一起（比如以 @ 符号关联），就形成了该页面的埋点，如页面展现，我们可以打点为 wx_list_page@0@0,如公众号点击，我们可以打点为 wx_list_page@talk_list@pub_acc_clk，以此类推。

如果我们想统计中间区域的点击，那么我们之需要把点击埋点截断至 区域，不用明确区分按钮，我们就能很方便的统计出想要的区域，页面，点位上的数据。

和模块式埋点类似，模块式埋点是产品本身的层级区分，内容式埋点是内容本身的层级区分。

内容式埋点一般会应用在广告等内容的数据统计上。

首先，我们需要一个串联ID来串联前端数据和服务端数据。

往上层，我们需要知道这个串联id属于什么内容，这时需要内容id。再往上，内容id属于哪种大的类目，这时需要内容分类。

这个就是内容埋点，同模块埋点，内容埋点需要有明确的内容层级区分。

而这时基础层级，串联后就形成了内容埋点规范：内容分类_内容id_串联id。

当然，模块式埋点以及内容式埋点还可以继续往上层划分，比如 模块式埋点可以增加至 产品_业务_页面_区域_按钮内容式埋点可以增加至 业务_系统_内容分类_内容id_串联id。

这些都可以根据特定的业务场景修改，只要有相应的层级划分，统计起来就会方便很多。

一般情况下，主要有3类埋点：展现埋点 + 曝光埋点 + 点击/输入框 等交互埋点 + 自定义埋点。

通俗来说，某个页面里的内容被展现了。

怎么定义展现，这个其实就是一个服务端的触发。服务端如果触发了，用户侧会展现什么内容。

由打点时机可以明确出，展现埋点需要记录的是 页面展现的内容信息。

也就是说，服务端下发的内容都包含什么（这些东西一定是当前页面主要内容，不包含一些交互信息）。

哪些下发的内容被用户实际看到了。

和展现埋点类似，由于屏幕有限，但内容可以无限。哪些内容被用户侧实际看到（曝光），我们也需要记录下来。

不同的是，曝光埋点，我们需要记录的是单个“内容”被看到，不能是一串内容。一串内容，可以触发多次曝光埋点，但是曝光埋点一定是单个“内容”。

哪些功能/内容被用户“点击”了。

从埋点时机来说，这个是展现 & 曝光的下游。

记录的是，对于我们提供的“服务”的“消费”情况。

比如，一个页面，用户可以点击，那么我们需要记录相应的交互埋点比如，一个视频可以点赞，我们也可以记录交互埋点比如，一个视频可以播放暂停，我们也可以记录消费埋点。

总体来说，就是，我们要记录 被看到的可交互功能/信息的“消费”数据。

自定义埋点：随着业务的发展，产品种类越来越多，总会有需要特殊埋点的地方，可以留一个自定义埋点备用，总要给业务一个机会嘛（玩笑话）。

关于埋点记录，或者叫埋点文档，我们只要明确记录两个信息：点位信息 & 点位映射。

点位信息：明确每个业务事件下的具体的参数信息，即上文所述的公参+业务参数。

点位映射：每个埋点对应的业务含义。

只要埋点文档中记录了这两个内容，那么这份埋点文档就是一个合格的埋点文档。

当然，上文所说的层级，参数，事件等，都是一份好的埋点设计的组成“成分”。

多思考，多参考，相信大家都能设计出合适自己业务的埋点规范。

-END-