为减少不必要的篇幅，本文缩减了一些具体细节描述，在阅读本文前建议您首先阅读： 创建第一个数据指标、ICON图标点击数据统计 以及 移动支付订单数据统计，以便于您对XL-LightHouse的使用有初步了解。

XL-LightHouse的运算依赖业务方接入主动上报的原始统计消息，XL-LightHouse自身的功能不涉及相关埋点数据采集环节。

序言

电商已经彻底改变了现代零售业，而且它还在不断向前发展，不断满足人们日益变化的购买需求，也不断顺应着现代消费者的品味。本文选择几个电商类APP的常见业务场景为大家演示XL-LightHouse在该类业务中的使用。 文中的案例是根据主流的电商类APP（如淘宝、美团）的产品表象进行的主观猜测并进行了适当简化，旨在于阐述XL-LightHouse的适用场景和使用方式，其中的描述或许会与企业实际的业务现状有一定差异，请大家在使用时根据自己的实际情况灵活配置。

订单实时数据统计

电商业务是一个相对较重量级的业务，这个业务链条中包含了：用户、商户、平台、交易、支付、物流、评价、售后等N多个环节。为了维系一个电商平台的良好运转，相关的数据指标种类是非常繁多的。而其中订单是电商企业最核心的数据，电商企业都会有实时订单数据统计，比如常见的双十一大屏，而使用XL-LightHouse可以较为轻松的支撑这类业务场景。 针对订单的核心指标主要有订单量、交易额、平均订单金额、人均交易额、下单用户数等。因为订单和商品是一对多关系，为了实现上面几类指标，将这些数据需求拆分成两个统计组实现，此外对于较为复杂的业务，很多统计需求并不适合使用一个统计组实现，要结合自身业务以及XL-LightHouse的特性灵活的拆分成多个统计组实现。

订单维度数据统计

统计需求梳理

订单量：
1、每分钟_订单量
2、每小时_订单量
3、每天_订单量
4、每天_各省份_订单量
5、每天_各城市_订单量
6、每天_各年龄段人群_订单量
7、每天_各性别人群_订单量
8、每天_各APP版本_订单量
9、每天_各付款方式_订单量
10、每天_各价格区间_订单量
11、每天_各商户_订单量

交易金额：
1、每分钟_交易金额
2、每小时_交易金额
3、每天_交易金额
4、每天_各省份_交易金额
5、每天_各城市_交易金额
6、每天_各年龄段人群_交易金额
7、每天_各性别人群_交易金额
8、每天_各APP版本_交易金额
9、每天_各付款方式_交易金额
10、每天_各商户_交易金额

平均订单金额：
1、每小时_平均订单金额
2、每天_平均订单金额
3、每天_各省份_平均订单金额
4、每天_各城市_平均订单金额
5、每天_各年龄段人群_平均订单金额
6、每天_各性别人群_平均订单金额
7、每天_各商户_平均交易金额

人均消费金额：
1、每天_人均消费金额
2、每天_各省份_人均消费金额
3、每天_各性别人群_人均消费金额
4、每天_各年龄段人群_人均消费金额

下单用户数：
1、每分钟_下单用户数
2、每小时_下单用户数
3、每天_下单用户数
4、每天_各省份_下单用户数
5、每天_各城市_下单用户数
6、每天_各年龄段人群_下单用户数
7、每天_各性别人群_下单用户数
8、每天_各APP版本_下单用户数
9、每天_各付款方式_下单用户数
10、每天_各商户_下单用户数

元数据结构(订单维度)

字段	字段类型	说明
userId	string	用户ID
orderId	string	订单ID
supplierId	string	商户ID
age	string	用户年龄段
sex	string	用户性别
province	string	省份
city	string	城市
os	string	用户系统标识	android/ios
amount	numberic	订单支付金额
paymode	numberic	支付方式	信用卡、银行卡、微信支付、支付宝、白条...
version	string	app版本

订单商品维度数据统计

统计需求梳理

订单量：
1、每天_各商品_订单量
2、每天_各业务线_订单量
3、每天_各商品一级分类_订单量
4、每天_各商品二级分类_订单量
5、每天_各省份_各业务线_订单量
6、每天_各城市_各业务线_订单量

交易金额
1、每天_各商品_总交易金额
2、每天_各业务线_总交易金额
3、每天_各商品一级分类_总交易金额
4、每天_各商品二级分类_总交易金额

下单商品数：
1、每分钟_各业务线_下单商品数
2、每小时_各业务线_下单商品数
3、每天_各业务线_下单商品数

元数据结构（商品维度）

字段	字段类型	说明
orderId	string	订单ID
productId	string	商品ID
industry	string	所属业务	快消品、小家电、服装鞋帽、家电、医疗保健、母婴用品、3C数码、图书音像...
province	string	省份
city	string	城市
top_cate	string	商品一级分类
sec_cate	string	商品二级分类
price	numberic	付款金额

外卖订单异常率监控

对于外卖、打车、搬家、保洁、共享充电宝、单车等这一类的业务来说，有可能会因为各种原因出现某些区域的供需不平衡，反映到平台的表象可能是某些区域订单激增、超时订单增多、用户取消订单增多、用户等待时间过长、平台资源空耗等等情况，而数据化运营可以帮助企业更清晰、更及时的看到平台资源的分布状况和用户需求的分布状况是否匹配，从而更大化的发挥平台的资源调度能力。 不同的业务衡量资源的“供需关系”的数据指标不尽相同，而同一个业务也可能会用多种数据指标来综合衡量供需关系。 比如一个电商平台，如果“大码男装“的搜索量和成交量与”大码男装“商品供给量和商户数量的比例，如果远高于其他品类，则可以初步反映出在平台内”大码男装“是一个细分蓝海领域，平台就必要有针对性的引导商户资源向这个细分蓝海移动。 衡量平台资源的”供需关系“是一个相对复杂点的问题，需要对自身业务有足够清晰的了解，然后将业务问题转变成数学问题来处理，依据多个数据指标的交叉验证进行推断。

下面借助XL-LightHouse实时监控异常订单走势，为了阐述这个场景，在这里我将外卖订单状态划分成如下几种：

一级状态	状态描述	二级状态	状态描述
1	订单创建
2	订单支付
3	商户接单
4	骑手接单
5	配送中
6	订单完成	601	订单未超时
6	订单完成	602	配送超时
7	订单异常	701	用户未支付
7	订单异常	702	用户取消
7	订单异常	703	商户未接单
7	订单异常	704	无骑手接单
7	订单异常	705	骑手取货异常
7	订单异常	706	骑手配送异常

统计需求梳理

订单支付率：
1、每5分钟_订单支付率
2、每10分钟_订单支付率
3、每30分钟_订单支付率
4、每小时_订单支付率

无骑手接单率：
1、每10分钟_无骑手接单率
2、每30分钟_无骑手接单率
3、每小时_无骑手接单率
4、每10分钟_各城市_无骑手接单率
5、每10分钟_各商圈_无骑手接单率

商户拒单数量统计:
1、每天_商户拒单量
2、每天_各城市_商户拒单量
3、每天_各城市_各商圈_商户拒单量

订单异常率：
1、每10分钟_订单异常率
2、每30分钟_订单异常率
3、每小时_订单异常率
4、每小时_各城市_订单异常率
5、每小时_各城市_各商圈_订单异常率
6、每小时_各异常原因_订单异常率
7、每天_各异常原因_订单异常率

配送超时订单占比：
1、每10分钟_订单配送超时占比
2、每10分钟_各城市_各商圈_订单配送超时占比
3、每30分钟_订单配送超时占比
4、每小时_订单配送超时占比
5、每小时_订单配送超时占比
6、每小时_订单配送超时占比

元数据结构

字段	字段类型	说明
orderId	string	订单ID
city	string	城市
district	string	商圈
state1	string	一级订单状态
state2	string	二级订单状态

元数据上报时机：在每一次订单状态发生变化时上报对应的元数据消息。XL-LightHouse的每一条元数据消息都需要一个时间戳参数，内部的运算逻辑也完全基于这个时间戳来划分统计周期。在这种“状态变更”的业务场景中使用时，状态变更可能会横跨不同的统计周期，比如我们要计算“每小时_外卖异常订单数量”这个数据指标，订单创建消息可能是在10点，订单异常消息可能是在12点，这个时候如果您的业务期望这个值计算在订单创建的统计周期内，就传订单创建的时间戳。如果是期望计算在订单异常消息那个统计周期内，就传异常消息本身的时间戳。

物流配送数据统计

物流配送直接影响到电商APP的使用体验，是维系电商生态良性循环的主要环节，下面我们看下如何使用XL-LightHouse实时统计物流相关的指标，假如我们有如下数据需求：

统计需求梳理

包裹量统计：
1、每分钟_包裹量
2、每小时_包裹量
3、每天_包裹量
4、每天_各物流公司_包裹量
5、每天_各发货省份_包裹量
6、每天_各发货城市_包裹量
7、每天_各收货省份_包裹量
8、每天_各收货城市_包裹量
9、每天_各重量区间_包裹量
10、每天_各体积区间_包裹量
11、每天_各物流费用区间_包裹量
12、每天_各配送里程区间_包裹量
13、每天_各运输方式_包裹量
14、每天_各物流状态_包裹量
15、每天_各配送时长区间_包裹量

包裹配送时长：
1、每天_平均配送时长
2、每天_各重量区间包裹_平均配送时长
3、每天_各体积区间包裹_平均配送时长
4、每天_各运输方式_平均配送时长

总物流费用： 
1、每分钟_总物流费用
2、每天_各物流公司_物流费用
3、每天_各运输方式_物流费用

平均物流费用：
1、每天_平均物流费用
2、每天_各物流公司_平均物流费用
3、每天_各重量区间_平均物流费用
4、每天_各体积区间_平均物流费用
5、每天_各运输方式_平均物流费用

配送异常订单量：
1、每天_各物流公司_配送超时订单量
2、每天_各物流公司_配送异常订单量

元数据结构

字段	字段类型	说明
orderId	string	订单ID
pckId	string	物流包裹ID
deliveryId	string	物流公司ID
s_province	string	发货地_省份
s_city	string	发货地_城市
e_province	string	收货地_省份
e_city	string	收货地_城市
type	string	包裹重量体积类型	1：小型包裹，2：中型包裹，3：大型包裹，4：超大型包裹
transport_type	string	运输方式	0：公路，1：铁路+公路，2：航空+公路，3：水运+公路，4：其他
mileage	string	配送总里程
fee	string	物流费用
state	string	包裹最终状态	0：正常签收，1：无人签收超时退回，2：用户主动退回，4：包裹损坏退回，5：包裹丢失
outtimeflag	string	是否超时	0：正常，1：超时
cost	string	包裹总耗时

用户订单评价数据

这里的用户评价数据与一般电商APP上显示的用户打分数据略有不同，流式统计一般应用在较短的统计周期的场景内（XL-LightHouse默认最大统计周期是一天）。而电商APP上显示的用户评价打分是基于较长的时间周期计算的。这两种数据各有用途，第一类数据是面向企业内部人员进行产品或服务迭代使用，第二类数据是面向C端用户作为衡量商户服务、商品质量的标准使用。 用户评价直接反映用户对电商交易的满意状况，以淘宝为例，它的订单评价分为三个部分：商品质量评分、商户服务评分、物流配送评分。针对于这个场景我们来看下如何使用XL-LightHouse实时监控各项指标。由于这三种评分侧重不同的方面，相关维度有些不同，所以在这里分成三个统计组来实现。假如我们有如下数据需求：

统计需求梳理

用户主动评价次数：
1、每分钟_主动评价次数
2、每小时_主动评价次数
3、每天_主动评价次数
4、每天_各行业_主动评价次数
5、每天_各app版本_主动评价次数
6、每天_各一级分类_主动评价次数
6、每天_各二级分类_主动评价次数
6、每天_各三级分类_主动评价次数
6、每天_各评分区间_主动评价次数

商品质量平均评分：
1、每天_平均评分
2、每天_各行业_平均评分
3、每天_各一级分类_平均评分
4、每天_各二级分类_平均评分
5、每天_各商户_平均评分
6、每天_各商品_平均评分

元数据结构（商品质量评分）

字段	字段类型	说明
orderId	string	订单ID
userId	string	用户ID
industry	string	所属行业	快消品、服装鞋帽、家电、医疗保健、母婴用品、3C数码、图书音像等
isVirtual	string	是否为虚拟商品	0:实物商品,1:虚拟商品
top_cate	string	商品一级分类
sec_cate	string	商品二级分类
thd_cate	string	商品三级分类
supplierId	string	商户ID
productId	string	商品ID
score	string	商品质量评分

元数据结构（商户服务评分）

| 字段 | 字段类型 | 说明 | --- | --- | --- | --- | | orderId | string | 订单ID | | | userId | string | 用户ID | | | industry | string | 所属行业 | 快消品、服装鞋帽、家电、医疗保健、母婴用品、3C数码、图书音像等 | | supplierId | string | 商户ID | | | productId | string | 商品ID | | | score | string | 商户服务评分 | |

元数据结构（物流服务评分）

字段	字段类型	说明
orderId	string	订单ID
userId	string	用户ID
industry	string	所属行业	快消品、服装鞋帽、家电、医疗保健、母婴用品、3C数码、图书音像等
supplierId	string	商户ID
productId	string	商品ID
score	string	商户服务评分

品牌热度监控

优质品牌对于电商平台来说意义重大，即时掌握各品类商品优质品牌的“供给和需求状况”对于电商平台来说有很大的业务价值。用户对品牌的"关注热度"可以从很多方面体现出来，比如用户主动搜索品牌相关词、在列表页使用品牌条件过滤商品、点击品牌下的商品、购买品牌商品等等。如果现在我们要实时监控不同性别和不同年龄段的人群对于各个品牌的偏好变化，假如有如下数据需求：

统计需求梳理

品牌总热度趋势
1、每天_各行业_各品牌_热度评分
2、每天_各年龄段人群_各行业_各品牌_热度评分
3、每天_各性别人群_各行业_各品牌_热度评分

品牌搜索热度趋势
1、每天_各行业_各品牌_搜索热度
2、每天_各年龄段人群_各行业_各品牌_搜索热度
3、每天_各性别人群_各行业_各品牌_搜索热度

品牌购买热度趋势
1、每天_各行业_各品牌_购买热度趋势
2、每天_各年龄段人群_各行业_各品牌_购买热度趋势
3、每天_各性别人群_各行业_各品牌_购买热度趋势

元数据结构

字段	字段类型	说明
industry	string	行业	3C数码、家电、小家电、母婴、男装、女装...
userId	string	用户ID
age	string	用户年龄段
sex	string	用户性别
brand	string	品牌
msgType	string	消息类型	1：品牌词搜索，2：品牌词筛选，3：品牌商品点击，4：品牌商品购买
score	string	打分

竞价排名广告点击收入监控

站内广告是电商平台营收的主要来源之一，电商APP的站内广告以多种形式遍布于APP内的各个角落，比如APP启动页广告、 首页的展示位、列表的竞价排名等等。为了便于实时掌握各个广告位的展示情况、点击效果和收益状况，下面我们以列表页竞价排名广告的业务场景为例阐述一下在这个场景中XL-LightHouse的使用。列表页的竞价广告一般使用CPC(按点击付费)或CPM(按展示付费)两种类型之一。假如我们有如下数据需求：

统计需求梳理

广告收益：
1、每分钟_广告收益
2、每天_各付费类型_广告收益
3、每天_各广告主_广告费用(Top100)
4、每天_各省份_广告费用
5、每天_各城市_广告费用
6、每天_各APP版本_广告费用
7、每天_各手机系统_广告费用
8、每天_各行业_广告费用
9、每天_各一级分类_广告费用
10、每天_各二级分类_广告费用

广告曝光量：
1、每分钟_广告曝光量
2、每天_各付费类型_广告曝光量
3、每天_各广告主_广告曝光量
4、每天_各省份_广告曝光量
5、每天_各城市_广告曝光量
6、每天_各APP版本_广告曝光量
7、每天_各手机系统_广告曝光量
8、每天_各行业_广告曝光量
9、每天_各一级分类_广告曝光量
10、每天_各二级分类_广告曝光量

广告点击量：
1、每分钟_广告点击量
2、每天_各付费类型_广告点击量
3、每天_各广告主_广告点击量
4、每天_各省份_广告点击量
5、每天_各城市_广告点击量
6、每天_各APP版本_广告点击量
7、每天_各手机系统_广告点击量
8、每天_各行业_广告点击量
9、每天_各一级分类_广告点击量
10、每天_各二级分类_广告点击量

广告点击率：
1、每分钟_广告点击率
2、每天_各付费类型_广告点击率
3、每天_各广告主_广告点击率
4、每天_各省份_广告点击率
5、每天_各城市_广告点击率
6、每天_各APP版本_广告点击率
7、每天_各手机系统_广告点击率
8、每天_各行业_广告点击率
9、每天_各一级分类_广告点击率
10、每天_各二级分类_广告点击率

元数据结构

字段	字段类型	说明
advertisers	string	广告主ID
skuId	string	广告商品ID
industry	string	行业
top_cate	string	一级分类
sec_cate	string	二级分类
province	numberic	用户所在省份
city	numberic	用户所在城市
action	numberic	1：广告展示、2：广告点击
cost	numberic	广告费用
type	numberic	付费类型	1：CPC，2：CPM
os	numberic	用户操作系统	android、ios
version	numberic	app版本

交易佣金收入监控

对于电商平台来说除了各种形式的广告收入之外，每笔订单的交易佣金也是其主要收入来源。我们可以使用XL-LightHouse实时监控交易佣金的走势情况。假如我们有如下数据需求：

统计需求梳理

交易佣金：
1、每分钟_总佣金
2、每小时_总佣金
3、每天_总佣金
4、每天_各行业_总佣金
5、每天_各店铺_总佣金(Top100)

平均交易佣金：
1、每分钟_平均交易佣金
2、每小时_平均交易佣金
3、每天_平均交易佣金
4、每天_各行业_平均交易佣金

佣金比例：
1、每分钟_平均佣金比例
2、每小时_平均佣金比例
3、每天_各行业_平均佣金比例

收佣店铺数量：
1、每天_收佣店铺数量
2、每天_各行业_收佣店铺数量

元数据结构

字段	字段类型	说明
orderId	string	订单ID
industry	string	行业
storeId	string	店铺ID
amount	string	订单总价格
commission	string	佣金金额
rate	string	收佣比例

业务ICON点击数据统计

上文描述的场景主要是针对于一些业务类数据指标、运营类数据指标的统计，而其实在互联网行业产品类数据指标可能才是统计需求最繁多的种类。 一个APP是由很多个页面组成，每个页面又有很多个大大小小的产品模块组成。这些产品模块互相组合嵌套，其范围既可以大到商品列表页和商品详情页这类用户主要的活动区域，也可以小到App首页的一个推荐位，一个搜索框，一个弹窗广告甚至是一个按钮。XL-LightHouse适用于应对这种繁杂的数据需求。 下面举一个产品类指标的例子。 很多APP都会有这种业务icon的展示区域，它是各业务线主要的流量入口。假如针对这个产品模块我们有如下数据需求：

统计需求梳理

点击量：
1、每10分钟_总点击量
2、每10分钟_各ICON_点击量
4、每天_总点击量
5、每天_各ICON_点击量
6、每天_各省份_各ICON_点击量
7、每天_各城市_各ICON_点击量

点击用户量
1、每10分钟_点击用户量
2、每10分钟_各ICON_点击用户量
4、每天_点击用户量
5、每天_各ICON_点击用户量
6、每天_各城市_各ICON_点击用户量

元数据结构

字段	字段类型	说明
userId	string	用户id
iconId	string	业务iconID	比如：1：外卖，2：美事，3：酒店/民宿...
eventType	string	行为类型	1：曝光、2:点击

直播电商停留时长数据统计

直播电商是最近几年较为新颖的购物方式，它可以带给买家更直观的购物体验，有利于买卖双方的互动，建立信任感，从而促成交易。 直播电商相关的数据统计也是非常多的，除了基本的订单数据、加购数据之外还会有买家沟通互动的数据、店铺关注数据、用户停留时长数据等等。 现在我们以该场景为例，看下如何使用XL-LightHouse统计用户在直播间停留时长数据。

统计需求梳理

停留时长：
1、每小时_用户平均停留时长
2、每小时_各行业_用户平均停留时长
3、每小时_各省份_用户平均停留时长
4、每小时_各城市_用户平均停留时长
5、每小时_各店铺_用户平均停留时长
6、每小时_各店铺_各主播_用户平均停留时长
7、每天_用户平均停留时长
8、每天_各行业_用户平均停留时长
9、每天_各省份_用户平均停留时长
10、每天_各城市_用户平均停留时长
11、每天_各店铺_用户平均停留时长
12、每天_各店铺_各主播_用户平均停留时长

元数据结构

字段	字段类型	说明
userId	string	用户id
province	string	省份
city	string	城市
biz	string	行业
shopId	string	店铺Id
anchorId	string	主播Id
staytime	numberic	停留时长

上报时机：通过记录用户每次点击进入直播间的时间戳，在用户退出直播间时上报用户的停留时长消息。