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