zoukankan      html  css  js  c++  java
  • 数据产品-数据埋点-02

    1.埋点方式

    1.1客户端埋点

     

    1.1.1代码埋点

    代码埋点主要有app研发手动在程序中写下代码进行统计,通过触发某个动作后程序自动发送数据。

    优点:具有很强得灵活性,可以控制发散得时间和发散方式等。

    缺点:人力成本和维护成本太高,需要以来app发版生效

     

    1.1.2可视化埋点

    可视化埋点以前端可视化的方式记录前端设置页面元素与对其操作的关系然后以后端截屏的方式统计数据。
    优点:简单、方便,能够快速地埋点。

    缺点:比较受限,上报的行为信息有限。

    1.1.3无埋点

    无埋点绑定项面的各个控件,当事件触发时就会调用相关的接口上报数据。
    优点:不需要埋点,方便、快捷、省事。

    缺点:传输数据量比较大,需要消耗一定的数据存储资源。特别是数据量多的时候

    1.2后端埋点

    其实数据埋点不仅有客户端前端埋点,还有服务器后端埋点,它能够收集不App内发生的行为,只要有网络请求就可以记录下来,它能够实时收集,不存在延时上报的问题,但是没有网络就很难收集到数据,这也是服务器后端埋点的一个弊端。因此,很多公司都会结合客户端前端埋点和服务器后端埋点两种方式一起埋,服务器后端数据实时性强、很准确,用户需要请求服务器的关键业务量最好均使用服务器后端埋点(例如支付),例如,要根据埋点数据统计中奖用户信息,显然服务器后端数据更合理,客户端前端数据可能会漏掉部分中奖用户,导致用户投诉。

     

    总结:

    客户端前端数据很全,记录了用户绝大多数的操作行为,其他非关键业务量或者不需要请求服务器的行为可以使用客户端前端埋点。服务器后端理点和客户端前端理点各有优劣,应该两种数据都同时存在,可以相互印证,当一方数据发生重大向题时可以通过另一方发现。同时,数据也能互补,如一方数据采集突然有问题了,可以用另一方数据替代。但是,由于前端埋点和后端埋点的埋点方式不同,统计的数据难免有差异,不要纠结于两者的数据为什么对不上,而更应该结合两者互相验证。




    2.埋点事件类型

    在记录埋点信息时,主要的埋点事件分为点击事件、曝光事件和页面停留时长三类。

     

    2.1点击事件

    用户每点击页面上的一个button一下都会记录一次数据。

     

    2.2曝光事件

    详细的曝光事件参考第一篇“数据产品—数据埋点”当用户成功进入一个页面时记录一次数据,当刷新一次页面时候也会记录一次数据,如果通过手机home切换出去,则不会记录,因为已经脱离了app,此处记录也没有太多分析价值,记录上还可能受到污染数据。

     

    2.3页面停留时长事件

    页面停留时长主要用来记录用户在一个页面的停留时间,它可以通过记录用户进入页面的时间T1和离开页面时间T2计算,计算公式可以简单表示为:用户停留时长=离开页面时间T2—进入页面时间T1。

     

    2.4 曝光事件

     

    2.5 刷新事件

     

    2.6通知事件

    如推送,消息通知....

     

    3.埋点实例

    现在App端的数据埋点一般采取Key- Value的形式,Key一般表示某个事件,Value代表相对应的值,一个Key可以对应一个 Value或者多个 Value。
    在埋点过程中,同种属性的多个事件要命名成一个埋点事件ID,并以Key-Value的形式区分。不同属性的多个事件应该命名成多个埋点事件ID,此时也尽量用Key- Value的形式埋点。
    例如我们上线了活动A和活动B两个活动,都在衣服专区和裤子专区的入口页面进行了Banner展现,想要知道这两个活动的用户访问情况,应该如何埋点呢?

    3.1埋点方案一:

    根据活动页面来源的不同与事件类型的不同,埋点事件分为4个,每个埋点事件代表一种情况。如下图:

     这种方法可以达到目的,但是随着活动投放的入口越来越多,每次增加一个入口,就需要不断增加事件ID,这样不但工作量会越来越大,而且维护成本和后期数据处理成本都很高。

     

    3.2埋点方案二:

    我们再来看看另外一种思路。使用Key字段表示以后业务分析时的维度,使用 Value字段表示在不同维度下对应的维度的唯一值,这样进行有组织的归纳,可以将不同维度下的不同参数有效地区分出来。通过Key-Value的形式,然后结合事件类型,最后形成埋点日志时的事件ID。即使以后增加更多的活动入口顶面,也只需要在当前 Key-value的基础上,在Key维度下Page对应的 Value中增加更多的值就可以了,这样会方便、灵活很多。在以后的数据分析应用中,这样就可以根据各维度(Key)下不同参数( Value)组成事件ID,高效地查找到相应事件的相关数据。

    如下图:

    这样,我就可以通过Page、 Source、 ActionType确定一个时间,例如点击了活动A页面的衣服专区入口按钮,就可以表示为 ActivityA_ Click_ClothesPrefectureButton,那么理点文档就可以简单梳理为下图所示的形式。通过梳理逻辑关系,把同属性的埋点事件用一个总事件ID表示,结合Key- Value细分不同维度下的不同参数,方便日后数据分析。解决了方案一的问题,不仅如此,还具备以下优点:
    (1)维护成本低,更加简单高效,新增时只需要在更新埋点文档时加一个Value参数即可。

    (2)易理解,减少沟通成本,提高其他业务人员、数据分析师根据埋点日志进行查询和分析的效率

    (3)扩展性好,对日后上线新活动或者业务的调整更灵活,可以在原有基础上扩展

    那么我只要选区不同的Page对应的Value值和和Source对应的Value值组合就可以得出统计情况。

     

    PS:其实这里和我们文章所说的 数据分析方法:演绎与归纳法 ,有异曲同工之妙。

    3.埋点数据的管理方式

  • 相关阅读:
    poj 2418 Hardwood Species
    hdu 3791 二叉搜索树
    九度oj 1544 数字序列区间最小值
    九度oj 1525 子串逆序打印
    九度oj 1530 最长不重复子串
    九度oj 1523 从上往下打印二叉树
    P1190 接水问题
    P1179 数字统计
    P1083 借教室
    P1079 Vigenère 密码
  • 原文地址:https://www.cnblogs.com/codewan/p/11389049.html
Copyright © 2011-2022 走看看