集团经营数据分析体系 · 需求诞生
当管理对象从一家商场变成一个集团
集团管理层不需要逐个进入商场页面完成集团分析；他们需要的是集团汇总、商场横向比较和统一考核入口。
从效率抱怨追到产品问题
下载次数多只是症状，真正缺的是集团分析结构
先看集团目标与统一指标结果。
使用同一口径横向识别差异。
从异常结果定位到具体商场。
第一个需求 · 会员新增趋势 2.0
先定义“新增”，再设计统计记录
集团新增会员 ≠ 各商场新增会员之和
只统计真正首次开卡的会员。
会员首次在该商场开卡。
已在其他商场开卡，首次在该商场产生有效会员交互。
商场新增开卡会员 + 商场新增关联会员。
日期 × 商场 × 新增类型 × 来源维度 → 新增数量 业务口径被转译成可以按集团和商场查询的组合统计记录。
第二个需求 · 销售趋势
从订单事实推导经营指标
SO负数 RSOMCUid商场 / 门店日粒度
SO 与负数 RSO 共同计算
按有效订单事实统计
按 MCUid 去重
由对应分子与分母计算
基于 MCUid 完成新老客判断
日期 × 商场 / 门店 × 数据来源 × 支付渠道 → 日指标统计记录 周 / 月比例需要重新聚合分子与分母，不能简单平均每日百分比。
第一代方案
把查询结果提前算好，是早期上线的合理取舍
触发对应组合统计记录的增量更新。
预先保存常用维度组合的查询结果。
按单日、单商场重新统计，降低同步失败风险。
以较低查询成本支持需求快速落地。
第一代模型不是错误方案；它解决了当时最重要的“先让集团用起来”。
使用中暴露边界
每增加一个分析维度，也增加一组更新责任
商场、来源、渠道和业务维度交叉生成更多统计节点。
业务事件可能遗漏、错乱，或需要历史回溯补算。
空值也成为维度值，扩大组合和解释成本。
兜底机制逐步带来资源消耗和数据风险。
统计错误与修复工作频繁出现。
新增平台或维度需要继续扩写更新链路。
继续扩写组合结果表，会把每个新维度变成新的更新责任。
模型实验台
从组合结果，回到可以追溯的业务事实
动画表达的是建模决策，不表示旧报表已经自动迁移。
结果先算好，更新责任随维度增长
商场×来源日期×渠道空值组合历史重算
先记录真实发生了什么
日活记录启动日志 页面访问日志新增会员明细
再按管理问题选择分析维度
商场平台日期用户类型打开来源推广渠道页面路径
04 · 对象如何被投影为指标
先保留真实行为，再按问题选择聚合方式
开卡或绑卡事实及其转化与推广上下文
用户在某平台、商场和日期的日活事实
每次启动及其来源、渠道和会员状态
页面访问事实，并关联日活与启动上下文
按需聚合不等于所有对象合成一个通用宽表，也不等于旧报表已经完成迁移。
产品反思
页面只是数据产品的最后一层
- 01谁用数据？
先识别集团管理者与商场经营者。
- 02做什么决策？
明确汇总、比较、考核与下钻动作。
- 03指标怎么定义？
把业务口径写成可复核的计算关系。
- 04事实对象是什么？
区分订单、日活、启动、访问与新增事实。
- 05按什么粒度聚合？
尊重日、商场、门店、用户与事件粒度。
预聚合帮助快速上线，明细与埋点对象帮助持续扩展；它们是不同阶段的产品选择。
会员新增趋势 2.0小程序访问趋势积分产生 / 消耗趋势销售趋势
技术债 · 完整一章
如实区分已上线、旧方案、方案完成与未排期
小程序访问趋势积分产生 / 消耗趋势
会员新增趋势 2.0销售趋势
有价券分析
会员新增趋势 2.0 数仓改造销售趋势数仓改造拍照积分订单纳入销售趋势
能力边界：MCUid 与统一 SO 只是继续关联分析的基础，不表示统一漏斗已经上线。
真实运行与本人角色
从集团考核需求，生长为可以持续演进的数据产品
客户沟通、问题抽象、指标与分析维度建模、数据方案研究、集团—商场两级结构、PRD 与原型、协作和交付推动。
研发与数据团队完成工程实现；本案例不把数据开发、埋点开发或数仓建设表述为本人独立完成。