从数据产品经理视角，聊聊埋点的意义

什么是埋点？怎么埋点呢？本文作者从数据产品经理的角度来为你讲解。

一、数据过程

数据生产-数据采集-数据处理-数据分析和挖掘-数据驱动/用户反馈-产品优化/迭代。
用户操作app时产生行为数据，通过数据采集系统采集，对采集的数据进行处理（实时数据处理+离线数据处理）得到统计数据进行数据分析，并将结果呈现出来以复盘总结当前版本并驱动下一个产品迭代，或者清洗后的数据进行数据挖掘，实时反馈给用户（如推荐）。
数据采集，顾名思义采集相应的数据，是整个数据流的起点，采集的全不全、对不对，直接决定数据广度和质量，影响后续所有的环节。
在数据采集失效性、完整性不好的公司，经常会有业务方发现数据发生的大幅度变化，追其所以时发现是数据采集的问题（见附注）。而另一方面，采集什么数据才能有效的得到数据分析结论，才能有效的进行推荐，就需要提前规划埋点。
当前数据采集普遍遇到的几个问题：
实时性，对于工具性产品在无网条件下的数据，无法实时上报；
完整性，由于用户隐私协议&欧盟通用数据保护条例的，部分数据无法采集；
异常，android_id、idfa、idfv 随版本升级变化或无法获取。

二、数据埋点

接下来用5w2h的思路来看埋点。

1. 埋点是什么？

所谓“埋点”，是数据采集领域（尤其是用户行为数据采集领域）的术语，指的是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。比如用户某个icon点击次数、观看某个视频的时长等等。
埋点的技术实质，是先监听软件应用运行过程中的事件，当需要关注的事件发生时进行判断和捕获。
特别注意需要明确事件发生时间点、判别条件，这里如果遇到不清楚的，需要和开发沟通清楚，避免采集数据与理想存在差异。例如：期望采集某个app的某个广告的有效曝光数，有效曝光的判别条件是停留时长超过1秒且有效加载出广告内容。

2. 埋点是谁的工作？

现在公司通常都会有数据产品经理或业务线数据分析师，结合版本迭代过程进行埋点规划。如果是代码埋点，还需要开发完成相应的埋点代码。

3. 在什么时间点&在哪里埋点呢？

埋点是目的导向。
在产品规划时就要思考数据埋点问题，如果在产品外发后再考虑怎么埋点，就会导致前期版本用户的数据无法收集，想要看某个数据时就会非常无奈，只有等到新版本完善来弥补。
思考要埋哪些点、埋点的形式，需要紧密结合产品迭代的方向、运营需求，并和数据开发等进行充分沟通以确认：
埋点能够得到想要的数据解决/支持；
能够得到当前版本的复盘情况；
后续版本的数据支撑。
通常的沟通过程以 埋点文档为载体；数据埋点评审为终结。
当前版本的复盘情况：
新版本功能使用情况，是否符合预期；
新功能上线后对其他功能点的影响？是否为整体均有积极作用；
版本运营活动目标群体的特征获取;
新增商业化目标的监测……
后续版本的数据支撑：
规划方向的用户行为分析
画像特征分析

4. 怎么埋点呢？

4.1 埋点技术：代码埋点、可视化埋点、无埋点
接着第一节：埋点是什么？来看下埋点技术层面的区分：代码埋点、可视化埋点和无埋点。
（1）代码埋点
以为需要监测网站上/app上用户的行为，是需要在网页/app中加上一些代码的，当用户触发相应行为时，进行数据上报，也就是代码埋点。这样的代码，在网站上叫监测代码，在app中叫SDK（Software Development Kit）。市场上的第三方数据采集均支持代码埋点，GA, GrowingIO，神策等。
优点：可以详细的设置某一个事件自定义属性；
缺点：时间、人力成本大，数据传输的时效性。
（2）可视化埋点
利用可视化交互手段，数据产品/数据分析师可以通过可视化界面（管理后台连接设备） 配置事件，如下是腾讯移动分析的可视化埋点界面。可视化埋点仍需要先配置相关事件，再采集。





优点：埋点只需业务同学接入，无需开发支持；
缺点：仅支持客户端行为。
（3）无埋点
无埋点是指开发人员集成采集 SDK 后，SDK 便直接开始捕捉和监测用户在应用里的所有行为，并全部上报，不需要开发人员添加额外代码。
数据分析师/数据产品 通过管理后台的圈选功能来选出自己关注的用户行为，并给出事件命名。之后就可以结合时间属性、用户属性、事件进行分析了。所以无埋点并不是真的不用埋点了。
优点：
无需开发，业务人员埋点即可；
支持先上报数据，后进行埋点。
缺点：
数据量大；
仅仅支持客户端。
无埋点和可视化埋点均不需要开发支持，仅数据业务同学进行设置即可。但两者数据上报-埋点设置存在加大的差异：无埋点支持在数据上报之后再进行埋点设置，因而数据采集/上报的量远大于可视化埋点。
因而无埋点的数据大都有清空机制，例如growingIO，允许版本发布后7天内设置埋点，超过7天数据清空，无法追溯。
4.2 埋点技术：客户端埋点 & 服务端埋点
（1）客户端埋点
好处：
能够搜集页面展示、点击行为；
可以收集不需要请求服务器的数据，如音乐的本地播放、页面停留时长等。
缺点：
由于数据上报需要网络，当用户产生行为而没有网络时，则会延迟上报数据，影响数据的实时性。这点在工具型产品上表现尤其强烈。
如果用户删除自己的APP操作记录，或者无网连接时数据存储达到上限，则会造成数据丢失，影响数据的完整性。
当需要改变埋点时，需要更新版本才行，但是会存在有些用户不更新版本情况，影响数据质量。
（2）服务端埋点
优点：
实时性好：实时收集，数据很准确，不存在延时上报；
变更成本小：当要改变埋点时，只要改变，上报数据就会改变；
能够收集不在APP内发生的行为，只要请求服务器就行，而客户端只能收集在客户端中的操作行为，如统计从其他APP引流的安装量。
缺点：
不能收集不需要请求服务器的数据；
用户没联网的时候不能够采集数据。
当前大多数产品&公司都是客户端、服务端相结合。
（3）各种埋点场景&埋点建议
客户端数据：页面点击数据，比如：tab栏的点击，某个icon的点击（各入口点击对比使用情况，统计页面点击行为的转化漏斗）。
服务端数据：安装数据，下载后安装情况；内容数据，比如某个视频内容 曝光/展示/播放数据；搜索内容。
以视频产品为例的一次埋点过程：
1. 明确产品动态，梳理数据需求；
当前为一个视频社区软件，增加了**舞蹈跟拍**功能，用户可以根据不用的舞蹈来进行拍摄（运营同学对舞蹈进行了分类，主打几个舞蹈），目的是为了给用户提供低成本创造视频内容的方式。
基于上述的产品目的，期望能了解：
a.该功能的使用情况（uv，pv，使用过程漏斗）;
b.生产的视频情况（视频数,视频的互动情况），是否能实现促进内容生产带动社区氛围的目标。
2. 数据需求转化为指标&埋点，并与数据开发进行讨论；
a.功能使用uv、pv；
b.对其他拍摄功能的影响；
a，b：可以服务端打点，也可以客户端打点，但因为视频社区的基于内容的互动行为基本都在服务端，所以建议服务端打点。
c.拍摄流程的转化漏斗；拍摄流程主要是页面的点击过程，故使用客户端埋点，并记录uv，pv。
d.跟拍视频的播放、点赞、评论、分享、关注、二次被跟拍的情况；
f.跟拍舞蹈的类型，明确用户是否偏向于某个类型的舞蹈跟拍；
d，f服务端，基于内容的互动行为基本都在服务端。
3. 版本上线；
4. 按照预期进行数据分析，产品迭代复盘。数据分析过程，注意查看是否与预期相符，是否有优化点。
在了解埋点知识时，参考的文章，在此非常感谢： https://blog.csdn.net/heatdeath/article/details/72817838 http://www.chinawebanalytics.cn/auto-event-tracking-good-bad-ugly/ https://blog.csdn.net/wangyiyungw/article/details/80179730 https://www.cnblogs.com/111testing/p/7672833.html https://blog.csdn.net/wangyiyungw/article/details/80179730 https://www.zhihu.com/question/36411025/answer/144973846
 
本文由 @cecil 原创发布于人人都是产品经理。未经许可，禁止转载