埋点-数据产品经理视角

一、数据过程

数据生产-数据采集-数据处理-数据分析和挖掘-数据驱动/反馈

eg.用户操作app时产生行为数据,通过数据采集系统采集,对采集的数据进行处理(实时数据处理+离线数据处理)得到统计数据进行数据分析 并将结果呈现出来以复盘总结当前版本并驱动下一个产品迭代,或者 清洗后的数据进行数据挖掘,实时反馈给用户(如推荐)。

数据采集,顾名思义采集相应的数据,是整个数据流的起点,采集的全不全、对不对,直接决定数据广度和质量,影响后续所有的环节。在数据采集失效性、完整性不好的公司,经常会有业务方发现数据发生的大幅度变化,追其所以时发现是数据采集的问题(见附注)。而另一方面,采集什么数据才能有效的得到数据分析结论,才能有效的进行推荐,就需要提前规划【埋点】。

当前数据采集普遍遇到的几个问题:

1.实时性,对于工具性产品在无网条件下的数据,无法实时上报;

2.完整性,由于用户隐私协议&欧盟通用数据保护条例的,部分数据无法采集;

3.异常,android_id、idfa、idfv 随版本升级变化 或 无法获取。

二、数据埋点

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

1.埋点是什么?

所谓“埋点”,是数据采集领域(尤其是用户行为数据采集领域)的术语,指的是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。

埋点的技术实质,是先监听软件应用运行过程中的事件,当需要关注的事件发生时进行判断和捕获,然后获取必要的上下文信息,最后将信息整理后发送至服务器端。所监听的事件,通常由操作系统、浏览器、APP框架等平台提供,也可以在基础事件之上进行触发条件的自定义(如点击某一个特定按钮)。

2.埋点是谁的工作

现在公司通常都会有数据产品经理 或 业务线数据分析师 结合版本迭代过程进行埋点。

3.when&where

埋点是目的导向。

在产品规划时就要思考数据埋点问题,如果在产品外发后再考虑怎么埋点,就会导致前期版本用户的数据无法收集,想要看某个数据时就无可奈何,只有等到新版本完善来弥补。

思考要埋哪些点、埋点的形式,需要紧密结合产品迭代的方向、运营需求,并和数据开发等进行充分沟通 以确认 1.埋点能够得到想要的数据解决/支持;2.能够得到当前版本的复盘情况;3.后续版本的数据支撑.

通常的沟通过程以 埋点文档为载体;数据埋点评审 为终结。

当前版本的复盘情况

(1).新版本功能使用情况,是否符合预期;

(2).新功能上线后对其他功能点的影响?是否为整体均有积极作用;

(3).版本运营活动目标群体的特征获取;

(4).新增商业化目标的监测...

后续版本的数据支撑

(1).规划方向的用户行为分析

(2).画像特征分析

5.为什么埋点

上述第一节已经讲过,不再复述。

6.怎么埋点呢?

     1).埋点技术

    监测代码、SDK和埋点

接着【埋点是什么?】来看下埋点技术层面的区分:代码埋点、可视化埋点和无埋点

    代码埋点

能够监测网站上用户的行为,或者app上用户的行为,是需要在网站的每一页或者app中加上一些程序代码的(这里就不考虑日志分析这种方法了),也就是**代码埋点**。这样的程序代码,在网站上叫**监测代码**,在app中叫**SDK(Software Development Kit)**。无论你是要监测网站,还是要监测app,你都必须加上这类代码,不加代码就收集不到数据。

优点:控制发送数据时间,事件自定义属性详细记录;

缺点:时间、人力成本大,数据传输的时效性。

    可视化埋点

利用可视化交互手段,通过可视化界面配置控件操作与事件操作发生关系,通过后台截屏的方式采集数据。

优点:成本低,速度快;

缺点:行为记录信息少,支持的分析方式少。

    无埋点

用户展现界面元素时,通过控件绑定触发事件,事件被触发的时候系统会有相应的接口让开发者处理这些行为。现在市面上主流无埋点做法有两种,一种是预先跟踪所有的渲染信息,一种是滞后跟踪的渲染信息。

优点:无需埋点,方便快捷;

缺点:行为记录信息少,传输压力大。

Question:无埋点是真的不用埋点么?

无埋点是指开发人员集成采集 SDK 后,SDK 便直接开始捕捉和监测用户在应用里的所有行为,并全部发送到分析平台,不需要开发人员添加额外代码。在分析时,业务人员通过分析平台的圈选功能来选出自己关注的用户行为,并给出事件命名。之后便可以对特定用户行为(事件)进行多维分析了。无埋点和可视化埋点是比较像,都不需要开发人员手工加代码,也都需要业务人员进行所关注的用户行为的圈选。**两者最大的不同是在用户终端的表现上,可视化埋点只采集业务人员关注的用户行为数据,而无埋点是会采集所有用户的行为数据,通常情况下数据量后者比前者大很多。**

客户端埋点 & 服务端埋点

客户端埋点的优缺点

好处

(1)能够搜集页面展示、点击行为;

(2)可以收集不需要请求服务器的数据,如音乐的本地播放、页面停留时长等。

缺点

(1)由于数据上报需要网络,当用户产生行为而没有网络时,则会延迟上报数据,影响数据的实时性。这点在工具型产品上表现尤其强烈。

(2)如果用户删除自己的APP操作记录,或者无网连接时数据存储达到上限,则会造成数据丢失,影响数据的完整性。

(3) 当需要改变埋点时,需要更新版本才行,但是会存在有些用户不更新版本情况,影响数据质量。

服务端埋点

**优点**

(1)实时性好:实时收集,数据很准确,不存在延时上报;

(2)变更成本小:当要改变埋点时,只要改变,上报数据就会改变;

(3)能够收集不在APP内发生的行为,只要请求服务器就行,而客户端只能收集在客户端中的操作行为,如统计从其他APP引流的安装量。

缺点

(1)不能收集不需要请求服务器的数据;

(2)用户没联网的时候不能够采集数据。

当前大多数产品&公司都是客户端、服务端相结合。

各种埋点场景&埋点建议

客户端数据:页面点击数据,eg.tab栏的点击,某个icon的点击(各入口点击对比使用情况,统计页面点击行为的转化漏斗)

服务端数据:安装数据,下载后安装情况;内容数据,eg.某个视频内容 曝光/展示/播放数据;搜索内容

以视频产品为例的一次埋点过程

1. 明确产品动态,梳理数据需求;

eg.当前为一个视频社区软件,增加了**舞蹈跟拍**功能,用户可以根据不用的舞蹈来进行拍摄(运营同学对舞蹈进行了分类,主打几个舞蹈),目的是为了给用户提供低成本创造视频内容的方式。

基于上述的产品目的,期望能了解 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

推荐阅读更多精彩内容