diff --git a/CLAUDE.md b/CLAUDE.md
index 3038d30..b84b543 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -122,6 +122,41 @@ score_all     = score_latency * 70 + score_model * 30
 
 **策略指标以 baseline 为上限**，指标下降会扣分，超出范围直接 0 分。
 
+## 数据分析
+
+### 数据规模
+
+| 维度 | 数值 |
+|------|------|
+| 历史数据 | 15 文件 × ~650K 行 = **923 万行**，15GB |
+| 测试集 | **7,774 条预测**，13MB |
+| 缓存 batch | 9 个 shard，17GB，共 **2,039 batch** |
+| Slot 数量 | 1-28（28 个特征槽） |
+
+### 数据格式
+
+```
+# History（5 列，含 clk）:
+logid,userid,adid,clk,timestamp,sign:slot,...
+
+# Test（4 列，无 clk）:
+logid,userid,adid,timestamp,sign:slot,...
+```
+
+### 特征分布特征
+
+1. **Slot 28 是瓶颈槽位**：每个样本含 30-50 个 `sign:28` 特征，远超其他 slot。`segment_reduce` 在 slot 28 上占据 RepEncoder 最大开销。
+2. **Slot 19 高度冗余**：同一样本内连续出现大量相同 `sign:19`（如 `96:19` 重复 40+ 次）。在 `segment_reduce(sum)` 中，N 个相同 sign 等价于 `N × emb`，但代码独立查表 N 次再求和，浪费 embedding 带宽。
+3. **特征极度稀疏**：百万级 sign id，每个样本仅 100-200 个 sign。Embedding 查表是主要内存瓶颈。
+
+### 数据驱动的可优化方向
+
+| 方向 | 合规性 | 预估收益 | 说明 |
+|------|--------|----------|------|
+| Slot 19 同值合并 | ⚠️ | 小 | N 个相同 sign 合并为 `N × emb`，减少 embedding 查表次数。属数据预处理灰区 |
+| Slot 28 segment_reduce 融合 | ✅ | 中 | 将 slot 28 的大量 sign 预先按 offset 分桶，减少 kernel launch |
+| Embedding 查表带宽 | ✅ | 小 | 已用 FP16，embedding 5M×512 约 5GB |
+
 ## 优化路线图（来自 `推理优化方案.md`）
 
 Baseline 数据：推理 229s，AUC 0.759，PCOC 1.110，得分 25.85。