# shoplytics
**Repository Path**: zeroonei1/shoplytics
## Basic Information
- **Project Name**: shoplytics
- **Description**: ecommerce user analytics
- **Primary Language**: Unknown
- **License**: MIT
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No
## Statistics
- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-06-13
- **Last Updated**: 2026-07-03
## Categories & Tags
**Categories**: Uncategorized
**Tags**: None
## README
---
## 核心结论
> 在单机上以 Polars **~0.4 秒**完成 **2,900 万行**电商行为数据的清洗与特征工程，构建覆盖用户留存、转化漏斗、RFM 分群、A/B 测试、**uplift 增益建模（CATE）**、流失预测、协同过滤推荐的用户生命周期全链路分析管线。在 8 万用户采样、5 个随机种子下 S-learner 取得 **AUUC_normalized = 0.71**（treatment 为事后模拟、ATE≈0，点估计方差大，详见下方 uplift 模块），并以 **31 项 dbt 数据质量测试** + GitHub Actions 四重 CI（lint / sql-lint / test / docker-build）保障工程化交付。**从 A/B 测试的「平均处理效应 ATE」推进到 uplift 建模的「条件处理效应 CATE」**——识别推荐对*哪类*用户有效——是本项目的因果学习记忆点，并诚实标注 treatment 为事后模拟的语义边界。
| 维度 | 关键结果 |
|------|---------|
| 数据规模 | **2,900 万行**（29,128,402 条）· 287,004 用户 · 2,584,623 商品 · 5,132 品类（2017-11-24 ~ 12-03）|
| ETL 性能 | Polars **~0.4s** 清洗 29M 行（比 Pandas 快约 60×）|
| Uplift（S-learner） | AUUC_normalized = **0.71** · Qini 系数 +1.8（5 种子均值；ATE≈0 下方差大）|
| 流失预测 | XGBoost AUC **0.73** / 逻辑回归 AUC **0.80**（按 `last_active_date` 时间切分）|
| A/B 测试 | lift +0.44% · p=0.43（不显著，post-hoc holdout 设计）|
| 工程化 | dbt **31 项**数据质量测试全绿 · CI 四检查 |
**Uplift 增益曲线（S/T-learner）—— 从 ATE 推进到 CATE 的深度记忆点**
*uplift curve · Qini curve · 十分位校验三联图，完整指标见 [`reports/uplift_results.json`](reports/uplift_results.json)*
交互式 dashboard：留存 / 漏斗 / RFM / uplift 曲线的实时探索
---
## 数据
| 属性 | 值 |
|------|-----|
| **来源** | 阿里云天池 —「电商用户行为」公开数据集 |
| **规模** | 287,004 用户 · 2,584,623 商品 · 5,132 品类 · **29,128,402 条记录** |
| **时间窗口** | 2017-11-24 ~ 2017-12-03（共 10 天） |
| **行为类型** | `pv`（浏览）· `buy`（购买）· `cart`（加购）· `fav`（收藏） |
> 秒级时间戳支持精细的行为序列建模；2,900 万行规模为验证 Polars / DuckDB 等现代分析工具的大吞吐性能提供了充足的实验场。
数据集统计特征（社区参考值，点击展开）
> 本数据集为开放数据集（非竞赛），以下指标来自社区常见分析结果，供数据规模与业务水平参考：
| 指标 | 值 | 说明 |
|------|-----|------|
| 总浏览量（PV） | 3,431,900 | 10 天累计 |
| 总访客数（UV） | 37,376 | 去重用户数 |
| 跳失率 | **5.87%** | 仅浏览无其他行为 |
| 浏览 → 购买转化率 | **2.2%** | 整体转化 |
| 浏览 → 加购转化率 | **58.8%** | 商品详情页引导效果 |
| 加购 → 购买转化率 | **38.9%** | 购物车召回潜力 |
| 复购率 | **65.8%** | 购买 2 次及以上用户占比 |
---
## 快速开始
```bash
git clone https://github.com/MeaFew/shoplytics.git
cd shoplytics
# 下载数据集（GitHub Releases，约 264MB）
bash download_data.sh
# 验证环境（lint + test + format-check + audit）
make verify
# 运行完整分析管线
make all
# Windows (无 GNU Make):
# python run_all.py
# 启动交互式看板
make dashboard
```
---
## 核心指标一览
| 指标 | 值 | 业务解读 |
|------|-----|---------|
| 日均 DAU | 205,798 | 10 天核心窗口期间活跃用户规模稳定 |
| PV → 购买转化率 | **2.24%** | 典型电商水平，优化空间在于首页推荐精准度 |
| PV → 加购转化率 | 6.21% | 商品详情页设计对加购引导有效 |
| 加购 → 购买转化率 | **36.04%** | 购物车召回（短信/推送）是高 ROI 优化点 |
| 次日留存率 | 74.6% | 新用户首周留存健康 |
| 零转化商品占比 | 89.3%（2,243,686 件）| 长尾商品流量枯竭，需优化推荐长尾分发策略 |
> 上述指标现由 `scripts/pipeline.py::compute_headline_metrics` 计算并写入
> `reports/pipeline_summary.json`（`headline_business_metrics` 字段），而非仅作为
> 静态数字写在 README 中。**次日留存率**定义为"首日活跃用户在次日仍活跃的比例"；
> **零转化商品**定义为"曾被浏览但从未被购买的商品"占"全部被浏览商品"的比例。
>
> Windows 用户注意：直接运行 `sqlfluff lint sql/` 若遇到编码错误，请先执行
> `set PYTHONUTF8=1`（CMD）或 `$env:PYTHONUTF8=1`（PowerShell）。
>
> 完整业务洞察报告：[reports/business_insights_report.md](reports/business_insights_report.md)
---
## 技术架构
```
┌─────────────────┐
│ UserBehavior │
│ CSV (29M) │
└────────┬────────┘
│ Polars ETL (~0.4s)
▼
┌─────────────────────────────────────────────────────────────┐
│ DuckDB / Parquet │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │
│ │ SQL Analysis│ │ dbt Models │ │ PySpark (MLlib) │ │
│ │ 7 scripts │ │ staging → │ │ ALS 矩阵分解 │ │
│ │ │ │ intermediate│ │ (分布式) │ │
│ │ │ │ → marts │ │ │ │
│ └──────┬──────┘ └──────┬──────┘ └──────────┬──────────┘ │
└─────────┼────────────────┼────────────────────┼─────────────┘
│ │ │
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ XGBoost │ │ Streamlit │ │ Jupyter │
│ Churn Model│ │ Dashboard │ │ Notebooks │
│ (11 feats) │ │ (KPI/R/F/M)│ │ (EDA/AB/ │
│ AUC ≈ 0.7* │ │ │ │ Cohort) │
└────────────┘ └────────────┘ └────────────┘
```
---
## 分析模块（11 项）
| # | 模块 | 核心技术 | 产出价值 |
|---|------|---------|---------|
| 1 | **用户留存分析** | Self-join + 窗口函数 `ROW_NUMBER` / `LAG` | D1/D3/D7 留存曲线，识别流失拐点 |
| 2 | **转化漏斗** | CTE + 条件聚合 + 路径分类 | 四步漏斗（PV → 收藏/加购 → 购买），定位最大 leak |
| 3 | **RFM 用户分群** | `NTILE(5)` 分箱 + 生命周期状态迁移 | 8 类用户画像（冠军/忠诚/新客/流失预警等） |
| 4 | **A/B 测试框架** | hash 无偏分组 · SRM 卡方校验 · 双比例 Z 检验 · 95% CI · 推荐器 lift 度量 | post-hoc holdout 设计：control 组训练推荐器 → treatment 组模拟曝光 → 对称 Z 检验 |
| 5 | **Uplift 增益建模** | S-learner / T-learner (CATE) · AUUC / Qini · 十分位校验 | 从「平均效应 ATE」推进到「条件效应 CATE」：识别推荐对*哪类*用户有效（反事实框架）|
| 6 | **流失预测** | XGBoost vs 逻辑回归 · 11 维特征工程 · ROC-AUC | 时间切分 AUC ≈ 0.7（见下方说明）|
| 7 | **推荐系统** | UserCF（余弦相似度）· ALS（PySpark MLlib） | 协同过滤 + 矩阵分解双方案对比 |
| 8 | **异常检测** | 3σ 规则 + 移动平均 | 自动化日报 + 异常行为告警 |
| 9 | **Cohort & LTV** | cohort 留存热力图 · 行为加权价值估计 | 用户群组生命周期价值追踪 |
| 10 | **交互看板** | Streamlit + Plotly · KPI 卡片 · 漏斗 · RFM | 产品/运营团队的自助分析工具 |
| 11 | **数据工程** | dbt 模型分层 · 31 项数据质量测试 | 可版本控制的分析数据管线 |
---
## 技术栈
| 层级 | 工具 | 选型理由 |
|------|------|---------|
| 数据处理 | **Polars**（Rust 核心）· Pandas · **PySpark** | Polars 在 29M 行数据上比 Pandas 快 60 倍；PySpark 用于 ALS 分布式矩阵分解 |
| SQL 引擎 | **DuckDB** | 零配置、列式 OLAP，单节点即可秒级聚合 29M 行 |
| 数据工程 | **dbt** | 模型版本化、血缘追踪、自动化测试，将分析 SQL 从脚本升级为工程化管线 |
| 统计建模 | scikit-learn · **XGBoost** · SciPy · statsmodels | XGBoost 处理高维稀疏特征；statsmodels 提供经典统计推断 |
| 可视化 | Matplotlib · Seaborn · **Plotly** | Plotly 交互式图表直接嵌入 Streamlit |
| 交付 | **Streamlit** · **Apache Superset** · Jupyter | Streamlit 做轻量自助看板；Superset（Docker）做交互式 BI 演示 探查 |
| 质量保障 | pytest · **ruff** · sqlfluff · GitHub Actions | CI 全绿 = 代码规范 + SQL 规范 + Docker 构建三重校验 |
---
## 局限与生产化路径
| 局限 | 影响 | 生产化方案 |
|------|------|-----------|
| 约 10 天有效窗口 | 无法观察月度季节性；D7+ 留存右删失 | 扩展至 ≥90 天数据，引入 Prophet / ARIMA 预测 |
| 无金额字段 | GMV、ARPU、CLV 无法计算；RFM 退化为 RF | 关联订单/交易表，补全 monetary 维度 |
| 无用户属性 | 缺失 demographics、设备、渠道分段 | 关联用户画像表，支持多维 cohort 分析 |
| A/B 测试为离线模拟 | 离线行为日志无在线实验事件，用 control 组训练的 item-CF 推荐器对 treatment 组模拟曝光 | 接入真实在线实验平台（Optimizely / 内部 AB 系统）记录曝光与转化事件 |
| Uplift treatment 为事后虚拟 | hash 派生的 W 与 outcome 无真实因果链路（ATE≈0），多种子分析显示 uplift 指标退化为噪声（std>点估计） | 换成真实在线实验曝光标志 + 真实转化事件即可整体迁移 |
| 单节点执行 | DuckDB + 本地 Parquet | Hive / Spark on 分区 Parquet + Airflow 调度 |
> A/B 测试采用 **post-hoc holdout 设计**回答"推荐器是否提升转化"：用 hash 把用户无偏地劈成 control / treatment，仅在 control 组的观察窗口训练 item-CF 推荐器（模型不接触 treatment 用户），再对 treatment 组模拟推荐曝光，用对称的双比例 Z 检验比较两组的预测窗口转化率。这份数据上结果为 lift=+0.44%、p=0.43（**不显著**）——这是诚实的结论：低命中率的 item-CF 在事后模拟里几乎不产生因果效应，框架本身（SRM 校验 + 对称分母 + Z 检验）严谨可用，可整体迁移至有真实在线实验数据的场景。
---
## Uplift 增量建模（CATE 估计）
A/B 测试回答的是**平均处理效应（ATE）**：「推荐对*所有人平均*有用吗？」但增长 / 推荐方向真正的问题是**条件平均处理效应（CATE）**：「推荐对*哪一类*用户有用？」——把营销预算花在「会被推荐打动」的人身上，而不是「无论如何都会买」或「无论如何都不买」的人。`scripts/uplift_modeling.py` 把项目从 ATE 层面推进到 CATE 层面，这是推荐 / 增长作品集里稀缺的「反事实因果学习」记忆点。
为什么需要它（A/B 测试的方法论局限）—— 点击展开
| 维度 | A/B 测试（ATE） | Uplift 建模（CATE） |
|------|----------------|--------------------|
| 回答的问题 | 推荐对**全体**平均有效吗？ | 推荐对**哪类**用户有效？ |
| 输出 | 一个 lift 数字 + p 值 | 每个用户的预测增量 τ̂(x) |
| 落地价值 | 决定「要不要上」 | 决定「对谁上」——精细化投放 |
| 局限 | 群体平均，忽略异质性 | 需要可观测的 treatment 信号 |
怎么做的（S/T-learner 原理与特征工程）—— 点击展开
```
特征 X (观察窗口 user-level 行为)
treatment W (hash 分流 0/1)
outcome Y (预测窗口是否购买)
│
┌─────────────────────┴─────────────────────┐
▼ ▼
S-learner T-learner
┌─────────────────┐ ┌──────────────────┐
│ 单模型 P(Y|X,W) │ │ P_T(Y|X) P_C(Y|X)│
│ 把 W 当一列特征 │ │ 两个模型各拟一边 │
└────────┬────────┘ └────────┬─────────┘
│ │
τ̂(x)=f(x,W=1)−f(x,W=0) τ̂(x)=P_T(Y=1|x)−P_C(Y=1|x)
```
- **S-learner**：单模型把 treatment W 当作一列特征拼进 X，预测时对同一样本分别查 W=1 / W=0，差值即 CATE。优点是只用一个模型、小样本稳健；缺点是 W 只是一列特征，弱信号容易被强特征淹没（正则化下 treatment 维可能被早早剪枝）。
- **T-learner**：两个独立模型分别拟合 treatment / control，预测时各算 P(Y=1) 再求差。优点是处理效应显式建模；缺点是每个模型只用一半数据，方差更大。基础学习器统一用 XGBoost。
**特征 X**（15 维，严格只用观察窗口 `< 2017-12-01` 的事件，杜绝标签泄漏）：各类行为计数（pv/buy/cart/fav/总事件）、活跃天数、活跃小时数、最近一次行为距今天数、周末活跃占比、品类多样性、商品多样性、行为转化率、活跃小时熵。
**评估指标**：uplift curve（累积增益曲线）、Qini curve（累积增量正样本数）、AUUC（uplift curve 下面积）、Qini 系数（与随机基线的差）；另把测试集按预测 uplift 十等分，验证「高预测 uplift 分位是否真的有更高的真实增量」。
### 结果（采样 8 万用户 / 287k 全量，5 个 split 种子均值±std）
| 模型 | AUUC | Qini 系数 | 最高 vs 最低十分位真实增量差 |
|------|------|-----------|------------------------------|
| **S-learner** | 12.7 ± 44.6 | +1.8 ± 22.3 | +0.017 ± 0.024 |
| T-learner | −9.3 ± 31.7 | −9.2 ± 15.8 | −0.002 ± 0.028 |
> 指标对 **5 个不同的 train/test split 种子**取均值±std。之所以要多种子：因为 treatment 是事后虚拟的（ATE≈0），**单次** split 下 uplift 指标方差极大、符号会随机翻转（一次跑出 +60、再跑可能 −30），单次数字没有意义；多种子均值±std 才是诚实的点估计。
**最诚实也最重要的发现**：两组的**平均转化率几乎相同**（treatment 38.43% vs control 38.36%，ATE = +0.001，本质上为零）——这恰好印证了下方「treatment 是事后虚拟的」语义。**在 ATE≈0 的数据上，模型无法稳健恢复 CATE 排序**：所有 uplift 指标的**标准差都大于点估计的绝对值**，十分位校验曲线也**不是单调**的（围绕 0 抖动，见上方 `images/uplift_curve.png` 右图）。换句话说——**没有真实 treatment 信号时，uplift 建模退化为在噪声上拟合**。
这恰恰是这个模块的价值所在：它**诚实地展示了 uplift 建模的完整方法学（特征工程 → S/T-learner → AUUC/Qini → 多种子不确定性 → 十分位校验），并通过严格的多种子分析揭示了「无真实 treatment → 无可恢复 CATE」这一结论**——而不是用一个碰巧为正的单次数字误导读者。框架本身（含多种子稳健性检验）严谨可用，**只需把 W 换成真实在线实验曝光标志、Y 换成真实转化事件，即可在有真实 treatment 的数据上恢复有意义的 CATE 排序**。
> 完整指标见 [`reports/uplift_results.json`](reports/uplift_results.json)，可视化（uplift curve / Qini curve / 十分位校验三联图）见上方 [`images/uplift_curve.png`](images/uplift_curve.png)。
### ⚠️ 语义边界：treatment 是事后模拟的（诚实说明）
**这一点必须明确，不能夸大成「发现了真实因果效应」**。原始数据是*观察性*行为日志：control / treatment 两组用户在当时经历的是*同一个*线上系统，**没有任何干预真的发生**。本模块用 `hash_group(user_id)`（与 `ab_testing.py` 完全一致）派生一个虚拟二值 treatment W，因此在 W 与 outcome Y 之间**没有真实的因果链路**——上面的多种子结果（点估计≈0、std 占主导）正是这一点的统计印证。
所以我们估计的是「**假想推荐部署**」这一*反事实框架*下的 CATE——用于展示 uplift 建模的方法学（特征工程、S/T-learner、AUUC/Qini、多种子不确定性、十分位校验），而非声称发现了真实因果效应。报告与文档中均据此表述。
**框架本身严谨可用**：只需把 W 换成真实在线实验的曝光标志、Y 换成真实转化事件，即可整体迁移到生产场景（接入 Optimizely / 内部 AB 平台记录曝光与转化）。在有真实 treatment 信号的数据上，本管线会恢复出有意义的 CATE 排序——届时「uplift 模型能定位 responder 子群」的能力才会真正显现。
---
数据与建模正确性修正（重要，点击展开）
本管线对几处影响结论正确性的问题做了修正：
- **RFM 评分方向（dbt marts）**：`mart_user_segments` 与 `mart_rfm_segments` 此前三列评分方向不一致，导致运营用的 `value_tier` / `rfm_segment` 把"低价值/流失"用户标成"高价值/重要价值"。已统一为 `(6 - NTILE(5) OVER (ORDER BY x [A/D]SC))` 使 5 分=最优，并新增 `assert_rfm_score_direction.sql` 回归测试锁定该不变量。修正后高价值用户的平均 monetary/frequency 显著更高、recency 更低。
- **清洗报告计数**：此前 `removed_invalid_timestamp`/`removed_invalid_behavior` 被硬编码为 0、全部差值塞进 `removed_duplicates`。改为每步单独统计（真实值：时间戳越界 4,079 / 无效 behavior 0 / 重复 11 / 空ID 1），`data_quality_report.json` 现可信。
- **ID 类型与静默丢数据**：ID 列由 Int32 升级为 Int64（商品 item_id 可超 Int32 范围），并在清洗阶段显式丢弃并计数空 ID 行，消除"null 静默流入分析"的风险。
- **头条业务指标**：DAU、PV→购买/加购转化、加购→购买转化、次日留存、零转化商品占比，现由 `scripts/pipeline.py::compute_headline_metrics` 计算并写入 `reports/pipeline_summary.json`，而非仅作为静态数字写在 README。
- **流失预测的时间切分**：改为按 `last_active_date` 时间切分（训练早期活跃用户、测试晚期用户），是可部署的泛化估计而非随机重代入。注意建模在 10 万用户随机采样上进行（速度），时间切分 AUC 的样本方差较大；完整人群估计请移除采样上限。`dbt` 测试数从宣称的 29 修正为实际的 31（`dbt test` 全绿）。
- **推荐系统 Precision@10 的诚实报告**：UserCF 在极度稀疏的购买矩阵（约 99.8% 稀疏度，仅取前 500 名高购买用户）上命中率为 0，因此评估器在 UserCF 命中为 0 时回退到 popularity baseline。当前报告值为 **Precision@10 = 0.02**（popularity fallback）。这仍是一个 straw-man 基线；生产级推荐请使用 `pyspark/` 中的 ALS 矩阵分解。
- **Makefile 环境变量**：为所有 Python 目标注入 `PYTHONPATH=.`；为 `dbt` 目标注入 `DBT_DUCKDB_PATH` / `DBT_DATA_PATH` 的绝对路径，避免 `cd dbt` 后相对路径解析到错误位置。
---
项目结构（点击展开）
```
shoplytics/
├── scripts/ # Python 工具脚本
│ ├── preprocess.py # Polars ETL（~0.4s / 29M rows）
│ ├── pipeline.py # 管线编排入口（加载数据 → 调度各模块 → 汇总）
│ ├── eda.py # EDA 可视化（行为分布/DAU/活跃热力图）
│ ├── churn_prediction.py # 流失预测（LR + XGBoost + ROC/重要性图）
│ ├── ab_testing.py # A/B 测试（哈希分组 + Z 检验 + SRM 校验）
│ ├── uplift_modeling.py # Uplift 增益建模（S/T-learner CATE + AUUC/Qini）
│ ├── recommendation.py # 协同过滤推荐 + Cohort 留存 + LTV 估算
│ ├── run_sql.py # DuckDB SQL 批量执行
│ ├── validate_data.py # 数据质量校验
│ └── benchmark_preprocessing.py # Polars vs Pandas 性能基准
│
├── notebooks/ # Jupyter 分析笔记本（5 份）
│ ├── 01_eda_and_visualization.ipynb
│ ├── 02_user_churn_prediction.ipynb
│ ├── 03_ab_test_analysis.ipynb
│ ├── 04_recommendation_system.ipynb
│ └── 05_cohort_and_ltv.ipynb
│
├── sql/ # SQL 分析脚本（7 份）
│ ├── 01_database_setup.sql # Schema + 索引 + 视图
│ ├── 02_user_retention.sql # 留存分析（D1/D3/D7）
│ ├── 03_conversion_funnel.sql # 漏斗 + 路径分析
│ ├── 04_rfm_model.sql # RFM 分群
│ ├── 05_ab_test_framework.sql # A/B 测试数据准备
│ ├── 06_anomaly_detection.sql # 异常检测（3σ 规则）
│ └── 07_product_analysis.sql # 商品与品类分析
│
├── dbt/ # dbt 数据模型 + 测试
│ ├── models/staging/
│ ├── models/intermediate/
│ └── models/marts/
│
├── pyspark/ # PySpark 分布式计算（4 脚本）
├── dashboard/ # Streamlit 交互看板
├── superset/ # Apache Superset BI 配置
│ ├── superset_config.py # Superset 自定义配置
│ └── add_duckdb.py # DuckDB 数据源自动注册脚本
├── images/ # 生成的图表
├── reports/ # 分析报告
├── docs/ # 架构决策记录（ADR）
├── docker-compose.superset.yml # Superset Docker Compose 配置
├── Makefile # 工作流编排
└── requirements.txt
```
---
## BI 看板（Apache Superset）
除了 Streamlit 轻量看板，项目还集成了 **Apache Superset**（Docker）作为交互式 BI 演示 探查工具：
```bash
# 启动 Superset（需 Docker）
docker compose -f docker-compose.superset.yml up -d
# 首次启动约需 1–2 分钟完成初始化
# 访问 http://localhost:8088
# 用户名: admin / 密码: admin
```
**已预配置内容：**
- DuckDB 数据源自动连接（`analytics.duckdb`）
- SQL Lab 可直接对 2,900 万行数据执行 Ad-hoc 查询
- Explore 界面支持拖拽式图表创建（日活趋势、转化漏斗、品类分布等）
| 维度 | Streamlit | Apache Superset |
|------|-----------|-----------------|
| 定位 | 轻量自助看板 | 交互式 BI 演示 探查 |
| 使用场景 | 固定指标监控 | Ad-hoc 分析、下钻、多维切片 |
| 开发方式 | Python 代码 | 零代码拖拽 + SQL |
| 受众 | 产品经理/运营 | 数据分析师/管理层 |
> 生产环境中，Streamlit 适合嵌入业务系统的固定看板，Superset 适合分析师自助探索。两者互补而非替代。
---
## 相关资源
- [`docs/ADR.md`](docs/ADR.md) — 架构决策记录：为什么选 DuckDB、Polars、dbt，以及扁平化目录结构的设计考量
- [`CONTRIBUTING.md`](CONTRIBUTING.md) — 本地环境搭建、开发工作流、lint 规则与 commit 规范
- [`sql/README.md`](sql/README.md) — SQL 分析模块指南与数据库兼容性对照表
---
## 相关项目
| 项目 | 仓库 | 简介 |
|------|------|------|
| 营销归因与预算优化 | [MeaFew/attributor](https://github.com/MeaFew/attributor) | MMM + 多触点归因 + 预算优化 |
| 信用风险评分 | [MeaFew/riskscore](https://github.com/MeaFew/riskscore) | WOE/IV + XGBoost/LightGBM + SHAP 可解释性 |
| 多元时序预测 | [MeaFew/foresight](https://github.com/MeaFew/foresight) | LSTM / Transformer / XGBoost 时序预测对比 |
| 图神经网络反欺诈 | [MeaFew/graphguard](https://github.com/MeaFew/graphguard) | 图神经网络非法交易检测 |
---
## 许可证
数据集遵循阿里云天池的使用条款。代码采用 MIT License，仅供学习交流使用。 
**中文** | English