这是一个数据分析项目。
不是线上生产系统，是一个基于真实处理结果整理出来的运营分析样例。重点工作是把数据口径、基础判断和解释边界说明白。
这个仓库最早更接近一个前端展示页。重做时，保持了技术栈和 UI，主要做了两件事：
-
让页面上的指标来自真实聚合结果，而不是固定示例数据。
-
让看板更像一个可以拿去面试讨论的运营分析作品，而不是一个纯展示 demo。
这个项目主要想回答几个比较基础、但在游戏运营中很常见的问题。
-
新用户留存是不是有明显流失点？
-
活跃用户结构偏不偏轻，哪些人群更值得优先运营？
-
收入是不是过度集中在少数高价值用户？
-
当前 A/B 样本能不能支持明确判断？
它主要能说明下面几件事：
-
指标口径说清楚。
-
用数据解释留存、活跃和收入结构。
-
区分“数据结果”“分析解释”和“运营假设”。
-
在证据不足时明确说边界，而不是硬下结论。
本项目使用的数据来自 Kaggle 公共数据集 Gamelytics: Mobile Game Analytics Challenge。
数据集地址：https://www.kaggle.com/datasets/debs2x/gamelytics-mobile-analytics-challenge
仓库中的 data/raw/Gamelytics/ 是这套公开数据集的本地副本。本项目基于这套公开数据完成了预处理、聚合和看板分析。
当前使用的原始文件包括：
reg_data.csv：注册数据，100 万用户。
auth_data.csv：登录数据，960 万+ 行。
ab_test.csv：A/B 变现实验样本，404,770 用户。
由于 auth_data.csv 体量较大，页面不直接读取原始 CSV，而是先离线处理，再由前端读取轻量结果文件。
离线处理脚本：scripts/prepare_dashboard_data.py
页面直接读取的结果：data/dashboard-metrics.json
另外还保留了一组便于核对的处理结果。
data/processed/daily_metrics.csv
data/processed/cohort_retention.csv
data/processed/activity_segments.csv
data/processed/ab_test_summary.json
data/processed/dashboard_payload.json
这里没有做复杂的数据工程，主要是因为大体量登录日志不适合直接丢给前端，作品集页面上的数字也应该能回溯到具体聚合结果。
页面沿用现有结构，主要分成几块。
总览：DAU、D1 / D7 留存、实验样本付费率、ARPU、ARPPU。
留存分析：D1 / D3 / D7 / D14 / D30 留存、完整留存曲线、月度 cohort。
营收分析：实验样本口径下的总营收、付费率、收入结构和付费层级。
A/B 样本结果：A / B 两组的样本内付费率、ARPU 和基础显著性结果。
洞察与建议：把结果整理成适合讨论的风险信号和候选方向。
其中“洞察”和“建议”需要分开理解。洞察里的数字来自聚合结果，建议是基于当前结果提出的运营假设，不是已经验证完成的方案。
定义：按自然日去重的登录用户数。
页面展示：近 7 日平均 DAU，以及 2020 年周均 DAU 趋势。
定义：定点留存（exact-day retention），不是滚动留存。
解释：Dn 表示用户是否在注册后第 n 个自然日登录。
处理方式：对尚未成熟的窗口，分母按可观测用户计算。
这也意味着留存曲线不一定单调下降，D7 高于 D1 不自动代表计算错误。这里的留存更适合拿来找流失节点和节奏信号。
定义：按注册月份聚合的留存 cohort。
页面主展示：2020 年注册 cohort。
页面主展示聚焦 2020 cohort，主要是为了让近期样本更集中、页面更容易读。更早月份的完整结果仍保留在 data/processed/cohort_retention.csv。
付费率：实验样本中付费用户占比。
ARPU：实验样本总收入 / 实验样本总用户数。
ARPPU：实验样本总收入 / 实验样本付费用户数。
这些指标只代表 ab_test.csv 样本，不代表全部注册用户。
页面展示的是 A / B 两组样本用户数、样本内付费率差异、样本内 ARPU 差异和基础显著性结果。
这里的定位是“样本结果解读”，不是完整的实验评审结论。
从运营分析角度看，这个项目比较适合支撑几类基础判断。
新用户首日和首周留存哪里掉得比较明显。
近期 cohort 之间有没有明显差异。
活跃用户结构里，沉默用户、中层活跃、核心活跃分别占多少。
收入是不是过度依赖少数高价值用户。
A/B 样本里有没有值得继续验证的趋势，或者有没有明显不能直接推广的风险。
这些判断都比较基础。这个项目的重点不是把分析做复杂，而是把口径、结果和边界讲清楚。
这个项目有几条需要直接说明的限制：
全量活跃/留存分析和 A/B 变现实验分析不是同一用户母体。
所以不能把全量留存和实验样本 ARPU 直接拼成一个完整经营漏斗。
变现相关结论只代表 ab_test.csv 样本。
当前数据没有提供实验起止时间、分流规则、曝光口径，也没有版本、活动、渠道等上下文。
因此 A/B 模块只能做样本结果解读，不能当成完整上线结论。
页面里的建议属于候选方向，仍然需要进一步验证。
生成聚合结果：
python3 scripts/prepare_dashboard_data.py启动本地静态服务：
python3 -m http.server 8000浏览器打开：
http://127.0.0.1:8000/
补充说明：页面通过 fetch() 读取 JSON，不建议直接双击打开 index.html。预处理脚本依赖 pandas。
index.html：页面结构。
gamelytics-dashboard.css：页面样式。
gamelytics-dashboard.js：前端渲染逻辑。
scripts/prepare_dashboard_data.py：离线处理脚本。
data/dashboard-metrics.json：页面直接读取的聚合结果。
data/processed/：便于核对的处理输出。
把页面里的建议进一步改成“运营假设 + 验证方式”。
给 cohort 增加样本量或可观测用户说明，减少误读。
给 A/B 补一张更完整的说明卡片，明确样本范围和结论边界。
把活跃分层再往运营表达上收一层，比如更清楚地区分召回对象和深化对象。