想看埋点数据？产品经理有必要了解的埋点知识（1）

                                                本文作者将从一个埋点系统设计者的角度通俗系统地讲解埋点的全过程，涉及到埋点基础知识、埋点作用、埋点方法、埋点数据流程、埋点应用、埋点管理等信息。

埋点是什么？
埋点是互联网领域非常重要的数据信息获取方式。埋点采集信息的过程一般也称作日志采集。
通俗点讲，就是在APP或者web产品中植入一段代码，监控用户行为事件（例如某个页面的曝光）。用户一旦触发了该事件，就会上传埋点代码中定义的、需要上传的有关该事件的信息。
常见的信息包括：用户会话id，用户id，当前页面编码，当前事件编码，触发时间，用户设备id，ip信息等等。
埋点的作用
可以看到，除了像电商购物提交的订单报表等信息是用户填写之后，通过业务数据库中进行读取的；用户在APP或web产品上的行为信息，更多需要靠埋点方式进行获取。典型的应用场景就是某个运营活动，页面的点击量（PV）有多少，点击用户数目（UV）有多少，都是用埋点数据进行计算，来对运营活动有数据上的评估。
当然这些信息并不是消费一次就没有用处了。通过埋点收集到的信息，可以作为监控，看到APP的长期表现，也可以作为基础原料，进行复杂的运算，用于用户标签、渠道转化分析、个性推荐等等。
埋点种类
按照信息采集发生的位置来分，埋点可分为客户端埋点、服务端埋点、H5埋点。客户端埋点即监控APP当地发生事件的埋点，例如APP某页面曝光，一旦APP客户端加载了该页面，客户端埋点就会发送相应信息；H5埋点可能是在APP中跳转到的某个H5页面（如运营活动页）上的埋点，也可能是web某页面上的埋点。
下文重点讲的是客户端或H5埋点的方式，服务端埋点一般较少，埋点方式也较为通用。
埋点方式
1、手动埋点

这是埋点最古老的方式。具体的步骤一般是，产品经理在提需求，需要在APP某个页面的某个事件进行埋点，在这个过程中，产品会对该页面和事件按照一套规则进行编码命名（若事件数不多，页面编码命名这一层也可以省略），以便后续通过该编码对上传上来的信息进行辨认；同时，产品也会将这一埋点需要上传的参数告知前端开发。开发明确需求后就会进行埋点。
优点：

手动埋点方式简单灵活，来一个埋一个，埋点代码实现过程对开发来说也较为简单，不会占用太多时间。

可对埋点中需要上传信息的字段进行个性化选择，满足复杂业务场景。例如页面曝光埋点中，上传的信息只需要是这个页面编码等就可以了，但如果是某个下拉控件的事件，可能上传的信息中还需要带上下拉控件后最终选择了第几项。

缺点：

埋点过多时，大量重复性操作较为枯燥且容易出错。新版本发布可能要埋100个点，人工手动去埋，总可能出现某一个忘记埋或者某个应该在A处埋的点埋到了B处的情况。

沟通成本较高。需要PM和开发确认。

埋点周期长。手动埋点如果出现漏埋情况，必须依赖下一版本发版，补上漏埋的那个埋点，才能看到数据。如果新增一个埋点需求，要看数据也只能等下期了。

2、半自动埋点
看了上面的手动埋点描述，可能很多人都会有疑问，所有的埋点都需要手工去埋是否有必要。就比如100个埋点中，可能有80个埋点都是页面曝光事件，这类埋点非常相似，完全可以用一套埋点手段去解决。那么半自动埋点就是为了解决这种问题，把部分人工的工作进行标准化，做成SDK。阿里埋点实践中的“黄金令箭”方案就是半自动埋点的典型例子。PM提埋点需求时候，直接将自己申请的埋点进行注册，调用符合自己要求的埋点SDK，并进行下发，那么APP或web产品中就会集成该段埋点代码，而不再需要沟通前端开发进行埋点。当然，在半自动埋点不完善的阶段，可能调用SDK的工作是由开发完成的。
友盟、神策分析、growing IO等传统的商用化埋点服务，也均是通过埋点SDK这种手段实现的。另外值得一提的是，近来兴起的可视化埋点方案（腾讯MTA、百度移动统计近期也刚新加入了该功能），也算是半自动埋点的一种。通过可视化埋点的方案，PM可以直接看到APP或web产品的界面，在界面上捕捉需要进行埋点的元素如页面或控件等，再通过可视化的点击录入过程，赋予埋点业务含义。也就是说，可视化埋点方案可以通过所见即所得的方式，方便埋点需求方进行埋点。
优点：

将通用的埋点方式进行整合，提高埋点效率，通过同一套SDK，埋点上传的信息也较为规范，便于后续数据处理。

PM直接调用SDK的方式，使得埋点需求提出过程和埋点过程统一，无需付出复杂劳动，省略了整理埋点需求和沟通的环节，也节约了开发进行埋点的工作量。

可视化埋点方案可以更加形象可视地将埋点业务含义和物理代码连接起来，也可以更清晰直观看到哪些控件已有注册埋点。

缺点：

同样存在埋点周期长的问题。如果漏埋还是要等下一版本发布。

可视化埋点一般只适用于比较简单的APP，如果版本过多，显示的内容不同，需要打开并进行埋点的可视化页面过多，导致管理混乱。

公司自行开发可视化埋点方案成本较高。

3、全自动埋点
全自动埋点在一些宣传当中也被称为“无痕埋点”。这种方式和上文的手动和半自动埋点有产生方式上的本质不同。手动和半自动埋点是需求方需要了，才去埋。而全自动埋点则是不管需不需要，将所有的点都埋了。通常这种埋点也是通过SDK实现的，这种SDK不需调用，已经直接嵌入在APP中。因为全自动埋点都是自动生成的，用于对每一个埋点进行标识的埋点编码也是按照既定规则进行生成。通常这种标识是不可读的，需要PM和开发沟通，对埋点编码进行和业务含义上的映射。

全自动埋点方法听起来挺简单粗暴，优点和缺点也同样突出。
优点：

根本上解决漏埋问题，缩短埋点周期。

无需对页面、控件是否需要进行埋点做区分，需要数据时直接取数据。

缺点：

全自动埋点一套SDK对应一套数据上传方式，需要尽可能通用，个性化的数据采集无法满足。一般只能对页面曝光、关闭，控件点击这种通用事件进行全自动埋点。

全自动埋点覆盖面广，数据传输压力大，可能有很多上传上来的信息是不需要的。

和一些半自动埋点中PM可自行通过SDK自助进行埋点相比，全自动埋点仍需要PM和开发沟通。因为全自动埋点中埋点编码为自动生成，其意义只有开发明白，要想对应到业务含义，必须由开发参与。

安卓APP和IOS APP往往是两组开发人员开发的。全自动埋点这种“埋点创造于开发过程而不是需求过程”的模式，很容易导致同一个埋点事件，其埋点物理编码在安卓和IOS上是不同的，这就需要埋点需求方花费时间去做对应。对应过程是复杂而艰辛的。

因而，全自动埋点适用于产品比较小，页面、控件少，上传的数据也较少的情况。同样，全自动埋点也可以配合可视化埋点方案，此时可视化页面中不仅仅是捕捉到页面或控件，同样可以显示其已存在的埋点编码名称，埋点需求方可将该不易读的编码录入到可读的业务含义上。
埋点数据的采集、传输、加工、存储、应用和管理内容将在下期介绍。