一、数据过程

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

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