chore:文档补全
This commit is contained in:
@@ -0,0 +1,63 @@
|
||||
# 2026.06.22-日报-夏莲
|
||||
|
||||
Source: feishu docx XooedG5ydozuuWx8uQDcRji4nMb
|
||||
Fetched: 2026-06-23
|
||||
|
||||
---
|
||||
|
||||
# 2026.06.22-日报-夏莲
|
||||
## 一、今日内容概述
|
||||
- 整理《钲鼓连烽》数据资产与口径基础- 梳理七机制变量表并复核重点机制- 汇总七机制变量池并推进入模前检查- 同步本周与本月目标
|
||||
---
|
||||
|
||||
## 二、变量整理的基础准备
|
||||
|
||||
在完成数据资产梳理和口径对齐后,当前已具备进入第二轮试跑变量整理的基础。
|
||||
### (一)数据资产与口径确认
|
||||
|
||||
**主要依托以下材料:**- **全量数据资产明细总表**:作为数据总索引,用于查询文件、Sheet、字段、来源和用途。- **口径对齐检查表**:作为执行规则,用于统一主键、层级、时间窗口、后验风险和字段归口。- **最终边界项清单**:用于明确哪些字段可入池、哪些只能描述、哪些需要排除。
|
||||
**主要遵循以下流程:**>
|
||||
**数据资产盘点 → 口径对齐 → 字段边界确认 → 机制变量整理 → 入模前检查**- 重点确认了各数据表的样本单位、可合并主键、时间字段、初始 / 早期 / 全期 / 后验窗口,以及榜单、排名、胜负、领奖、兑换、战功等后验字段的使用边界。- 通过该步骤,可以减少后续重复确认,避免变量构造中出现字段来源不清、主键不可拼、时间窗口不一致或结果字段回灌等问题,也为后续七机制变量整理和第二轮试跑入模前检查提供统一基础。
|
||||
|
||||
### (二)七机制变量表梳理与版本清单整理
|
||||
|
||||
按七个机制分别整理变量表(独立机制表),把每个机制对应到可追溯的数据结构中,**重点确认三类信息:**- **机制与规则对应关系**
|
||||
明确每个机制对应哪些游戏规则,以及这些规则是否能在现有数据表中找到字段支撑。- **字段与样本层级关系**
|
||||
确认变量来自哪些数据表、使用哪些字段、属于个体层 / 团体层 / 赛局层,后续应采用什么样本单位和主键拼接。- **入池边界与可计算性**
|
||||
判断变量是主变量候选、替代变量候选、补充变量、灰名单还是排除项,同时标记是否可计算、是否存在后验风险、是否需要配置字典解释,以及是否可进入第二轮试跑。
|
||||
**当前七机制变量池初步汇总结果如下:**[嵌入表格]
|
||||
|
||||
### (三)激励性、补偿性复核
|
||||
|
||||
这两个机制第一轮是没有正式进入变量池的,所以这次先对这两个机制进行交叉复核。重点是对照两个版本的变量构建框架和计算逻辑稿。
|
||||
#### **激励性机制**
|
||||
激励性机制主要关注平台是否通过奖励结构、奖励梯度、奖励门槛和奖励可达性,形成玩家继续投入的激励。
|
||||
**变量维度:**>
|
||||
奖励结构、奖励梯度、奖励门槛、奖励可达性、个人奖励机会、阵营奖励机会
|
||||
**整理方式:**- 能补充现有变量计算逻辑的,写回正式变量表- 与现有主线变量重复的,不再新增变量行- 榜单状态、排名差距、接近上一名、头部冲榜区等偏反馈状态的变量,保留为灰名单或探索项
|
||||
|
||||
#### **补偿性机制**
|
||||
补偿性机制主要关注弱势、受损、资源不足或需要恢复再参与的玩家 / 阵营,是否通过规则获得恢复、保护、补兵、加速或 buff 扶持。
|
||||
**变量维度:**>
|
||||
弱势阵营补偿暴露、士气 buff、保护窗口、恢复能力、战损后恢复链、道具恢复链、补偿性状态代理
|
||||
**整理方式:**- 规则补偿和恢复链相关内容,吸收到正式变量表- 状态代理和诊断项,保留在桥接表或灰名单中- 行为结果和后验风险较高的内容,不直接进入正式变量池
|
||||
>
|
||||
**把独立机制变量汇总成一份《七机制变量池汇总表》,进行入模前检查**- **统一信息:**
|
||||
机制名称、变量名称、变量角色、所属层级、推荐主键、时间窗口、可计算性、后验风险、配置字典需求和第二轮试跑建议等信息,作为后续入模前检查和第二轮试跑准备的统一主入口。
|
||||
|
||||
---
|
||||
|
||||
## 三、入模前检查整理
|
||||
|
||||
判断变量是否具备入模资格,检查主要分为四类:
|
||||
**1. 边界检查**- **X / Y 边界检查**:检查机制变量是否与综合投入 Y 的 K / L 组成部分重叠。- **后验风险检查**:排除最终排名、胜负、领奖、最终战功等赛后结果字段,避免结果变量进入机制变量池。
|
||||
**2. 结构检查**- **层级检查**:确认变量属于个体层、团体层、赛局层还是活动层,避免不同层级变量混用。- **主键检查**:确认变量是否可以通过 role_id、activity_id 等字段稳定拼接到底表。- **时间窗口检查**:确认变量属于初始、早期、全期、滞后还是后验窗口。
|
||||
**3. 解释检查**- **变量方向检查**:确认变量数值方向是否与机制含义一致。- **配置字典检查**:对特殊字段标记解释,避免仅凭字段名直接判断变量含义。
|
||||
**4. 入池检查**- **重复 / 高重叠检查**:检查同一机制内部或不同机制之间是否存在高度相似变量,区分主变量、替代变量、补充变量和灰名单变量。- **第二轮准入判断**:结合 3 月、5 月真实数据可计算性,判断变量是否进入第二轮正式试跑。- **实算验证准备**:检查变量是否可计算、是否能稳定拼接、是否存在高缺失、零方差、异常值或跨月口径不一致等问题。
|
||||
**初步结果如下****:**>
|
||||
七机制变量池 → 七机制变量池入模前检查表 → 变量支持性归口 → 第二轮正式试跑入池清单[嵌入表格]
|
||||
|
||||
> #### 下一步计划
|
||||
> - **待确认口径问题:**参与名单 activity_id 与事件日志 activity_id 未闭合,影响活动日历和前 24 小时窗口切分。- activity_start_time 取规则开始时点还是最早真实行为时点仍需确认。- alliance_id 缺失处理规则尚未统一,影响公平性和流动性变量。- 都城 / 关键节点窗口口径仍需锁定。- 激励性、补偿性、私有性部分变量还需确认是否进入主跑或仅作观察诊断。- **推进中间表:**
|
||||
互动性、互补性和补偿性变量计算需要:活动日历表、城池时间序列表和 24 小时窗口相关中间表。- **真实数据验证:**
|
||||
保留变量进行 3 月、5 月真实数据验证,重点检查变量是否可计算、能否稳定拼接、是否存在缺失、零方差或跨月口径不一致等问题。
|
||||
Reference in New Issue
Block a user