金币塔、收集星星、公会宝箱、竞技场目前只有领奖/资源发放记录，无法评价效果，也无法验证任何改造是否有效。统一补齐事件链：

另需补：星星的 cycle_id、配置版本号、机器人最终得分；公会的参与、分层达标、排名移动。补齐前，这四个活动的"效果结论"缺乏数据依据；补齐后一个完整活动周期即可评价。

替换死任务"2小时4000金币"：2小时内吞噬 2,000 个大物件（单个分数≥4，对齐 40007 埋点口径）。48关门槛；当日游戏满30分钟可见解锁（锁定槽+进度条）；当日 50% 概率；奖励池68不变（天使×1+黄金卡包×1+800金币，体力5→10）。N=2,000 ≈ 目标人群自然2小时产出的 p85，预计完成率 15-22%；道具增益仅+9%，付出主体=持续投入+体力管理。调参阶梯：>25%→N=2,500；<8%→N=1,500。

定位：面向周一二低谷的"人造冲动链入口"——2小时期限制造输不起心理，加打+体力消耗把玩家推向余额压力。

• A=现槽位（周二/周四），B=周一/周二；能用 OpenFunction AB 双列按角色持久随机则优先，否则 ≥8 周 ABBA switchback；
• 按 48关+ 合格人群 ITT；周二档候选动作（收集任务 / 火山定向门票 / 糖果派对主题推广）互斥轮换、每期只测一种；
• 主指标：全周净 IAP、付费率、订单数；机制指标：复活金币/合格DAU、低余额后金币包转化、任务完成率；护栏：D1/D7 留存、退款、活动替代、产耗比。

• 充值管线加 order_id 去重 + 测试角色剔除（实测 17,818 行 → 17,786 净单）；
• 建立"活动参与事件 vs 结算到账事件"口径表并在管线中强制执行：20012（星星结算）、20014（竞技场领奖）、scene 54/58（资源发放/金币奖励）一律不得用作参与证据；
• 金币 scene 改号哨兵维持（8/7 已发生 31→63、29→64/65）。

当前证据最充分的周一杠杆：有直接参与事件、同人差异 +2.0pp、参与日在线 +32 分钟、已触达 1.6 万人。先做低成本项（入口可见性、匹配质量、场次），单独跑 A/B 而不是混进收集任务实验——否则两个动作在同一天互相污染。

按 8/14 专项审计更新（此前"落实 40→50、冠军 3000"的写法已过时）。线上事实：50 个排名节点已于 6/26 上线；冠军实发 1500 金币；服务端逻辑未随配置改动；冠军仍占获奖者 73.9%，"过易夺冠"的核心结构没变。因此要做的是：

• 修复活动结束时机器人不做最终补分的问题（夺冠过易的直接原因）；
• 产品决策：做共享真人竞争房还是个人机器人难度赛——两者数值与体验目标完全不同；
• 补 cycle_id、配置版本、机器人最终分、完整奖励日志（并入 ① 的埋点整改）；
• 付费效果单独做实验，不能由领奖数据推出。

效果目前不可判定（只有领奖埋点），但结构性机会明确：3.6k 日领奖流量、无任何主动竞争节点、高段位真实触达≈0（6 月经济分析）。方向是给它一个可观测的主动竞争节点（限时冲分窗口、失败代价、结算悬念），先做小流量实验而非全量重做。定位是"设计机会"，而非问题修复。

若要下调 49 级门槛，只能单独 A/B，不与其他动作叠加。

前置条件是 ① 的埋点整改完成。之后再谈两点权衡：解锁门槛限制覆盖；纯金币奖池与减产方向逆行（可讨论部分卡包化）。6 月经济分析曾定调"低触达高人均是其特色、不削"。

门槛读数备注：6/27 配置快照为"首过第 48 关"（Condition 211 → extra 48;1，与新手包 34 关、免广告 12 关同一编码约定，后两者已由广告需求文档独立印证）。OpenFunction id=43 是大逃杀的功能行号，不是等级门槛，两者容易混淆；线上现值仍需按当前分支复核。

夺宝是 6.4k 人的参与底盘和休闲侧配重，不要加失败代价——游戏需要一个无压力的积分长跑。火山/糖果派对是参与日在线最高的常开系统（+53/+33 分钟）但自选择最重，不靠加频次；可测形态是周一/二定向门票或入口任务（与收集任务互斥轮换），糖果派对先补进入/结果埋点。

Gold Tower, Star Collection, Guild Chest and Ranked Arena currently emit only claim / grant records, so their effect cannot be evaluated and no redesign can be validated. Complete the event chain uniformly:

Also required: Star Collection's cycle_id, config version and final bot scores; Guild participation, tier thresholds and rank movement. Until this lands, "effect conclusions" about these four lack data support; once it lands, a single full activity cycle is enough to evaluate them.

Replaces the dead "4,000 coins in 2 hours" task: swallow 2,000 large objects (individual score ≥ 4, matching the 40007 telemetry definition) within 2 hours. Level-48 gate; visibly unlocks after 30 minutes of play that day (locked slot + progress bar); 50% chance per eligible day; reward pool 68 unchanged (Angel ×1 + Gold Pack ×1 + 800 coins, Energy 5→10). N = 2,000 ≈ the p85 of the target group's natural 2-hour output, expected completion 15–22%; boosters add only +9%, so the real cost is sustained play plus energy management. Tuning ladder: >25% → N = 2,500; <8% → N = 1,500.

Role: a manufactured entry into the impulse chain aimed at the Mon/Tue trough — the 2-hour deadline creates something to lose, and extra runs plus energy drain push players toward balance pressure.

• A = current slots (Tue / Thu), B = Mon / Tue; prefer persistent per-player randomisation via the OpenFunction A/B columns, otherwise an ABBA switchback of at least 8 weeks;
• Analyse ITT on the level-48+ eligible population; Tuesday candidates (collection task / targeted Volcano ticket / Candy Party promotion) must rotate exclusively — one per period;
• Primary metrics: full-week net IAP, payer rate, order count; mechanism metrics: revive coins per eligible DAU, low-balance→coin-pack conversion, task completion; guardrails: D1/D7 retention, refunds, cross-activity substitution, faucet/sink ratio.

• Add order_id de-duplication and test-account exclusion to the payments pipeline (measured: 17,818 rows → 17,786 net orders);
• Build a "participation event vs settlement/claim event" definition table and enforce it in the pipeline: 20012 (Star settlement), 20014 (Arena claim) and scenes 54 / 58 (resource grant / coin reward) may never be used as participation evidence;
• Keep the coin scene-code sentinel in place (Aug 7 already moved 31→63 and 29→64/65).

The best-evidenced Monday lever today: it has direct participation events, a within-player difference of +2.0pp, +32 minutes online on participation days, and already reaches 16k players. Start with low-cost work (entry visibility, matchmaking quality, session count) and run it as a separate A/B rather than folding it into the collection-task test — otherwise the two actions contaminate each other on the same day.

Updated per the Aug 14 audit (the earlier wording "ship 40→50 and champion 3,000" is out of date). Live facts: the 50 ranking nodes shipped on Jun 26; the champion actually receives 1,500 coins; server logic did not change with the config; champions are still 73.9% of prize winners, so the "too easy to win" structure is intact. What is actually needed:

• Fix bots not making a final score contribution when the activity ends (the direct cause of easy championships);
• Product decision: a shared real-player room or a solo bot difficulty race — the tuning and experience goals differ completely;
• Add cycle_id, config version, final bot scores and complete reward logs (folded into ①);
• Test the spend effect separately — it cannot be inferred from claim data.

The effect is currently not assessable (claim telemetry only), but the structural opportunity is clear: 3.6k daily claim traffic, no active competitive moment at all, and real reach of high tiers ≈ 0 (June economy analysis). The direction is to give it one observable active moment (a timed scoring window, a failure cost, settlement suspense) and run a small-traffic experiment rather than a full rebuild. Frame this as a design opportunity rather than a fix.

If the level-49 gate is to be lowered, do it as a standalone A/B, never stacked with other actions.

Precondition: ① is complete. Then weigh two things: the unlock gate limits coverage, and a pure-coin prize pool runs against the faucet-reduction direction (partial card-pack conversion is worth discussing). The June economy analysis concluded "low reach, high per-player value is its character — do not cut it".

Note on the gate reading: the Jun 27 config snapshot says "first clear of level 48" (Condition 211 → extra 48;1, the same encoding convention as the starter pack at 34 and no-ads at 12, both independently confirmed by the ad spec). OpenFunction id = 43 is the Battle Royal function row number, not a level gate — the two are easy to confuse. The live value should still be re-checked against the current branch.

Treasure Hunt is a 6.4k-player participation base and the casual counterweight — do not add a failure cost; the game needs one pressure-free long-run points track. Volcano Hunt and Candy Party have the highest participation-day online time of the always-on systems (+53 / +33 minutes) but also the heaviest self-selection, so do not simply raise their frequency; the testable form is a targeted ticket or entry task on Mon/Tue (rotating exclusively with the collection task). Candy Party needs entry / result telemetry first.