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

时间  2019-11-16 标签 用户 行为 深度 追踪 事件 埋 点

1、什么是事件？

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

  • 什么是事件ios

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

    • 事件三要素json

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

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

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

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

2、埋点

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

1. 代码埋点(客户端)

  • 原理网络

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

  • 优势架构

    • 控制精准: 能够很是精确地选择何时发送数据
    • 自定义：随意自定义属性、自定义事件

  • 不足app

    • 人力成本高

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

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

      每一次更新埋点方案，就意味着必需要修改代码，而后经过各个渠道进行分发，一旦有至关多数量的用户对新版的更新不感冒时，致使埋点代码可以采集到的数据也就得不到更新，前功尽弃,很难在实际平常运营中可以及时依赖实时数据捕获焦点作出应变

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

  • 应用场景和产品举例

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 的时候数据就一直都在收集了
    • “无埋点”方案也能够自动获取不少启发性的信息，例如，“无埋点”能够告诉使用者这个界面上每一个控件分别被点击的几率是多大，哪些控件值得作更进一步的分析等等

  • 缺点

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

  • 与可视化埋点的区别

    • 可视化埋点先经过界面配置哪些控件的操做数据须要收集
    • “无埋点”则是先尽量收集全部的控件的操做数据，而后再经过界面配置哪些数据须要在系统里面进行分析

  • 应用场景和产品

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数据采集和发送规范，根据业务定制化埋点

3、参考：

联系我们 沪ICP备2021010478号-7