大家好，因为最近工作比较忙和辅导的原因，更新的时间间隔久了点，有些同学问我咋还不更新，今天我来了。今天给大家分享一下数据全生命周期的起点，互联网行业最主要的数据获取手段–数据埋点。
埋点这个词对于大部分非互联网行业的同学，可能会有点陌生，所以这次分享不会涉及复杂的埋点类型和数据结构，而是更偏向于在感性理解的角度帮大家建立起对埋点的认知，当大家每打开一个app的时候，可能就会自然的想到这里这里可能是有埋点的。
01 什么是埋点？
埋点通俗的讲，就是收集用户行为数据的一种手段，大部分同学可能都知道我们在app上的点击、浏览等行为都是可以被记录的，你看了什么点了什么企业都一清二楚，基于这些数据才能做出一些个性化的推荐。大部分情况下，数据被记录都有一个前提条件，就是这个行为已被埋点，如果没有埋点的话，你的点击、浏览等行为数据是不会被上报的。
数据分析师的职责之一就是要确定哪些点需要埋、应该怎么埋、点的名称是什么、需要带什么参数。有同学可能会问，为什么不能把用户所有的行为都埋下来呢？原因是埋点开发也是有成本的，一般是由ios和andorid的开发去完成，如果埋很多不必要的埋点的话一是会增加开发的工作量，二是在后期的维护上也会比较困难。
02 埋点应该怎么设计？
数据分析师在实际埋点的过程中，一般都是参考产品的prd文档和设计的ui稿去确定哪些地方需要埋点，我们以知乎为例。大家看到知乎app推荐feed流的这张截图能够想到哪些地方需要打埋点么？
我们对知乎首页的模块进行划分，可以看到首页主要可以分为7个大模块，对于同一个大模块，我们可以考虑用一个事件名称埋点，用参数区分不同的子模块，下面我们一个个来看。
首先埋点是由什么构成的呢？简单来说，由事件名称和参数两部分构成，以模块1为例，这个模块由【首页】、【会员】、【消息】、【我的】四个子模块构成，对于这个模块，我们可以设计一个通用的底部模块点击事件，‘bottom_tab_click’，同时我们还要区分出用户点击的是哪个tab,所以这个事件里面可以再加一个参数 tab_name 来进行区分，比如用户点击了【首页】，那么上报的事件格式就会如下所示
event :bottom_tab_click
params : {tab_name :‘首页’}
除了事件的特定参数外，埋点通常还会有一些公共参数，比如用户的设备id，带有设备id我们才能知道这个行为是由哪个用户触发的，这是每个埋点都会带的公共参数。
再来看一下模块3–feed流模块，也是首页最重要的一个模块，以这个模块为例我们再来讲一下埋点设计中的注意事项。首先对这个模块应该至少有两个埋点，一个是回答曝光埋点，一个是回答点击埋点。
回答曝光埋点字面意思是当回答出现在用户视野中的时候，上报一个曝光埋点，我们就知道用户看到了这篇文章。但有一个细节需要注意，就是事件上报的时机，对于每一个埋点，数据分析师都必须要明确上报的时机是什么。
曝光事件上报的时机大部分同学的理解可能是和字面意思相同，当回答出现在用户视野时上报，但实际上feed流中曝光事件上报的时机一般是在问题或文章离开用户视野时上报
为什么要在离开时上报呢？主要的原因是为了获取到一个很重要的参数，回答在用户视野中的停留时间，只有在离开视野时上报，我们才能统计到这个问题在用户视野中停留了多久。对应的事件和参数为：
event: answer_impression
params:
{question_id（问题的id）、
answer_id（回答的id）、
author_id（答主的id）、
duration（问题停留时间）}
再设计一个点击的埋点
event: answer_click
params:
{question_id（问题的id）、
answer_id（回答的id）、
author_id（答主的id）}
这么来看的话，是不是埋点设计还比较简单？但其实埋点设计中还有两个细节要注意：
第一点是事件上报的时机需要考虑到非常规情况。
- 在前面我们定义了feed流曝光事件上报时机是当回答从用户的视野中消失时上报，但消失这个行为也存在多种方式，比如用户上下滑动信息流导致回答消失在视野中，这是最常规的消失。浏览过程中切换到别的tab，回答也会从用户视野中消失。再额外的，用户可以直接在feed页退出app，这种也算是回答在用户视野中消失，也是需要上报曝光事件。
- 在设计埋点时，数据分析师需要考虑这些非常规情况是否也要上报。如果没有和开发明确在切换tab和退出app也需要上报信息流曝光埋点的话，开发很有可能就不会在这两种情况下打点。
第二点是应考虑到同一事件在不同场景下触发的情况
- 除了在首页推荐feed流我们可以看到回答外，回答还会有其他的曝光场景，下图从左到右场景分别为：问题详情页、个人收藏夹、关注页、搜索页。这些场景下面也都会有问题的曝光，虽然它们是不同的场景，在我们设计事件的时候，这些应都统一归纳在问题曝光事件中，用参数进行区分，而不是每个场景一个事件。所以基于这个思想，埋点设计应为：
event: answer_impression
params: {question_id（问题的id）
answer_id（回答的id）
author_id（答主的id）
duration（问题停留时间）
page (代表问题的场景，比如问题详情页就是question_detail，推荐页就是search}
通过上面直观的理解，大家对埋点应该已经有了一个感性的认知，下面是头条的推荐feed流，你是不是能看出哪些地方会有埋点了呢？
以上，希望对大家有所帮助，我们下期再会。
