资讯类场景使用演示
为了减少不必要的篇幅，本文缩减了一些具体细节描述，在阅读本文前建议您首先阅读： 创建第一个数据指标、ICON图标点击数据统计 以及 移动支付订单数据统计，以便于您对XL-LightHouse的使用有初步了解。
XL-LightHouse的运算依赖业务方接入主动上报的原始统计消息，XL-LightHouse自身的功能不涉及相关埋点数据采集环节。
前言
在移动互联网时代新闻资讯类APP很大程度上填补了用户的碎片化时间，满足了人们对资讯的需求，是广大用户获取信息的主要途径。 本文选择几个资讯类APP常见业务场景为大家演示XL-LightHouse在该类业务中的使用。文中的案例是根据主流的资讯类APP（如腾讯新闻、抖音、微博等）的产品表象进行的主观猜测并进行了适当简化，旨在于阐述XL-LightHouse的适用场景和使用方式，其中的描述或许会与企业实际的业务现状有一定差异，请在使用时根据自己的实际情况灵活配置。
Feed列表用户行为数据统计
资讯类业务一般以Feed信息流的形态呈现，如上图所示，它包含多个Tab栏，比如：要闻、视频、推荐、国际、财经等等，每个Tab栏下都对应一个信息流列表，这种列表的数据是由个性化推荐系统基于多种召回策略产生。这类Feed列表要统计的用户行为方面的指标一般主要有曝光量、点击量、曝光UV、点击UV、点击率、帖子下发量、用户请求次数等。并且每个指标都可以结合不同的维度（比如：时间周期、用户行为类型、地区、帖子类型、召回策略、app版本等）进行更细粒度的数据统计。假如针对这类Feed业务场景我们有如下数据需求：
统计需求梳理
各行为类型PV：
1、每分钟_各行为类型_PV
2、每小时_各行为类型_PV
3、每天_各行为类型_PV
4、每天_各省份_各行为类型_PV
5、每天_各城市_各行为类型_PV
6、每天_各Tab栏_各行为类型_PV
7、每天_各手机系统_各行为类型_PV
8、每天_各一级分类_各行为类型_PV
9、每天_各二级分类_各行为类型_PV
10、每天_各帖子来源_各行为类型_PV
11、每天_各召回模型_各行为类型_PV
12、每天_各APP版本_各行为类型_PV
各行为类型UV：
1、每分钟_各行为类型_UV
2、每小时_各行为类型_UV
3、每天_各行为类型_UV
4、每天_各省份_各行为类型_UV
5、每天_各城市_各行为类型_UV
6、每天_各Tab栏_各行为类型_UV
7、每天_各手机系统_各行为类型_UV
8、每天_各一级分类_各行为类型_UV
9、每天_各二级分类_各行为类型_UV
10、每天_各帖子来源_各行为类型_UV
11、每天_各召回模型_各行为类型_UV
12、每天_各APP版本_各行为类型_UV
点击率(CTR)：
1、每分钟_CTR
2、每小时_CTR
3、每天_CTR
4、每天_各Tab栏_CTR
5、每天_各一级分类_CTR
6、每天_各二级分类_CTR
7、每天_各帖子来源_CTR
8、每天_各召回模型_CTR
帖子下发量：
1、每分钟_帖子下发量
2、每小时_帖子下发量
3、每天_帖子下发量
4、每天_各省份_帖子下发量
5、每天_各城市_帖子下发量
6、每天_各Tab栏_帖子下发量
7、每天_各手机系统_帖子下发量
8、每天_各一级分类_帖子下发量
9、每天_各二级分类_帖子下发量
10、每天_各帖子来源_帖子下发量
11、每天_各召回模型_帖子下发量
12、每天_各APP版本_帖子下发量
用户请求次数：
1、每分钟_请求次数
2、每小时_请求次数
3、每天_请求次数
4、每天_各Tab栏_请求次数
5、每天_各手机系统_请求次数
6、每天_各APP版本_请求次数
元数据结构
| 字段 | 类型 | 描述 | 说明 | |
|---|---|---|---|---|
| request_id | string | 用户请求标识 | 用户每次上划或下划刷新请求的唯一标识 | |
| imei | string | 用户标识 | ||
| action_type | string | 用户行为类型 | 曝光、点击 | |
| province | string | 用户所在省份 | ||
| city | string | 用户所在城市 | ||
| tab | string | Tab栏 | 推荐、要闻、体育、财经、娱乐等 | |
| item_id | string | 帖子ID | ||
| item_type | string | 帖子类型 | 1：图文，2：长视频，3：短视频 | |
| source | string | 帖子来源 | 1、平台自产，2、平台创作者发布、3、爬虫爬取 | |
| top_level | string | 帖子一级分类 | ||
| sec_level | string | 帖子二级分类 | ||
| recallno | string | 召回模型标识 | ||
| os | string | 用户手机系统 | android、ios | |
| version | string | APP版本 |
触发时机：当用户上拉或下拉刷新时，每一个帖子曝光或被点击都上报一条包括上面参数的原始消息。
新闻热点推送场景数据统计
我们每天都会收到很多APP的消息推送，比如APP系统通知、新闻热点、促销活动、聊天消息、天气预警等等。Push推送是移动互联网非常常见也比较重要的业务场景，它是吸引用户注意力、提升用户粘度成本低廉、行之有效的手段。不同业务类型的APP推送的消息有较大差异，同一个APP内也可能会包含多种类型的消息推送。这类业务场景要统计的指标一般有推送量、推送帖子量、到达量、点击量、到达率、点击率等。下面以个性化新闻热点推送为例描述一下XL-LightHouse在该类业务中的使用。这种与客户端交互较为密切的指标，需要首先梳理业务所关注指标有哪些、根据指标在APP添加埋点、然后在XL-LightHouse中创建相应的统计组和统计项并接入业务数据。 假如我们有如下数据需求：
统计需求梳理
推送量：
1、每分钟_推送量
2、每小时_推送量
3、每天_推送量
4、每天_各批次_推送量
5、每天_各手机系统_推送量
6、每天_各APP版本_推送量
7、每天_各省份_到达量
8、每天_各城市_到达量
9、每天_各手机品牌_推送量
推送帖子量：
1、每分钟_推送帖子量
2、每小时_推送帖子量
3、每天_推送帖子量
4、每天_各批次_推送帖子量
到达量：
1、每分钟_到达量
2、每小时_到达量
3、每天_到达量
4、每天_各批次_到达量
5、每天_各手机系统_到达量
6、每天_各APP版本_到达量
7、每天_各省份_到达量
8、每天_各城市_到达量
9、每天_各手机品牌_到达量
到达率：
1、每小时_到达率
2、每天_到达率
3、每天_各批次_到达率
4、每天_各手机系统_到达率
5、每天_各APP版本_到达率
6、每天_各省份_到达率
7、每天_各城市_到达率
8、每天_各手机品牌_到达率
点击量：
1、每分钟_到达量
2、每小时_到达量
3、每天_到达量
4、每天_各批次_到达量
5、每天_各手机系统_到达量
6、每天_各APP版本_到达量
7、每天_各省份_到达量
8、每天_各城市_到达量
9、每天_各手机品牌_到达量
点击率：
1、每小时_点击率
2、每天_点击率
3、每天_各批次_点击率
到达用户占比：
1、每天_到达用户占比
2、每天_各批次_到达用户占比
3、每天_各手机系统_到达用户占比
4、每天_各手机品牌_到达用户占比
点击用户占比：
1、每天_点击用户占比
2、每天_各批次_点击用户占比
元数据结构
| 字段 | 字段类型 | 描述 | |
|---|---|---|---|
| imei | string | 用户标识 | |
| itemId | string | 帖子ID | |
| eventType | string | 事件类型 | 1:消息推送，2：消息到达，3：消息点击 |
| province | string | 省份 | |
| city | string | 城市 | |
| os | string | 用户手机系统 | android、ios |
| recallno | string | 召回策略标识 | |
| batch | string | 推送批次 | |
| brand | string | 用户手机品牌 | |
| version | string | APP版本 |
内容源用户发布数据监控
内容源是资讯类平台的根本，资讯平台内容来源渠道可以有很多种，比如：平台自产内容、专业媒体发布、自媒体发布、爬虫抓取等。资讯平台需要监控各内容源的发布数量，这有助于平台及时掌握各内容源数量波动情况，维持内容平台的正常运转。下面我们使用XL-LightHouse实时监控各内容源的发布数据。假如这个场景我们有如下数据需求：
统计需求梳理
发帖量：
1、每10分钟_总发帖量
2、每小时_总发帖量
3、每天_总发帖量
4、每天_各数据来源_发帖量
5、每天_各帖子类型_发帖量
6、每天_各内容一级分类_发帖量
7、每天_各内容二级分类_发帖量
元数据结构
| 字段 | 字段类型 | 描述 | |
|---|---|---|---|
| itemId | string | 帖子ID | |
| source | string | 数据来源 | 1、平台自产，2、平台入驻媒体发布、3、自媒体、4、爬虫爬取 |
| item_type | string | 帖子类型 | 1：图文，2：短视频，3：长视频 |
| top_cate | string | 内容一级分类 | |
| sec_cate | string | 内容二级分类 |
内容审核数据监控
对于内容源的发布数据监控，很多时候上面的数据指标不能满足企业实际需要。企业往往需要更多细粒度的数据指标来进行更全面的监控。 比如内容平台的帖子在发布后都会经过审核环节，审核可以为系统审核或人工审核。
统计需求梳理
审核数量：
1、每天_各审核人员_审核数量
2、每天_各审核状态_发帖数量
3、每天_各数据来源_各审核状态数量
4、每天_各一级分类_各审核状态数量
5、每天_各二级分类_各审核状态数量
6、每天_各帖子类型_各审核状态数量
7、每天_各审核不通过原因数量
8、每天_各发帖账号_各审核状态数量
审核通过率：
1、每天_审核通过率
2、每天_各数据来源_审核通过率
3、每天_各一级分类_审核通过率
4、每天_各二级分类_审核通过率
5、每天_各帖子类型_审核通过率
元数据结构
| 字段 | 字段类型 | 描述 | |
|---|---|---|---|
| itemId | string | 帖子ID | |
| source | string | 数据来源 | 1、平台自产，2、平台入驻媒体发布、3、自媒体、4、普通用户、5、爬虫爬取 |
| item_type | string | 帖子类型 | 1：图文，2：短视频，3：长视频 |
| top_cate | string | 内容一级分类 | |
| sec_cate | string | 内容二级分类 | |
| accountId | string | 发帖账号ID | |
| reviewerId | string | 内容审核员ID | |
| type | string | 审核方式 | 0：无需审核，1：人审，2：机审 |
| status | string | 审核状态 | 0：审核通过，1：审核不通过 |
| invalid_type | string | 审核不通过原因 | 0：通过，1：广告，2：违法信息，3：涉政信息，4：低俗信息，5：虚假信息，6：其他敏感信息 |
爬虫爬取数据源监控
通过爬虫从外部爬取帖子是很多内容平台补充自身内容源的重要手段，但是因为爬虫程序很有可能会因为对方服务的升级、改版而导致爬取异常，从而影响到内容供给量。这种情况就有必要针对各主要爬取内容源进行数据监控，以便即时发现问题。假如在这个场景下我们有如下数据需求：
统计需求梳理
爬取内容源监控：
1、每小时_各内容源_爬取帖子量
2、每天_各内容源_爬取帖子量
元数据结构
| 字段 | 字段类型 | 描述 | |
|---|---|---|---|
| itemId | string | 帖子ID | |
| source | string | 爬取源 | 比如:微博热搜、腾讯新闻的本地热点、人民网置顶消息、头条新闻热榜、微博热议话题 |
兜底请求数据监控
在帖子数据不足或者系统服务有问题时，内容资讯类平台一般会给用户返回一些兜底数据，来避免列表为空的情况，降低对用户体验的影响。所以很多时候兜底请求的监控对于衡量内容供给丰富度或者系统服务质量有一定的参考价值，下面我们看下如何使用XL-LightHouse监控兜底请求出现的次数和发生的概率。用户在Feed列表每一次上滑或下滑都是一次接口请求，这里为每次接口请求定义三种返回状态：正常返回数据、返回兜底数据、返回空数据。假设我们有如下数据需求：
统计需求梳理
请求次数:
1、每分钟_各状态_请求次数
2、每小时_各状态_请求次数
3、每天_各状态_请求次数
4、每天_各Tab栏_各状态_请求次数
异常请求占比：
1、每分钟_异常请求占比
1、每小时_异常请求占比
2、每天_异常请求占比
3、每天_各Tab栏_异常请求占比
元数据结构
| 字段 | 字段类型 | 描述 | |
|---|---|---|---|
| imei | string | 用户标识 | |
| request_id | string | 用户请求标识 | |
| state | string | 1:正常返回数据，2：返回兜底数据，3：返回空数据 | |
| tab | string | Tab栏 | |
| province | string | 省份 | |
| city | string | 城市 | |
| os | string | 用户手机系统 | android、ios |
| version | string | APP版本 |
负反馈数据监控
很多资讯类APP在列表每个帖子下都有一个负反馈按钮，这个功能可以让用户自己屏蔽不敢兴趣的内容或内容创作者，同时也是一个用户举报低俗、违法等信息的入口。下面我们使用XL-LightHouse来实时监控用户的负反馈相关统计数据。假如我们有如下数据需求：
统计需求梳理
负反馈次数：
1、每分钟_负反馈次数
2、每天_负反馈次数
3、每天_各类型_负反馈次数
4、每天_各帖子类型_负反馈次数
5、每天_各帖子来源_负反馈次数
6、每天_各召回策略_负反馈次数
7、每天_各Tab栏_负反馈次数
8、每天_各帖子一级分类_负反馈次数
9、每天_各帖子二级分类_负反馈次数
负反馈人数：
1、每分钟_负反馈人数
2、每天_负反馈人数
3、每天_各帖子类型_负反馈人数
4、每天_各召回策略_负反馈人数
5、每天_各类型_负反馈人数
7、每天_被举报发布违法信息的创作者Top100
8、每天_被举报发布低俗信息的创作者Top100
元数据结构
| 字段 | 字段类型 | 描述 | |
|---|---|---|---|
| imei | string | 用户设备标识 | |
| itemId | string | 帖子ID | |
| author | string | 内容创作者 | |
| item_type | string | 帖子类型 | 1：图文，2：视频 |
| source | string | 帖子来源 | 1、平台自产，2、平台入驻媒体发布、3、自媒体、4、普通用户发布、5、爬虫爬取 |
| top_cate | string | 帖子一级分类 | |
| sec_cate | string | 帖子二级分类 | |
| feedback | string | 负反馈类型（不感兴趣、内容过时、低俗信息、虚假信息、标题党、违法信息） | |
| recallno | string | 召回策略标识 |
用户互动类数据监控
互动数据是指用户在app内点击、点赞、踩、搜藏、关注、评论、分享等行为数据，互动数据是衡量APP用户活跃程度的重要指标之一。实时监控用户互动类数据对于APP运营有非常重要的意义。下面我们使用XL-LightHouse来实时统计用户互动类相关的数据指标。假如我们有如下数据需求：
统计需求梳理
互动次数：
1、每分钟_各类型_互动次数
2、每天_各类型_互动次数
3、每天_各手机系统_各类型_互动次数
4、每天_各内容创作者_各类型_互动次数
5、每天_各内容一级分类_各类型_互动次数
6、每天_各内容二级分类_各类型_互动次数
7、每天_各版本_各类型_互动次数
互动人数：
1、每分钟_各类型_互动人数
2、每天_各类型_互动人数
3、每天_各手机系统_各类型_互动人数
4、每天_各内容创作者_各类型_互动人数
5、每天_各内容一级分类_各类型_互动人数
6、每天_各内容二级分类_各类型_互动人数
7、每天_各版本_各类型_互动人数
元数据结构
| 字段 | 字段类型 | 描述 | |
|---|---|---|---|
| imei | string | 用户标识 | |
| behaviorType | string | 互动行为类型 | 点击、点赞、踩、搜藏、关注、评论、分享 |
| author | string | 内容创作者 | |
| top_cate | string | 内容一级分类 | |
| sec_cate | string | 内容二级分类 | |
| os | string | 用户手机系统 | android、ios |
| version | string | APP版本 |
Feed列表内广告位数据统计
在现代社会广告以文字、图片、视频、弹窗、软文等各种形式遍布于各类互联网产品，是各个互联网企业的重要收入来源甚至是唯一收入来源。广告是否正常显示以及广告的曝光量、点击量、点击率、转化率与互联网企业的收益息息相关。下面我们以腾讯新闻的这种Feed列表的内嵌广告为例，阐述一下如何使用XL-LightHouse进行相关数据的统计。 Feed列表的广告往往是CPM(按曝光付费)或CPC(按点击付费)的形式，按假如我们有如下数据需求：
统计需求梳理
广告曝光PV：
1、每分钟_广告位总曝光量
2、每小时_广告位总曝光量
3、每天_广告位总曝光量
4、每天_各行业广告_广告曝光量
5、每天_各广告主_广告曝光量
6、每天_各Tab栏_广告曝光量
7、每天_各手机系统_广告曝光量
8、每天_各APP版本_广告曝光量
广告点击PV：
1、每分钟_广告位总点击量
2、每小时_广告位总点击量
3、每天_广告位总点击量
4、每天_各行业广告_广告点击量
5、每天_各广告主_广告点击量
6、每天_各Tab栏_广告点击量
7、每天_各手机系统_广告点击量
8、每天_各APP版本_广告点击量
广告曝光UV：
1、每分钟_广告位总曝光uv
2、每小时_广告位总曝光uv
3、每天_广告位总曝光uv
4、每天_各行业广告_广告曝光uv
5、每天_各广告主_广告曝光uv
6、每天_各Tab栏_广告曝光uv
7、每天_各手机系统_广告曝光uv
8、每天_各APP版本_广告曝光uv
广告点击UV：
1、每分钟_广告位总点击uv
2、每小时_广告位总点击uv
3、每天_广告位总点击uv
4、每天_各行业广告_广告点击uv
5、每天_各广告主_广告点击uv
6、每天_各Tab栏_广告点击uv
7、每天_各手机系统_广告点击uv
8、每天_各APP版本_广告点击uv
广告点击率CTR：
1、每分钟_广告位总点击CTR
2、每小时_广告位总点击CTR
3、每天_广告位总点击CTR
4、每天_各行业广告_广告点击CTR
5、每天_各广告主_广告点击CTR
6、每天_各Tab栏_广告点击CTR
7、每天_各手机系统_广告点击CTR
8、每天_各APP版本_广告点击CTR
广告收入/费用：
1、每分钟_广告总收益
2、每小时_广告总收益
3、每天_广告总收益
4、每天_各行业广告_总收益
5、每天_各广告主_总费用
6、每天_各Tab栏_广告总收益
7、每天_各手机系统_广告总收益
8、每天_各APP版本_广告总收益
元数据结构
| 字段 | 字段类型 | 描述 | |
|---|---|---|---|
| adid | string | 广告ID | |
| displayType | string | 广告形式 | 1、大图图文广告， 2、小图图文广告，3、动图广告，4，视频广告 |
| tab | string | Tab栏 | |
| industry | string | 广告行业 | 汽车、理财贷款、社交交友、教育、电商购物、家电、3C数码、旅游、游戏、娱乐、餐饮美事、其他 |
| advertisers | string | 广告主 | 宝马、奥迪、抖音、快手、京东、淘宝、海尔、小米、华为... |
| action | string | 操作行为 | 广告曝光、广告点击 |
| income | numberic | 收益 | |
| os | string | 用户手机系统 | android、ios |
| version | string | App版本 |
热门话题数据监控
一般这类场景一个话题下可以包含多个帖子，按假如我们有如下数据需求：
统计需求梳理
各话题曝光量、点击量
1、每10分钟_各话题_各行为类型_pv量
2、每小时_各话题_各行为类型_pv量
3、每天_各话题_各行为类型_pv量
各话题曝光UV量、点击UV量
1、每10分钟_各话题_各行为类型_uv量
2、每小时_各话题_各行为类型_uv量
3、每天_各话题_各行为类型_uv量
各话题的ctr
1、每10分钟_各话题_CTR
2、每天_各话题_CTR
元数据结构
| 字段 | 字段类型 | 描述 |
|---|---|---|
| topicId | string | 话题ID |
| imei | string | 用户标识 |
| itemId | string | 话题下的帖子ID |
| action_type | string | 用户行为类型 1：曝光、2：点击 |