Evilom
104 lines
11 KiB
Markdown
104 lines
11 KiB
Markdown
# 2026.06.18-日报-夏莲
|
||
|
||
Source: feishu docx XHVldO192otVP1xAfbfcJpfsndc
|
||
Fetched: 2026-06-22
|
||
|
||
---
|
||
|
||
# 2026.06.18-日报-夏莲
|
||
## 一、今日内容概述
|
||
- 完成第二批补充数据返回后的全量数据资产盘点- 整理《钲鼓连烽》文件、表、字段及字段来源- 完成数据层级、主键关系和时间窗口口径检查- 完成【进度报告】框架
|
||
|
||
---
|
||
|
||
## 二、数据结构说明部分
|
||
|
||
#### **样本层级与数据结构**
|
||
|
||
本研究数据具有多层嵌套结构。结合《钲鼓连烽》多人社交竞争活动的组织形式，将样本结构划分为**个体层、团体层和赛局层**三个层级。- **个体层：**指参与活动的玩家个体，对应玩家在具体活动中的行为与投入表现。>
|
||
**主要用于分析：**玩家个人投入、个人收益以及 K / L / Y 投入结构，例如个人付费、行为参与、战斗行为、营地建设、大臣委派等。- **团体层：**指活动中承担集体竞争结果的组织单位。对应游戏规则“盟营”。> **盟营：**活动中的三方竞争单位，承担城池占领、势力军威累计和最终胜负结果，可作为团体层主口径。- **跨服联盟：**盟营生成和报名匹配的基础单位，主要用于解释成员来源和匹配结构。- **队伍：**玩家执行出征、驻守、交战、撤退等行为的操作单元，主要用于行为过程分析。
|
||
后续需要进一步确认盟营 ID、联盟 ID、队伍 ID 等字段的完整性，并判断哪些字段作为团体层主口径，哪些字段作为组织画像或行为过程变量。- **赛局层：**指一次《钲鼓连烽》活动所形成的整体竞赛环境，包括活动期次、区服分组、盟营匹配、三方对战结构、城池地图、攻防规则、服务器生态和奖励配置等内容。>
|
||
**主要用于分析：**公平性、互动性、流动性等规则机制对综合投入的影响。
|
||
**机制分析按层级提变量，聚类分析按层级生成标签，后续异质性分析再把两者接起来。**
|
||
|
||
#### 分层口径与分析衔接关系
|
||
|
||
样本单位与主键口径的作用，是先在数据源头明确“个体层、团体层、赛局层”分别对应什么。这样后续机制分析、聚类分析和异质性分析才能接在同一套数据结构上。
|
||
**关系说明：**
|
||
分层口径需要在源头先统一，因为机制分析和聚类分析虽然使用的变量不同，但后续需要在同一套样本结构中衔接。- **机制分析主要回答：**哪些规则机制更可能影响综合投入？- **聚类分析主要回答：**样本中是否存在不同类型的团体或投入结构？- **异质性分析主要回答：**不同团体类型下，重点机制的表现是否存在差异？
|
||
**三者不是彼此独立的分析，而是前后衔接、最终汇合的关系：**>
|
||
机制分析 → 筛选重点机制
|
||
聚类分析 → 形成群体类型标签
|
||
异质性分析 → 将“重点机制”和“群体类型”结合起来，比较不同类型下机制表现是否不同。
|
||
|
||
#### 时间窗口口径梳理
|
||
|
||
已确认《钲鼓连烽》每两个月开放一期活动，每期活动持续三天。- **数据核心判断：**>
|
||
**3月、5月：**用于区分不同活动期次
|
||
**每期三天：**是机制发生、玩家行为投入和结果形成的主要时间范围
|
||
**机制变量：**优先使用初始窗口或早期窗口
|
||
**结果变量 K / L / Y：**主要使用三天全期累计
|
||
**排名、胜负、领奖、兑换等赛后字段：**作为后验结果处理，不进入机制变量池- **统一时间窗口：**>
|
||
**初始窗口：**活动开始前或开始时的数据。如玩家等级、VIP、战力、盟营归属、盟营初始规模等。
|
||
**早期窗口：**活动第 1 天或前 24 小时的数据。如早期攻防、早期城池变化、早期队伍调度、早期资源投入等。
|
||
**全期窗口：**活动三天累计数据，用于计算 K / L / Y 综合投入结果。
|
||
**后验窗口：**活动结束后形成的数据，如最终排名、胜负、领奖、兑换、最终结算战功和最终结算势力军威等。
|
||
第二轮数据返回后，先检查每张表是否有时间字段。有时间字段的行为日志可以切早期和全期。没有时间字段但反映活动开始状态的数据，可作为初始画像。赛后结果字段不进入机制变量池，避免结果回灌。
|
||
|
||
#### 变量角色与边界口径梳理
|
||
|
||
变量边界需要在正式提取前先统一，重点避免结果字段回灌到机制变量中，也避免聚类变量与机制主变量高度重叠，导致后续解释不清。- **机制变量：**用于解释规则机制对综合投入的影响，例如公平性、互动性、流动性、私有性、互补性、激励性、补偿性相关变量。- **结果变量：**用于衡量玩家或团体投入结果，主要包括 K / L / Y。- **控制变量：**用于控制基础差异，例如等级、VIP、战力、活动期次、服务器等。- **画像变量：**用于描述玩家、盟营或赛局基础特征，可服务于聚类和异质性分析。- **聚类变量：**用于识别不同群体类型，原则上应优先使用初始、早期或画像类变量。- **后验结果字段：**如最终排名、胜负、领奖、兑换、最终结算战功和最终结算势力军威等，不进入机制变量池。- **灰名单变量：**与机制变量或结果变量边界较近的字段，需要单独审查后再决定是否使用。
|
||
---
|
||
|
||
## 三、阶段五 SHAP 解释流程预演
|
||
|
||
今日完成阶段五 SHAP 解释流程预演。主要目的是验证阶段四已经整理好的**可建模数据表**，是否能够继续承接到阶段五的机器学习解释流程中。- **验证的链路：**
|
||
阶段四可建模数据表 → XGBoost 建模 → SHAP 解释 → 图表输出 → 解释摘要- **试跑结果：**
|
||
链路已经跑通，活动层和个体层均成功完成字段检查、模型训练、SHAP 数值计算、SHAP 图表输出和解释摘要生成，说明阶段五 SHAP 分析已经具备后续正式重跑的技术基础和输出模板。
|
||
本轮预演以**综合投入 Y**（Y_main_full_z）作为目标变量，活动层使用公平性、互动性和流动性主变量，个体层使用私有性和互补性主变量。当前预演模型中：- **活动层 SHAP 排序表现为：**>
|
||
前期攻防互动强度（Interaction_Battle_Engagement_Lag_z）
|
||
流动性集中度（liq_hhi_z）
|
||
公平性指数（Fairness_Index_z）- **个体层 SHAP 排序表现为：**>
|
||
私有收益比例（privatization_ratio_core_z）
|
||
大臣委派适配度（Complementarity_Minister_Assignment_Fit_Lag_z）
|
||
试跑是为了确认 SHAP 图表和解释流程可以正常输出，正式 SHAP 分析还要等待第二轮数据返回、变量池确认和重点机制确定后重新运行。
|
||
---
|
||
|
||
## 四、第二轮数据返回后的数据整理与口径核验
|
||
|
||
#### 全量数据资产明细整理
|
||
|
||
首先对《钲鼓连烽》相关数据进行了全量盘点。建立统一的数据资产索引，目的是先明确当前实际掌握了哪些文件、哪些表、哪些字段，以及这些字段分别来自哪里，为后续口径核验、七机制变量梳理和正式底表生成提供基础。- **整理范围包括：**>
|
||
游戏规则、埋点说明、三批返回数据、阶段四 model-ready 底表，以及阶段五 SHAP 预演相关文件。- **已形成****《钲鼓连烽_全量数据资产明细总表_v1.1》****：**>
|
||
共整理 221 个文件、254 个 Sheet、2526 个字段。
|
||
明细内容包括文件路径、数据批次、表名、字段名、字段类型、示例值、玩家 ID、活动 ID、盟营 ID、时间字段，以及 P0 / P1 需求字段返回情况等。
|
||
整理这份表的主要作用，是作为后续七机制变量梳理和正式底表生成前的字段检索入口。后续如果需要查找某个字段、判断某张表是否具备主键、确认某类补数是否返回，都可先通过该总表快速定位，减少重复查找和口径不一致的问题。
|
||
#### 口径对齐检查
|
||
|
||
在完成全量数据资产明细整理后，进一步检查这些数据后续能不能接起来使用。先判断每张表能不能和其他表对上，能不能支持后续分析。- **检查内容：**>
|
||
每张表主要记录的是玩家、盟营、队伍、城池，还是一次活动。
|
||
是否包含玩家 ID、活动 ID、盟营 ID、队伍 ID、城池 ID 等关键字段。
|
||
是否有时间字段，能不能区分活动早期、全期或赛后结果。
|
||
哪些表只是配置说明或结果榜单，不能直接当作行为数据使用。- **已形成****《钲鼓连烽_口径对齐检查表_v1.0》****：**>
|
||
主要用于检查现有数据之间是否具备合并条件，以及后续能否生成个体层、团体层和赛局层的正式分析底表。
|
||
进度：口径对齐检查已完成第一版。现在已经初步知道哪些数据可以直接对接，哪些数据还需要确认主键、时间字段或字段含义。后续应先完成重点待确认事项复核，再进入七机制分机制变量梳理和正式底表生成。
|
||
#### 待确认事项梳理
|
||
|
||
把需要确认的问题归并为 10 条母问题，主要集中在以下几个方面：>
|
||
每张表的一行数据到底代表玩家、盟营、队伍、事件还是赛局。
|
||
不同表之间能否通过 role_id、ActivityId、FactionId、TroopId、LocationId 等主键进行合并。
|
||
log_time 是否是真实行为发生时间，以及哪些表可以切初始窗口、早期窗口、全期窗口或后验窗口。
|
||
榜单、战功、旌旗、奖励、积分、排名、军威等字段到底属于过程记录还是赛后结果。
|
||
BuffId、TaskId、scene、source、OperationType 等编码字段是否有配置字典可以解释。
|
||
飞鸽、buff、任务 / 通行证、情报、扫荡奖励等数据链路是否能够闭合成完整事件链。
|
||
接下来先围绕这 10 条母问题进行集中人工确认，待 10 条母问题解决后，可以批量回填。基础数据资产表建立好后，再进入七机制分机制变量梳理、变量池更新和正式底表生成。
|
||
---
|
||
> #### 总结：
|
||
>
|
||
目前整个实证流程已经基本跑通，第二批补充数据也已经返回。接下来先集中确认 10 条母问题，完成样本单位、主键关系、时间窗口和后验字段等基础口径确认后，再进入第二轮试跑。
|
||
**相比第一轮试跑，第二轮将重点完善以下内容：**- **补齐七机制分析范围**
|
||
在原有机制基础上，重点补入**补偿性、激励性相关数据，完善七机制整体分析框架**。- **统一机制分析与聚类分析口径**
|
||
进一步明确**个体层、团体层和赛局层的样本单位**，确保机制分析、聚类分析和后续异质性分析能在同一套数据结构中衔接。- **前置考虑异质性分析衔接**
|
||
在变量整理阶段提前考虑**聚类标签、团体类型或样本分组能否回填到后续分析底表**，为后续异质性分析预留接口。- **明确时间窗口口径**
|
||
区分**初始窗口、早期窗口、全期窗口和后验窗口**，避免后续机制变量中混入赛后结果字段。- **完善正式底表生成逻辑**
|
||
在第二批数据和口径确认基础上，重新整理个体层、团体层和赛局层底表，为第二轮机制试跑和后续机器学习分析提供稳定输入。 |