智能分析
  • 文档导引
  • 产品使用文档
  • 基础概念解释
    • 事件
    • 属性
    • 指标
    • 用户与用户群
    • 筛选条件
    • 分析维度
    • 时间范围
    • 时间聚合度
  • 分析模块
    • 事件分析
    • 留存分析
    • 间隔分析
    • 分布分析
    • 归因分析
    • 漏斗分析
    • 路径分析
    • 用户分析
    • Session分析
  • 用户分群
  • 管理
    • 元事件管理
    • 事件属性与用户属性
    • Session管理
    • 虚拟事件
  • 书签管理
  • 成员与权限
  • 监控预警
  • 项目管理
  • 基础设置
  • 看板&看板组
  • 技术指南
    • 基础知识
      • 数据格式
      • 数据模型
      • 用户的标识与关联
      • 如何标识新用户
      • 预置事件与预置属性
        • 客户端SDK预置
          • App SDK
          • Web JS SDK
          • 微信小程序
  • SDK使用
    • 客户端SDK
      • Android SDK
      • iOS SDK
      • 小程序SDK
      • Web JS SDK
    • 服务端SDK
      • Java SDK
由 GitBook 提供支持
在本页
  • Event实体对于分析模块的支撑
  • 订单量
  • 支付用户数
  • 销售额&客单价
  • 支付时间分布
  • User实体对于分析模块的支撑
  • 注册时触发
  • 登录时触发
  • 新老用户
  • VIP体系
  • 用户价值特征

这有帮助吗?

  1. 技术指南
  2. 基础知识

数据模型

智能分析平台的所有功能,全部依赖于底层的数据模型实现,即Event实体+User实体为基础,Item实体作为辅助的基本模型,下面将从实际应用中解释实现逻辑。

Event实体与User实体在数据上体现为数据层面的Event表与User表,二者通过唯一ID互联互通,构成了数据分析工作台的数据基础。

Event实体对于分析模块的支撑

以一个很常见的简单场景举例,在电商运营中,销售数据是很重要的数据,我们把销售数据细化为独立的数据指标,可以包含销售额,订单量,品类分布,成交时间分布等等多个指标。

以细化指标为切入点,如果我们想要了解这些指标的数据,那么就需要监测用户的支付订单行为,我们可以把支付订单设计为一个事件进行数据采集,接下来我们看这个事件能为我们携带什么样的属性:

订单金额:该笔订单的金额,该属性可以实现对销售额的监测

商品品类:该比订单中包含的商品品类,该属性可以实现对品类分布的监测

商品名称:该比订单中包含的商品名称,该属性可以实现细化到单品的销售数据监测

事件触发时间:支付订单事件触发的时间点,该属性可以实现对成交时间分布的监测

事件量:支付订单事件的条数,可以实现对于订单量的监测

事件触发用户数:触发支付订单的用户数,该属性可以实现对于客单价的监测

梳理清楚这些,我们就有了这样的事件数据:

{
    "distinct_id":"",
    "time":"",
    "type":"",
    "event":"payment",
    "project":"",
    "properties":{
        "price":,
        "item_classify":"",
        "item_name":"",
    }
}

随着用户对于支付订单事件的触发,支付订单事件的数据将不断的由设备上报至工作台并存入Event表中,接下来,我们来看Event表中的数据是如何支撑各个分析模块的。

订单量

订单量,即订单的总量,从业务上来讲,同一个用户支付两个订单,订单量会被计为2,那么对于订单量的统计,即可等同于对支付订单事件条数的统计。

也就是说,在事件分析模块中配置支付订单-总次数这个查询条件时,工作台会检索Event表中选定时间范围内的payment事件条数,并给出结果。

支付用户数

这个指标要依赖于distinct_id字段来实现,该字段是用户的唯一标识,两条订单数据如果distinct_id字段值相同,则证明这两笔订单来自于同一个用户。

如果在事件分析模块中配置支付订单-用户数这个查询条件时,工作台会计算Event表中选定时间范围内所有payment事件携带的distinct_id的去重数。

销售额&客单价

订单金额,即数据样例中的price字段,该字段记录了此订单的订单金额,我们把它设计为number类型,因此,我们可以计算订单金额的总和,最大值,最小值等多个指标。

实现对于订单额数据的监测,也就是在事件分析模块中配置支付订单-订单金额-总和这个查询条件,执行查询后,工作台会计算Event表中选定时间范围内所有payment事件携带的price字段值的总和。

同理,我们可以配置支付订单-订单金额-人均值这个查询条件,执行查询后,工作台会计算Event表中选定时间范围内所有payment事件携带的price字段的人均值。

支付时间分布

我们注意到,数据样例中携带了一个time字段,表示此事件被触发时的时间点,那么我们可以进入分布分析模块,配置支付订单-触发时间-默认区间这个查询条件,执行查询后,工作台会以小时为区间划分标准,计算每个时间区间内的订单量,给出的结果也就是支付时间分布。

可见,Event实体是分析模块实现功能的基础,但是只有Event实体对于数据分析来说开始有些薄弱,为此,我们引入了User实体作为Event实体的组合支撑。

User实体对于分析模块的支撑

还是以电商运营环境为例,新老用户的表现如何?VIP体系是否能提升用户的消费频率?复购率较高的用户或消费水平较高的用户有什么样的特征?

以这三个问题切入,想要划分新老用户,我们需要知道用户的注册时间,想要分析不同VIP等级与用户消费频率的关系,我们需要知道用户的VIP等级,想要知道高价值用户的特征,我们需要将这部分用户单独提取出来。

于是我们可以在用户注册以及登录之后,使用profile_*接口,向User表中写入注册时间以及VIP等级,数据样例如下:

注册时触发

{
    "distinct_id":"",
    "type":"profile_set_once",
    "time":"",
    "project":"",
    "properties":{
    	"sign_up_time":"",
}
}

登录时触发

{
	"distinct_id":"",
	"type":"profile_set",
	"time":"",
	"project":"",
	"properties":{
		"vip_level":,
		"nick_name":"",
	}
}

随着数据的不断上报,User实体也就组建完成并逐渐丰富起来,借助User实体,我们可以解决之前的问题。

新老用户

划分新老用户,我们可以进入用户分群模块,配置如下:

分群名称

划分标准

配置条件

新客客群

用户属性

注册时间-相对当前时间点-30天-之内

老客客群

用户属性

注册时间-相对当前时间点-30天-之前

我们可以得到两个用户群组,再回到事件分析模块中,将分析用户群选定为新客客群与老客客群,这样就可以横向对比新老客群的订单量,销售额,品类分布等数据指标。

VIP体系

同理,我们可以根据VIP等级将用户划分为不同的分群,横向对比不同VIP等级用户的消费数据。

用户价值特征

对于用户价值特征的分析,我们可以配置这样的分群条件:

分群名称

划分标准

配置条件

低价值用户

触发事件

上线至今-做过-支付订单事件-总次数-[0,5]次

中价值用户

触发事件

上线至今-做过-支付订单事件-总次数-[6,20]次

高价值用户

触发事件

上线至今-做过-支付订单事件-总次数-[21,+∞]次

分群创建完成后,可以通过用户分析模块详细分析不同价值用户群体之间的特征差异。

上一页数据格式下一页用户的标识与关联

最后更新于4年前

这有帮助吗?