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

一、什么是事件?

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

  • 什么是事件

    • 追踪或记录的用户行为或业务过程(注册账号,登录,观看视频,点赞,评论,关注等等)
    • 事件三要素
      • 操作(action):定义一个操作动作(如点击、拖拽)
      • 参数/属性:参数可以是任何和这个事件相关的属性,包括触发这个事件的(人、时间、地点、设备、操作的业务信息)
        • 举例:

          • 对于一个“购买”类型的事件,则可能需要记录的字段有:商品名称、商品类型、购买数量、购买金额、 付款方式等;
          • 对于一个“搜索”类型的事件,则可能需要记录的字段有:搜索关键词、搜索类型等
          • 对于一个“点击”类型的事件,则可能需要记录的字段有:点击 URL、点击 title、点击位置等
          • 对于一个“用户注册”类型的事件,则可能需要记录的字段有:注册渠道、注册邀请码等
          • 对于一个“用户投诉”类型的事件,则可能需要记录的字段有:投诉内容、投诉对象、投诉渠道、投诉方式等
          • 对于一个“申请退货”类型的事件,则可能需要记录的字段有:退货金额、退货原因、退货方式等。
      • 属性值:参数/属性的值参
        • 举例: 参数和值以kv形式存储在json串中

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

二、埋点

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

1. 代码埋点(客户端)

  • 原理

    • 要统计某页面一个Button点击事件次数。首先在APP或者界面初始化的时候,初始化埋点SDK,然后在这个Button事件发生时就调用SDK里面相应的方法,发送接口发送数据
    • App端为了避免浪费用户的流量,一般情况下,都是将多条数据打包,并且等待网络状况良好以及应用处于前台时才压缩上传
  • 优点
    • 控制精准: 可以非常精确地选择什么时候发送数据
    • 自定义:随意自定义属性、自定义事件
  • 不足
    • 人力成本高

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

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

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

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

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

三、参考:

时间: 02-17

用户行为的深度追踪——事件与埋点的相关文章

iOS 运行时RunTime使用场景一:打点统计用户行为,深度解耦

转自:http://www.jianshu.com/p/0497afdad36d 用户统计.jpeg 用户行为统计(User Behavior Statistics, UBS)一直是移动互联网产品中必不可少的环节,也俗称埋点.在保证移动端流量不会受较大影响的前提下,PM们总是希望埋点覆盖面越广越好.目前常规的做法是将埋点代码封装成工具类,但凡工程中需要埋点(如点击事件.页面跳转)的地方都插入埋点代码.一旦项目越来越复杂,你会发现埋点的代码散落在程序的各个角落,不利于维护以及复用.本文旨在探讨利用

控件不接收用户交互的情况以及事件响应顺序

开发中经常会遇到控件不接收用户交互了,可以从以下几个方面检查: 1. enable = NO 就不可以被点击 ->也会让按钮显示禁用状态 2. 设置了控件的 userInterActionEnabel = NO 3. hidden属性为YES 4. 控件的alpha < = 0.01 5. 如果一个父控件与用户的交互设置为NO ,那么它子控件将获取不到交互事件 6.如果子视图超出父视图范围,超出范围的部分也不能接收用户交互 7. 触发事件的过程 1). 交互事件,是先由父控件获取到,然后父控件

Ubuntu 14.04 用户如何安装深度音乐播放器和百度音乐插件

播放本地音乐或者收听国外的音乐电台,Ubuntu 14.04 自带的音乐播放器 Rhythmbox 完全能够满足,但是如果你想有像酷狗那样的国内播放器就需要折腾一下,还好有深度音乐播放器,这是一款完全为中国人开发的音乐播放器,深度音乐播放器(Dmusic)+ 百度音乐插件=酷狗,但是如果是deepin系统用户就完全不需要折腾了.先截图一下: 安装方法 (注释:我的系统是Ubuntu 14.04 其他系统没有实验,所以不保证是否成功) 先安装深度音乐播放器,安装很方便,有PPA可用,不过安装之前需

接入微信公众平台开发之用户关注(取消)事件触发后台自定义消息体通知给用户的实现过程

1.需求:用户关注公众号后回复给用户一个字符串,字符串不能重复使用即如果a用户关注公众号后商户后台回复给用户字符串str1后,b用户关注就是其他字符串,且a用户取消关注再次关注不回复消息体 2.实现过程: ①首先配置服务器url并开启,再次过程中需要微信后台与商户后台进行通信,所以,微信后台会发送请求,商户平台自定义接口回复相关内容即可完成通信. ②原理图: ③代码实现: a.pcodecontroller:定义的一个接口类,用来处理微信服务器发送的请求 1 package com.java.z

如何禁止用户连续点击一个按钮事件详细JS

<input type="button" id="submit" value="提交"> <script> $(document).ready(function(){     $("#submit").click(function(){       var nowTime = new Date().getTime();     var clickTime = $(this).attr("cti

基于无埋点技术的用户行为分析

用户行为分析从狭义来看是用户的行为数据分析,但是广义来说这一个词包含用户分析,用户行为的结果分析,用户的行为分析.用户行为的结果和用户的行为分析是不一样的,一个是结果,一个是过程.现在国内市场上关于用户行为分析的产品分为基于前台数据的用户行为分析和基于后台数据的用户行为分析.基于前台技术的用户行为分析侧重于用户的行为分析,而基于后台技术的用户行为分析侧重于用户行为的结果分析.这两类产品可以说是有一定的片面性,完成的只是用户行为分析的一部分.基于这个现状来谈谈全面的用户行为分析应该怎么做.这篇文章

Cookie已经过时,细看Facebook, Google, Apple如何追踪用户

http://www.infoq.com/cn/news/2014/10/cookie-facebook-google-apple 链接地址 Cookie,有时也用其复数形式Cookies,指某些网站为了辨别用户身份.进行session跟踪而储存在用户本地终端上的数据(通常经过加密).最早是网景公司的前雇员Lou Montulli在1993年3月的发明.Cookie是由服务器端生成,发送给User-Agent(一般是浏览器),浏览器会将Cookie的key/value保存到某个目录下的文本文件内

数极客vs百度统计深度对比

声明:本测评时间为2018年1月,若信息有误或更新请反馈至邮箱:[email protected].测评报告仅供参考,因采购该服务产生的任何争议与本文无关,文章版权归作者所有,未经授权不得转载. 编者按:企业在选择用户行为分析工具时,大都不知道如何选择适合自己的用户行为分析工具.笔者自己公司之前用的是百度统计,去年7月份同时接入了数极客的分析平台.在同时使用了这两款行为分析产品后,笔者从两款产品的定位.数据接入方式.定量分析功能.定性分析功能.二次开发与扩展.服务项目等六个主要方面深入对比百度统

国内主流新一代用户行为分析系统选型过程分享

企业在选择用户行为分析工具时,大都不清楚如何选择适合自己业务的用户行为分析工具.笔者自己公司之前网站分析用百度统计APP分析用友盟,公司是做电商行业的,最近公司提出要精细化运营,用数据驱动业务增长,因此在10月份分别考察了国内做得比较出色的几家公司:数极客(阿里系).神策数据(百度系)和GrowingIO(LinkedIn系)三家公司的用户行为分析产品. 我在选型过程中将各家公司的功能和服务对比文档进行整理,从团队背景和产品定位.数据接入方式.定量分析功能.定性分析功能.二次开发与数据应用.服务