《七天数据埋点之旅》第四天 埋点设计（下）

关于作者：我是水大人，资深潜水员，一个基于开发、面向分析、走向全栈的饱经摧残的数据新手，爱折腾不爱玩，爱总结爱思考的老兵，错了改改了又错的惯犯。

0x00 前言

在上节中我们介绍了埋点设计时四种主要思维方式，本节我们挑选典型的疑难埋点场景进行埋点设计。通过本节的阅读，你将获得以下典型场景埋点设计的认知：

• 刷新流
• 列表式
• 点击相关
• 联动演化

0x01 刷新流

刷新流又称服务流，是在新闻资讯类APP中常见的交互形式，随着用户不断的滑动，内容不听的更新，根据刷新的方式有分为全部刷新和增量刷新，而增量刷新有时候在页面的顶部，有时在页面的底部。对于刷新流埋点我们要终端关注上报的数据信息和上报时机。

上报数据：

• refresh_num：第几次刷新（0代表首次进入，没有刷新）
• refresh_id：刷新id(包括下拉刷新和加载更多)
• refresh_type:是否系统自动刷新，sys-系统自动刷新，manual-用户触发刷新
• position：元素刷新部分的位置(在每次刷新中的位置)
• rn:元素位于列表位置(在所有刷新中的位置)
• sessionid:用户一次连续使用id(用户首次进入首页生成，顶部刷新时更新

上报时机：

• 一般先加入缓存，缓存满多少条上报，或者结合一些其它的上报时机。上报完成之后清空缓存，新曝光的加入缓存，等待新的上报时机被触发。
• 用户来回滑动也正常加入到缓存中，回滑加入缓存不去重

0x02 列表式

曝光事件的处理是埋点设计中最难的部分，其中尤以上报时机和上报格式最为考研埋点设计人员的能力，下面结合给出作者的经验设计。

上报时机

曝光上报的一个基本原则是用户可见(离开之后再次可见算二次曝光)，上报时机有以下几种处理方式：

简单式：

离开页面的时候上报所有已曝光过的内容，但可能出现的问题对于刷新流的内容形式，一次上报的内容可能超出了限制，造成数据丢失。

混合式：

混合式的上报在简单式的离开上报基础上增加了缓存条数的触发上报条件，缓存达到了指定数目之后，则将缓存过的数据进行上报，同时清空缓存等待新的曝光条目加入。

综合起来，在处理曝光事件的上报时机的时候要充分的考虑以下场景：

• 缓存数据满上下滑动等的重复曝光是否加入缓存快速滑动是否加入缓存
• 离开tab切换（内容是否刷新）实体键返回/软键返回息屏（息屏之后解锁）折叠展开隐藏的内容浮层/弹窗等遮挡进下级页面

上报格式

列表式的曝光常采用多条一起上报的方式，每个条目有共性和个性属性两部分，一般设计如下：

# 公共属性
page:xx
src:xxx
# 个性属性:个性元素之间用‘;’分割，同元素不同属性之间‘,’分割 
contentlist:"a=1,b=2,c=3,d=4;a=5,b=6,c=7"

其中对于个性属性的上报，又有以下两种常用的方式（以今日头条新闻推荐tab下的列表项为例）：

• json嵌套

-- 多源埋点(info:string(json格式)) {
"page":"mp", /*不要求key唯一,高扩展性*/ "contenlits":[
{"type":"娱乐","auth_id":"111","rn":1,"id":"v111"}, {"type":"政治","auth_id":"222","rn":2,"id":"v222"}, {"type":"科技","auth_id":"333","rn":3,"id":"v333"},
],
/*要求key唯一*/ "contentlist2":{
} }
"v111":{"type":"娱乐","auth_id":"111","rn":1}, "v222":{"type":"政治","auth_id":"222","rn":2},

• 固定分割

# 内容公共属性 
page:mp
# 内容个性属性 
contentlist:
"type=娱乐,auth_id=111,rn=1,id=v111; type=政治,auth_id=222,rn=2,id=v222; type=科技,auth_id=333,rn=3,id=v333;"

注意事项

在处理曝光内容的时候，有以下几点需要提前考虑：

• 重复曝光是否计算在内，即集合和列表的区别。
• 悬浮的授权弹窗下的页面曝光，需要授权弹窗消失后才能上报

0x03 点击相关

点击延后

点击埋点的上报时机一般不存在疑问，即点击发生时候或者点击结果返回时上上报，但在处理一些特殊场景的时候合理的制定上报时机，会给后续数据处理带来极大便捷性。典型的使用场景是单页面批量操作，具体如下：

• 单选或多选、然后一起操作(操作结果:关注/删除/移动)
• 单选，每个选择有单独的操作结果(页面不发生跳转)，整个页面是每个操作的结果组合

以上两种场景，建议离开当前页的时候上报该页面操作的结果，可 以选择上报所有操作之后的最终态，也可以记录修改态(增什么减什么保留了什么，开什么关什么不变什么)

点击附着

具有附加信息的点击事件上报，建议单独拿出来，这是因为每个点击对象都导致不一样的结果，而这些 结果有时候又没有共性(有共性的情况下可抽象成一个点击事件)。具体的点击附着场景如下：

• 点击评论这个事件，就附着了评论的id、评论作者的id等信息，如果归结到统一的点击事件，就需要加额外的信 息。而这些信息是其它的点击事件所不具备的，例如点击返回(就没有附着的对象id)
• 点击具有跳转能力的对象，就要记录点击的位置，跳转前的属性(比如当前url)和跳转后的属性(比如跳转url) - 点击具有红点提示和消息条数提示的控件，则需要上报控件的状态(是否有红点或消息条目的多少)
• 点击具有附带结果，比如关注等，附带结果是否要上报(牵涉到上报时机)

点击信息表

对于某些特殊的入口型应用，或者具有丰富内容形态的产品，有很多的交互设计，点击不同的地方，跳转不同的位置，甚至相同的位置，随着后台的配置不同而跳转不同的地方。这种具有丰富的复杂的跳转关系情况下，如果继续采用属性和属性值堆叠的方式，不仅不能很好的体现属性值之间的组合情况，以便测试和其它人员进行针对性的测试，也不利于使用人员快捷的进行点击信息的统计，此时建议采用信息表的方式来设计，其形式如下：

说明：

• 点击区分重点按是否点击率计算的分之来区分
• 跳转区分是否跳转跳转到应用自身还是第三方
• 跳转地址若是应用内部的跳转，直接用对应的页面编码即可应用外部的跳转，若是拉起具体的应用，则给出具体的包名，若是地址形式，则直接给出地址

0x04 联动演化

联动

联动是指显性的某些操作引起其它地方状态改变的一些关联变动（而这些变动同样可有其它的显性操作引起），这个时候要注意被联动的状态改变的上报（同时也要注意区分出状态改变的原因），这些联动可以是层级的关系（上层关闭，下层自动关闭），也可以是平级的关系。比如一些内容服务类的app，提供内容类型的关注，并同时可定制内容子类型，当子类型全部删除后，则父类型自动取消关注。这种情形下，父类型的取消关注就会有两种方式，一种是直接取消父类型，一种是通过对子类型的操作联动父类型的改变。另外一些隐性的联动也可以通过事件映射的方式下沉到埋点层解决，如果没有这个将同类型操作结果的事件在底层映射成一个，很容易造成埋点遗漏，如果后面又利用此事件建立了开关累积表，则统计的准确性大大降低，而且修复起来也很复杂。

演化

演化是指在一个行为发生的过程中该行为附带的属性会发生变化，比如在一次播放过程中清晰度的切换、暂停和继续、播放器界面的小屏和大屏切换等，或者随着时间推移弹窗内容的改变等，这些存在演化的行为，一般的建议是用一个标示符串联起来，比如播放用的sessionid串联一次完整的播放，下单过程的产生订单id（注意区分成功之后的订单id）,在某些场景要求不细的情况，可合并到事件的某个阶段一起来上报，不用拆分阶段来追踪整个链条。

0x05 总结

本节对埋点设计中常见的刷新流、列表式、点击相关、联动演化四种常见情形讲解了埋点设计的方式，当然埋点中并不仅仅这几种方式，从统计需求出发，结合实际的场景，才是埋点设计的根本出发点。