1.2.3.4 指标体系

优质
小牛编辑
135浏览
2023-12-01

本节将会对HubbleData的指标体系进行介绍,主要内容包括HubbleData的指标逻辑,计算依据等等。

1.1. 基本概念

对数据指标进行介绍前,我首先将会对HubbleData的基本概念进行说明

HubbleData的用户体系

HubbleData支持两类账号体系,分别是用户:userId以及设备:deviceUuid

  1. userId:由产品方可以调用SDK的loginUser接口上传,一般使用产品自身账号系统的数据。当用户没有上传或者上传比较滞后时,HubbleData会用deviceUuid代替。
  2. deviceUuid:SDK自动生成的Id,用以标志设备的唯一性。

需要说明是,设备跟用户一般是多对多的关系:

  1. 同一用户对应多个设备,主要场景包括:
    1. 同一个用户有多个设备,在这种情况下使用userId可以实现数据打通以及用户的跨设备分析。比较常见的例子为网站和App的数据打通
    2. 另一种情况为服务端与客户端同时使用HubbleData进行数据采集。当然这种情况比较特殊,因为理论上同一个行为只应该在一端进行采集。
  2. 同一设备对应多个用户,主要场景包括:
    1. 多个人共用一台设备,当然这种情况现在比较少见;
    2. 产品方调用SDK过晚,或者用户首次使用。典型场景如用户首次访问App,然后在某一步进入注册环节。用户在注册环节调用loginUser接口,此时注册之前的行为都属于匿名用户,造成同一设备有有两个用户(userId)。
HubbleData的时间体系:

HubbleData包含以下两个时间,分别对应不同使用场景:

  1. occurTime:事件触发的客户端时间
  2. serverTime:服务端接收到数据的时间

对于这两个时间需要说明的是:

  1. 客户端跟服务端时间一般情况下并不一致,具体情况依赖应用形态以及SDK的使用姿势:
    1. iOS/Android 默认情况下,在App回到后台时发送数据。SDK支持对数据发送策略进行调整以适用具体的业务场景,具体使用姿势请参考使用文档。具体来说,客户端与服务端时间不一致的情况包括:
      1. 用户使用过程中断网或者直接Kill掉应用,本次访问的数据需要等到用户下次打开App时才会上报。
      2. 用户更改本地客户端时间,我们在预处理阶段会对部分差距多大数据进行恢复。
    2. JS 目前SDK采用实时发送数据的方式,一般两个时间是一致的
    3. Sever 目前SDK采用实时发送数据的方式,一般两个事件是一致的
    4. miniProgram 默认采用实时发送数据的方式。用户可以在SDK中进行配置,具体使用姿势请参考使用文档。
HubbleData的事件体系

HubbleData的事件体系包括以下内容:

dataType='ie'   SDK内置采集的数据
dataType=‘pv'   PV事件
dataType='e'    自定义事件
dataType='auto' 自动跟踪事件
虚拟事件

以日活这一指标为例,对我们后续需要用到的事件进行解读:

  1. 用户每次访问都会有会话事件,所以我们在应用统计主要使用会话事件。包括da_session_start以及da_session_close。
  2. 会话事件仅仅反应用户打开App的行为,为了更加精准的描述用户,我们需要使用da_screen事件来对用户进行统计。
  3. 我们可以进一步缩小用户的范围,比方说产品方认为只有触发产品自己的埋点的用户才算做活跃,此时我们可以使用任意事件。定义:任意自定义事件,也即用户触发过任意一个自定义事件。任意事件不包含会话事件以及PV事件

1.2. 数据指标

HubbleData由于功能模块众多,在不同模块对应不同的使用场景,相应会有不同的算法规则。这种情况造成HubbleData不同模块的计算指标可能出现冲突,我们此处对不同模块的指标进行解读,并对可能出现的数据冲突进行说明。

总体上来看,HubbleData可以分为四个分析模块:

  1. 概览 包括网站统计以及移动应用统计
  2. 实时分析 包括实时分析以及实时看板
  3. 行为分析 包括事件,漏斗等等
  4. 用户分析 包括属性分析以及用户分群

接下来主要通过UV这个指标,对三个模块进行介绍:

  1. 概览 提供设备以及用户两个维度的指标

    1. 时间:概览中的指标使用客户端时间,主要使用离线计算,同时数据不会回溯。

      可能出现的数据差异:部分用户昨天的数据今天才会上报,此时用户不会计算到昨天。同时客户端时间为昨天时间,用户也不会计算到今天。此时数据并没有丢失,仅是概览模块不会计算,用户可以在分析模块进行查询

    2. 为了方便产品方对数据进行分析,概览提供两种类型的日活指标。

      1. 设备(deviceUuid)日活:计算当天打开App的用户,计算依据为:da_session_start``da_session_close``da_screen``任意事件
      2. 用户(userId)日活: 计算当天有使用过产品的用户,计算依据为:da_screen``任意事件

        可能出现的数据差异:数据指标采用不同事件依据,不同埋点姿势造成用户活跃与设备活跃数差异巨大。举例如,用户没有做任何埋点,并且未开启PV事件采集,此种情况下概览模块的用户数据为0

  2. 实时 实时模块主要提供用户维度的指标

    1. 时间:为了数据的一致性,以及计算的便利。实时模块使用的时间为服务端时间

      可能出现的数据差异:部分不是非常活跃的App,很大比例的用户数据会有延迟发送的情况,造成用户数据差异

    2. 实时模块仅提供用户日活(userId),主要事件依据为da_screen``任意事件
  3. 行为分析 行为分析模块仅提供用户维度的指标

    1. 时间:为了方便产品方更加方便还原用户行为,行为分析模块使用客户端时间。

      可能出现的数据异常:数据延迟发送

    2. 行为分析模块HubbleData仅提供用户(userId)维度的分析,没有提供设备维度的分析。如果用户需要在行为分析模块计算活跃用户数,可以使用任意事件触发用户数

      可能出现的数据异常1:事件计算依据跟其他模块不同造成数据异常,任意事件不包含会话事件以及PV事件

      可能出现的数据异常2:近似计算出现的数据异常,HubleData采用NDV近似计算,数据量越大,误差越小平均在0.2%以内