You've already forked Commercialization.tapadn
Add TapADN smart preload attribution
This commit is contained in:
@@ -6,7 +6,10 @@
|
||||
|
||||
但不能把 TapADN 的 auto 与 TopOn 的全自动加载视为同一种能力。TopOn 的 auto 是一套更完整的广告位请求维护方案，包含广告位注册、真实 ready 查询、场景进入统计、缓存状态统计和自动续载；TapADN 当前 Unity wrapper 暴露的是“加载 + 展示合并”的 auto show API，没有看到类似 `entryAutoAdScenarioWithPlacementID` 的场景入口，也没有看到 auto ready 查询 API。
|
||||
|
||||
因此，生产默认策略建议调整为“激励视频可优先 auto，但插屏和开屏建议默认手动或由项目配置显式开启 auto”。如果为了兼容当前模块和快速调试继续保留 auto 默认值，也应该在正式项目配置里显式写清楚每个广告类型的选择，避免项目层误以为 `IsReadly()` 表示真实填充可展示。
|
||||
因此，生产默认策略建议改为“默认全部手动”，并保留每类广告的开关用于分场景 AB。原因是：
|
||||
|
||||
* 当前 `AsyncAdPlayer` 已经承载了 ready/load/show 的生命周期统一，手动模式更能把回调和失败收口稳定在框架层。
|
||||
* 上层仍会调用 `ADManager.EnterAdScenario(...)`，这更适合我们把策略判断放到“场景上”，而不是让 SDK 的 auto 接口替代场景决策。
|
||||
|
||||
## 问题定义
|
||||
|
||||
@@ -20,9 +23,9 @@
|
||||
|
||||
当前模块默认配置位于 `Assets/Tapadn_Adapter/Runtime/Scripts/TapadnControllerOptions.cs`：
|
||||
|
||||
* `RewardedAutoLoad = true`
|
||||
* `InterstitialAutoLoad = true`
|
||||
* `SplashAutoLoad = true`
|
||||
* `RewardedAutoLoad = false`
|
||||
* `InterstitialAutoLoad = false`
|
||||
* `SplashAutoLoad = false`
|
||||
* `RewardedPrewarmOnInit`、`InterstitialPrewarmOnInit`、`SplashPrewarmOnInit` 默认为 `false`
|
||||
|
||||
三个播放器的 auto 分支行为如下：
|
||||
@@ -77,8 +80,8 @@ TapADN / Dirichlet Unity 文档对 auto 的描述主要是“加载和展示合
|
||||
建议在生产项目里按如下方式显式配置：
|
||||
|
||||
```text
|
||||
tapadn.rewarded_auto_load=true
|
||||
tapadn.rewarded_prewarm_on_init=true 或在进入高概率广告场景前主动 LoadAD
|
||||
tapadn.rewarded_auto_load=false
|
||||
tapadn.rewarded_prewarm_on_init=false （建议改用入口驱动的手动 preload）
|
||||
|
||||
tapadn.interstitial_auto_load=false
|
||||
tapadn.interstitial_prewarm_on_init=false
|
||||
@@ -87,7 +90,7 @@ tapadn.splash_auto_load=false
|
||||
tapadn.splash_prewarm_on_init=false
|
||||
```
|
||||
|
||||
如果项目追求快速接入、广告位较少、可以接受展示时等待，则可以短期保持当前三类 auto 默认开启。但正式灰度前至少应完成以下验证：
|
||||
如果你想走“上层智能策略”也可以让默认逻辑保持上面的配置，再在高概率收益场景按策略临时开 auto 进行实验。必须完成以下验证：
|
||||
|
||||
* auto 模式下点击激励按钮到 `OnAdShow` 的延迟分布。
|
||||
* auto 模式下 show fail、load fail、close、reward verify 是否都被 `ADManager` 收口。
|
||||
@@ -95,6 +98,42 @@ tapadn.splash_prewarm_on_init=false
|
||||
* 开屏失败或无填充时是否能按产品要求进入主场景。
|
||||
* 每个业务广告场景是否有自己的埋点、频控和远程配置。
|
||||
|
||||
## 内部智能策略建议（结合场景声明）
|
||||
|
||||
上层仍然在 `ADManager.EnterAdScenario(adType, scenario)` 里会声明场景，这个入口可以成为 TapADN 的控制平面。建议用一个本地策略层（或接入现有 remote config）来替代“固定 auto 默认”。核心规则建议:
|
||||
|
||||
* 入场闸门：新手 / 首次会话内降低开屏和插屏频率，设置较长冷却。
|
||||
* 价值分层：`resume_continue`、`revive`、`double_reward`、`level_complete`、`session_end` 使用不同触发阈值。
|
||||
* 预算分发：按场景给定每小时/每日展示配额，按最近 N 次 fill 成功率和关闭率动态降权。
|
||||
* 失败避障：对连续 fail 场景计入惩罚分，自动降级到手动模式或延后下一次尝试。
|
||||
* 回落路径：场景声明后可先触发预加载（手动），再在 `AsyncPlayAD` 时做 ready 判断，避免 show 时阻塞。
|
||||
|
||||
### 实战落地推荐（先做这 4 件）
|
||||
|
||||
为了先上线再迭代，这版实验建议按下面节奏推进（先保守后扩展）：
|
||||
|
||||
1. 先做“是否预加载”二分类决策
|
||||
- 输入：场景进入次数 / 播放请求次数 / 最近一次更新距今时长
|
||||
- 输出：`preload_score` 与 `cooldown`
|
||||
- 初始阈值：`score >= threshold && cooldown 过期`
|
||||
|
||||
2. 再加“场景独立配置表”
|
||||
- 默认配置放在 `TapadnSmartLoadPolicy_Default.json`（本地资源表）
|
||||
- 支持服务端覆盖配置（`tapadn.smart_preload_remote_json`）
|
||||
- 场景命中优先、无命中回退到该位 default
|
||||
|
||||
3. 建立在线反馈回路（每 1~3 天可更新）
|
||||
- `enter_count` / `play_request_count` + `fill 成功率`
|
||||
- `show_success - close 率` 作为质量约束（用于上调/下调阈值）
|
||||
|
||||
4. 降噪与退化
|
||||
- 连续低效场景自动降 `threshold`、拉长 `cooldown`
|
||||
- 连续高效场景适当提高预加载优先级
|
||||
|
||||
这样比“固定 always auto”更安全：能先守住体验（手动 show 生命周期），再逐步把预加载放到高价值场景。
|
||||
|
||||
这样我们保持框架语义：`AsyncAdPlayer` 负责生命周期和回调收口，场景策略只负责“该不该、何时、给谁”。
|
||||
|
||||
## 当前实现评价
|
||||
|
||||
当前 TapADN auto 接入本身是合规且完整的 API 级接入，但默认策略偏激进。它适合样例工程、快速调试和 Android 单平台验证；对于正式 IAA 游戏商业化，建议把默认认知改成：
|
||||
@@ -119,3 +158,26 @@ tapadn.splash_prewarm_on_init=false
|
||||
* [Google AdMob recommended interstitial implementations](https://support.google.com/admob/answer/6201350?hl=en)
|
||||
* [Google AdMob frequency capping](https://support.google.com/admob/answer/6244508?hl=en)
|
||||
* [Unity LevelPlay placement best practices](https://docs.unity.com/grow/levelplay/platform/best-practices/placement)
|
||||
|
||||
## 仿真验收输出（新增）
|
||||
|
||||
为便于快速比较 `threshold / cooldown` 对用户体验与 waste 的影响，本模块附带一套敏感度脚本产物，默认次留目标为 35%：
|
||||
|
||||
- 报告：`Tools/SmartLoadSensitivity/output/TapADN_智能预加载_敏感度验收报告.md`
|
||||
- 明细 CSV：`Tools/SmartLoadSensitivity/output/smartload_sensitivity_summary.csv`
|
||||
- 排名 CSV：`Tools/SmartLoadSensitivity/output/smartload_retention_rank.csv`
|
||||
- 图表：`Tools/SmartLoadSensitivity/output/*.png`
|
||||
|
||||
常用可视化入口（打开仓库根目录）：
|
||||
|
||||
- [热力图（35%次留）](Tools/SmartLoadSensitivity/output/heatmap_immediate_r_0.35.png)
|
||||
- [平均时延（35%次留）](Tools/SmartLoadSensitivity/output/heatmap_wait_ms_r_0.35.png)
|
||||
- [Waste 热力图（35%次留）](Tools/SmartLoadSensitivity/output/heatmap_waste_ratio_r_0.35.png)
|
||||
- [留存变化线（即时性）](Tools/SmartLoadSensitivity/output/line_immediate_vs_retention.png)
|
||||
- [留存变化线（时延）](Tools/SmartLoadSensitivity/output/line_wait_vs_retention.png)
|
||||
|
||||
脚本运行命令：
|
||||
|
||||
```bash
|
||||
python Tools/SmartLoadSensitivity/smartload_sensitivity_simulation.py --users 5000 --out-dir Tools/SmartLoadSensitivity/output
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user