【干货】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类埋点：展现埋点 + 曝光埋点 + 点击/输入框 等交互埋点 + 自定义埋点。

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

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

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

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

曝光埋点：哪些下发的内容被用户实际看到了。

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

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

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

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

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

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

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

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

埋点记录

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

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

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

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

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

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