用户行为的深度追踪——事件与埋点

一、什么是事件？

不同于传统的页面路径跳转追踪，事件尝试追踪用户在网站或APP上发生的每一个动作（包括浏览页面）

• 什么是事件

  • 追踪或记录的用户行为或业务过程（注册账号，登录，观看视频，点赞，评论，关注等等）

  • 事件三要素

    • 操作（action):定义一个操作动作（如点击、拖拽）
    • 参数/属性：参数可以是任何和这个事件相关的属性，包括触发这个事件的（人、时间、地点、设备、操作的业务信息）
      • 举例：
        • 对于一个“购买”类型的事件，则可能需要记录的字段有：商品名称、商品类型、购买数量、购买金额、 付款方式等；
        • 对于一个“搜索”类型的事件，则可能需要记录的字段有：搜索关键词、搜索类型等
        • 对于一个“点击”类型的事件，则可能需要记录的字段有：点击 URL、点击 title、点击位置等
        • 对于一个“用户注册”类型的事件，则可能需要记录的字段有：注册渠道、注册邀请码等
        • 对于一个“用户投诉”类型的事件，则可能需要记录的字段有：投诉内容、投诉对象、投诉渠道、投诉方式等
        • 对于一个“申请退货”类型的事件，则可能需要记录的字段有：退货金额、退货原因、退货方式等。

    • 属性值：参数/属性的值参

      • 举例： 参数和值以kv形式存储在json串中

          {"age": 13, "gender": "male", "photo filetype": "png"}

---

二、埋点

目前的埋点方式：
按埋点工具：代码埋点、可视化埋点、‘无埋点’
按埋点位置：前段/客户单埋点、后端/服务端埋点

1. 代码埋点(客户端)

• 原理

  • 要统计某页面一个Button点击事件次数。首先在APP或者界面初始化的时候，初始化埋点SDK，然后在这个Button事件发生时就调用SDK里面相应的方法，发送接口发送数据
  • App端为了避免浪费用户的流量，一般情况下，都是将多条数据打包，并且等待网络状况良好以及应用处于前台时才压缩上传

• 优点

  • 控制精准: 可以非常精确地选择什么时候发送数据
  • 自定义：随意自定义属性、自定义事件

• 不足

  • 人力成本高

    埋点地方过多，因为不同的版本验证问题不同不易于管理。每一个控件的埋点都需要添加相应的手工代码，不仅工作量大，而且限定了必须是技术人员才能完成

  • 版本更新的代价大，易造成埋点混乱

    每一次更新埋点方案，就意味着必须要修改代码，然后通过各个渠道进行分发，一旦有相当多数量的用户对新版的更新不感冒时，导致埋点代码能够采集到的数据也就得不到更新，前功尽弃,很难在实际日常运营中能够及时依赖实时数据捕获焦点做出应变

  • 数据传输的时效性和可靠性不好保证
    • 客户端埋点的痛病
  • 支持的统计大多是简单计数，无法完成完整的多维分析功能

• 应用场景和产品举例

  • 场景：常用于简单的pv统计，如网站pv、APP的DAU等宏观数据
  • 第三方产品：umeng TalkingData Google Analytics

---

2. 可视化埋点（客户端）

• 原理
  • 参考手游APP的做法，把核心代码和配置、资源分开，在APP启动的时候通过网络更新配置和资源
  • 在虚拟的可视化界面，对支持的控件类型的实例，点击配置事件(event)，然后发布，配置通过后端接口直接下发给APP，所有安装有嵌入SDK的APP都会在启动时或者定时获取相应的配置。以后，真实的用户使用时，点击这个按钮，就会发送事件到后端
  • 实现细节：
    1. 在嵌入了SDK的APP开启可视化埋点模式，与后端联通时，SDK会应后端的要求，定期（例如每秒）做一次截图，而SDK在为App截图的同时，会从keyWindow对象开始进行遍历它的subviews()，得到当前视图下所有 UIView、UIResponder对象的层级关系。对于屏幕上的任何一个UIView对象，如 Button、Textfield等它都有一条唯一的从keyWindow到它的路径，这个路径上每个节点，都由ClassName、它是父节点的第几个subview、.text()等属性的值等标识。相对于父节点的坐标、长宽高等可视化方面的信息，是作为这个节点的属性存在。
    2. 服务端根据截屏和可视化信息来重新进行页面渲染，并且根据控件的类型，来识别哪些控件是可以增加可埋点的，并且将之标识出来。
    3. 当使用者在后台的截屏画面上点击了某个可埋点的控件时，后台会要求使用者做一些事件关联方面的配置，并且将配置信息进行保存和部署。
    4. SDK 在启动或者例行轮询时拿到这些配置信息，则会通过.addTarget:action:forControlEvents:接口，为每个关联的控件添加的点击或者编辑行为的监听，并且在回掉函数里面调用 Sensors Analytics SDK 的接口发送相应事件的 track 信息。

event.png

• 优点

  • 可视化埋点很好地解决了代码埋点的埋点代价大和更新代价大两个问题。
  • • 新增埋点在所有版本生效，不存在老版本迭代问题（只要老版本app有嵌入sdk)
  • 不懂代码的产品运营人员也可以通过后台可视化界面配置统计埋点并实时下发到客户端生效

• 不足

  • 可视化埋点能够覆盖的功能有限的，目前并不是所有的控件操作都可以通过这种方案进行定制
  • 不能自定义设置事件属性
    • 例如对于评论“提交”事件，并不能将评论的内容作为事件的属性进行上传
    • 在上传事件时，就只能上传SDK自动收集的设备、地域、网络等默认属性，以及一些通过代码设置的全局公共属性了
  • 数据传输的时效性和可靠性不好保证
    • 客户端埋点的痛病

• 应用场景和产品

  • 场景：
    • 替代代码埋点，支持产品、运营等非技术人员管理埋点
    • 活动/新功能快速上线迭代时的效果评估，可利用可视化埋点快速完成
  • 第三方产品： 诸葛io MixPanel 神策数据

---

3. 无埋点（全埋点）（客户端）

Heap Analytics 作为最早提出这种方案提供商,早在2013年就已经推出了“无埋点”这个技术方案。后续的用户行为分析的大佬Mixpanel也在去年中期推出同样的服务，诸葛IO也借鉴了两者，在国内最早正式推出了三大平台的无埋点分析方案，同时，国内也还有TalkingData的灵动分析和Growing IO提供了无埋点分析解决方案

• 原理

  • 在App中嵌入SDK，做统一的“全埋点”，将APP的操作尽量多的采集下来，然后通过界面配置的方式对关键行为进行定义，这样便完成了所谓的“无埋点”数据采集
    1. 事先在产品上埋一个 SDK
    2. 通过可视化的方式，生成配置信息，也就是事件名称之类的定义
    3. 将采集的数据按照配置重命名，进而就能做分析了

• 优点

  • 解决了数据“回溯”的问题
    • 例如，在某一天，突然想增加某个控件的点击的分析，如果是可视化埋点方案，则只能从这一时刻向后收集数据，而如果是“无埋点”，则从部署 SDK 的时候数据就一直都在收集了
  • “无埋点”方案也可以自动获取很多启发性的信息，例如，“无埋点”可以告诉使用者这个界面上每个控件分别被点击的概率是多大，哪些控件值得做更进一步的分析等等

• 缺点

  • 与可视化埋点一样，“无埋点”依然没有解决覆盖的操作有限问题，不能灵活地自定义属性
  • 数据传输的时效性和可靠性不好保证
    • 客户端埋点的痛病
  • 由于所有的控件事件都全部搜集，可能会给服务器和网络传输带来更大的负载

• 与可视化埋点的区别

  • 可视化埋点先通过界面配置哪些控件的操作数据需要收集
  • “无埋点”则是先尽可能收集所有的控件的操作数据，然后再通过界面配置哪些数据需要在系统里面进行分析

• 应用场景和产品

  • 场景：和可视化埋点相同
  • 第三方产品：Heap Analytics Growing IO

---

4. Google Measurement Protocol

上述的三种埋点都是在客户端埋点，都需要客户端嵌入sdk
为避免浪费用户流量，都需要定时或定量的批量打包发送数据

• 原理

  • 在需要埋点/追踪事件的地方（客户端或服务端）,以规定的格式/规范/协议，把相关的事件属性信息以及相关字段通过HTTP请求发送到指定的接收服务器

• 优点

  • 实时发送数据，不存在数据延时
  • 将线上和线下行为联系在一起
  • 可同时从客户端和服务器发送数据

• 缺点

  • 需要手动在代码中埋点
  • 考虑到用户流量消耗问题，不可能把所有的用户事件都埋点
  • 新的埋点需要发新版

---

5. 几种埋点的典型使用场景对比

• 举例：以电商APP的订单结算页面为例，当用户点击去结算按钮

  • 可视化埋点与无埋点只能采集到用户在某时某刻点击了去结算
  • 客户端单代码埋点能采集到去结算订单的金额，商品名称、用户等级等客户端可以获取的信息
  • 服务端代码埋点可以采集到商品库存、成本等其他关联的信息

• 总结：

  • 可视化埋点使用和部署比较简单，但数据获取能力有限
  • 客户端代码埋点埋点复杂，能拿到在客户端保存的信息
  • 服务端代码埋点能获取到事件以外的关联属性，但部署会影响线上业务代码逻辑和架构，对于这种外围信息，建议离线做join完成

埋点方式	数据时效	数据可靠(安全)	数据可回溯	埋点成本	对业务的影响	用户流量开销	新埋点是否对所有客户端版本生效
传统代码埋点	X	X	X	X	X	X	X
可视化埋点	X	X	X	X	√	√	√
无埋点	X	X	X	√	√	√	√
Measurement Protocol	√	√	X	X	X	√	X

    数据可回溯是指当上新的事件埋点统计后，支持对历史数据（埋点之前的日期）的统计，且不用回滚数据

---

6. 我们的选择

A、可视化埋点/无埋点:
产品或技术对 活动/新功能快速上线迭代时的效果评估，可利用可视化埋点快速完成
具体采用哪种方案还要考虑客户端代码改动成本

B、参考Measurement Protocol数据采集和发送规范，根据业务定制化埋点

三、参考：

• 数据采集与埋点
• HEAP
• MIXPANEL
• 事件模型
• Google Measurement Protocol
• 埋点参数参考