数据埋点学习

参考资料：

《三节课互联网数据分析实战》模块五 数据采集 神策

《数据运营：系统方法与实践案例》 第四章

《前端埋点的那些事》 慕课网

《掌握数据生命周期：初识数据埋点》公众号 秦路

学习目标：

了解埋点基本情况，业务方需要在埋点项目上做什么角色？埋点中常见的误区是什么？埋点如何指导业务分析，产品迭代，用户研究。

目前缺少：

埋点后数据分析内容。

---

埋点的原因

案例1：酒店预定页面

只统计了预定页面的点击情况，跳出情况。但预定页面信息量多，比如选择房间套餐情况，优惠券查看情况，因为没有埋点无法查看用户的点击查看行为，进而无法优化页面信息展示。

案例2：外卖投诉情况分析

平台外卖提供两种配送方式：自有配送，第三方配送。在外卖投诉上升情况下，想对投诉原因做一个分析，初步思考方向是在外卖配送方式不同下，做比对分析，查看不同方式是否有明显差别。但发现由于未收集外卖平台选择情况，无法分析。

埋点困境

困境一：在进行专项分析前，其实产品方也可能不知道要采集哪些信息。未来对某项内容的分析可能用到哪些数据，属性。

困境二：产品方明确了埋点需求，但可能不了解埋点技术，所以在与RD沟通时，存在偏差，比如某个埋点的触发时机彼此理解不同，导致收集的数据统计口径有差异。技术方思考的问题核心是埋点形式（前端or后端埋点？埋点难度？维护成本？）

案例：如何采集用户支付

需求：统计用户平均完成一次支付在支付页面要停留多久

问题：支付有成功支付和不成功两种，在前端埋点统计“立即支付”的点击，只能统计点击了支付的人数。如果统计支付成功的，只能在后端做埋点统计，这样就不能知道用户在前端什么时候点击的时间点。

解决方法：设置埋点文档DRD

DRD

埋点项目流程：

需求——>指标——>埋点

案例：共享出行APP的数据需求

需求：需求来自多个部门：产品经理和运营部门

产品经理：交易模块的检测-交易总金额，详情页转化率

企业出行部门：企业版入口点击率，该渠道用户付费转化率

从需求到埋点

埋点需要收集哪些属性？

埋点可能出现的问题：埋点收集的信息过于简单

案例：新浪微博登陆页埋点

可以埋点的地方很多，埋点的主要逻辑就是用户点击后，返回一个参数告诉服务器pageview+1。但如果埋点只返回这么一个值（信息），在后续分析的时候就只能单纯计数

埋点数据收集太少

包括：who，what，when，where，how

其中：

who的确认方式包括cookie，uuid，idfv等，还有账号，手机号（设备id和用户id）

when包括事件发生时间，事件上报时间，事件接受时间，事件入库时间。以用户的角度，事件发生事件是真正的时间，但埋点的上传可能不是同步的，同时，意外情况下，导致时间不匹配，比如用户突然断网，导致事件上传时间延迟。

where 包括GPS和IP，自主填写（产品可能与地理位置有关，比如租房app，打车app）

how用户如何做的？从哪个页面跳转过来的，使用的环境是怎样的？（设备，工具）

what尝试去描述一个事件，直到能基本能唯一确认这件事，比如购买事件，包含哪些？购买的产品是什么？价格是什么？付款的方式是什么？购买的数量是什么？

事件本身

一个事件基本要收集的信息内容

一个事件的数据收集表

埋点案例：社交媒体产品首页的feed改进

背景：互联网学习交流的社区媒体，产品首页是的feed主要来自用户的关注好友的产生的数据，但存在两个问题：一好友不多，产生不了更多内容。二关注的好友不爱发动态，进一步导致内容少。

问题：如何让用户的阅读范围跳出他关注的圈子

解决方法：上个性化feed，基于用户的阅读历史，好友关系，关注话题，当下热门进行推荐（跳出只在好友圈子）

需要对feed做数据分析

需求：

1.内容推荐模块：

content impression by user

各个内容的CTR

各个内容类型的曝光和点击需要能够分开查看

评论数和点赞数是否对阅读产生影响

2.技术部门的需求

每个卡片配“不敢兴趣”按钮

用户主动刷/加载内容

区分不同推荐理由

3.广告部门的需求

每天广告的曝光量以及ctr效果

广告曝光时长

从需求到指标：

内容卡片的曝光量

内容卡片的点击量

广告曝光量

广告的点击数

用户看到卡片的时长

主动刷新推荐feed的次数

主动滚动到底加载新内容的次数

点击不感兴趣的次数和原因

从指标到埋点：

通用属性是指每个埋点都要统一收集的信息。

通用属性

各个埋点需要收集的信息。根据前面的学习内容，事件本身不能只单单收集一个信息，比如卡片点击次数，除了收集卡片被点击的次数外，还要收集卡片内容，卡片类型，卡片位置，内容表现形式（有无图片）等等。如下图。

每个埋点的具体采集1 每个埋点的具体采集2

事件定义是为了解决埋点困境2，产品方和技术方对同一事件的触发时机理解不同可能会导致收集的数据口径有误。

在做好需求文档后，最重要的还有做埋点文档的管理，记录埋点时间，app版本，上线时间等。