前文:
流量分析主要有两种需求;一种时多维统计分析,一种是用户行为分析(浏览数据) ;通过hudi解决数据入湖问题,再通过按两种需求拆分建设思路;指标问题如传统ads层计 算出结果导致多张汇总表无法对齐去重指标,这里主要以olap系统如doris的rollup解决数据性能及精准性问题;
一、业务特点
1.1 相关需求
用户行为分析(浏览数据) | 多维统计报表 | |
---|---|---|
需求 | 页面分析、着陆分析、漏斗分析、事件分析、留存分析 | 各种维度 |
特点 | 仅需浏览日志; | 浏览+曝光+点击+其他互动行为 |
建设思路 | 需要业务过程表;拉宽明细; | 非业务过程表;直接汇总; |
1.2 相关字段
维度: utm、spm、区域、sku、版本号、关键字等
指标:用户数、新用户数、浏览量、会话数、曝光数、点击数、点击率、平均访问深度等;加购、收藏等;
相关介绍:
utm参数:运营推广在第三投放广告,填写相关utm参数,通过事前归因用户来源,分析哪个渠道的用户价值高。
spm参数:业务分析通过spm参数,分析坑位点击率,优化站内坑位分布/推送内容。
版本号:用于A/B test。
1.3 相关问题
1.数据量:浏览 1000万+、曝光 8000万+、点击 200万+ ;
主要构建多张轻度汇总表(有曝光无商品)+ 一张 有曝光有商品(产品综合统计,商品粒度太细);
2.数据分析:
最好上报页面id,通过事后归因页面有多个问题:规则库是否准确/存在一堆多问题;归因计算量大,且复杂;
二、采集及架构
2.1 采集
问题:流量数据最多有3小时入库延迟;
解决方案:用 flink - hudi 加快ods层入库时效性;流量表 = 天表 + 小时表(每小时跑最近3小时数据) ;
2.2 流量架构
2.2.1 思路一 (实体分析)
思路:按实体表建设 主题层:
存在问题:业务倾向多维分析,不满足现状;
2.2.2 思路二 (多维分析,推荐)
思路:倾向多维分析; 一张多业务过程宽表 + 业务过程宽表(浏览分析) + 多张无业务过程表(轻度汇总/沉淀指标)
思路一:参考网易 | 思路二:参考美团 | |
---|---|---|
特点 | 明细拉宽+实体表 | 主题层拉宽+汇总表 |
时效性 | 3 要拉宽数据入库 | 4 多了ods->dwd |
扩展性 | 3 底层数据,不方便改动 | 5 分析场景驱动 |
可分析 | 3 底层数据,不方便改动 | 4 分析场景驱动 |
适用性 | 4 实体表,按分析主题划分,每个实体都有自己的口径,现状实体较少 | 5 用汇总表,通用统计场景,与现状类似 |
参考:
三、质量监控
1.数据源监控
主要监控每日波动率、字段空值率等,重新消费kafka/跟业务解释数据下降原因;
2.加工逻辑监控(数据开发核心设置)
每天7点质量监控;通过自定义sql查询 上下游 group by 数据量是否一致;核心指标(金额/流量数)是否一致;
3.指标监控
一般是业务自己每天看报表监控;可通过bi报表自定义看板设置告警;