feat(ad): 膨胀弹窗改用服务端权威金额 + 本轮累计口径,下线 signin_boost

要守住的不变量:弹窗数字 == 本轮实际到账之和 == 用户看到的余额涨幅。三者对不上,
用户就会认为少发了钱(走查现象:弹窗 240、余额只涨 40)。

- reward-result:按 ad_session_id 查本次实发金币,替代余额差 / coin_per_ad 估算。
  S2S 异步未到账返 200+pending 而非 404(404 只表示路由不存在,混在一起客户端没法
  区分「后端没部署」和「再等等」);同 session 多条时显式优先 granted——客户端先报
  closed_early、S2S 后到时,granted 反而是后写的。

- boost_round_id:客户端经 mediaExtra 透传「这条广告属于哪一轮膨胀」,穿山甲 S2S 原样
  带回后随发奖记录落库。**纯标签,不参与发奖判定**。reward-result 新增 round_coin,按
  (user_id, boost_round_id) 对 granted 记录求和。之所以由服务端求和而非客户端自己累加
  ——客户端进程被杀/重建后本地累计会丢,发奖记录不会。
  · 求和恒带 user_id:轮 id 是客户端生成的,不带就等于让任何人拿别人的轮 id 查别人发了多少。
  · 本条非 granted(capped 等)时仍返本轮累计、该条按 0 计,让限额 toast 有数可显。
  · test-grant 加可选 boost_round_id:它不经 S2S 拿不到 extra,不补则 debug 包验不了累计。
  · 客户端复用同一轮 id 只会把展示数字滚大,求和的是已发生的记录,不产生新入账,无资损。

- 下线 signin_boost(签到膨胀):它按固定 3000 金币发、与广告实际收益脱钩,产品确认从来
  不是设计内的口径——奖励只有「签到」和「看视频」两种。签到弹窗的「看广告膨胀」改与福利页
  看视频同走 reward_video(按 eCPM 公式)。摘除回调分支、POST /signin/boost、
  SigninBoostRecord、signin_boost_coin 配置,并 drop signin_boost_record 表。
  **coin_transaction.biz_type='signin_boost' 的历史流水保留不动**——钱是真发过的,账必须
  留得住;admin 大盘那两项改从金币流水统计(一次膨胀 = 一笔,与原口径等价),继续能查回历史。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
左辰勇
2026-07-20 16:55:25 +08:00
parent e9fd51d119
commit de1fd58749
32 changed files with 912 additions and 411 deletions
+10 -2
View File
@@ -15,7 +15,15 @@ GroMore 以 GET 回调,关键参数:
| `trans_id` | string | 交易号(**幂等键** + **唯一参与签名的字段** |
| `reward_name` | string | 奖励名(广告位配置,入库备注) |
| `ecpm` | string\|null | GroMore 回调携带的 eCPM。普通激励视频优先用它计算金币 |
| `extra` / `gromoreExtra` / `gromore_extra` | string | 客户端透传 JSON。支持 `ad_session_id``reward_scene`;`reward_scene=signin_boost` 表示签到膨胀 |
| `extra` / `gromoreExtra` / `gromore_extra` | string | 客户端透传 JSON。支持 `ad_session_id``reward_scene``srv_env``boost_round_id` |
### `extra` 里的 `boost_round_id`
客户端生成的「这条广告属于哪一轮膨胀」标签(32 位十六进制,同 `ad_session_id` 格式),随发奖记录存进 `ad_reward_record.boost_round_id`
**它不参与任何发奖判定** —— 发多少、发不发完全不受影响,只是让 [`/ad/reward-result`](./ad-reward-result.md) 能把同一轮的 granted 记录求和成 `round_coin`(客户端「恭喜累计获得奖励」弹窗显示的数)。
轮次边界由客户端定(只有它知道用户点没点「放弃赚钱」):点「去膨胀」新生成一个 → 点「继续看视频膨胀」复用同一个 → 点「放弃赚钱」/ ✕ / 返回 / 到每日上限 / 跨天 则丢弃。不带此字段(老客户端 / GroMore 偶发丢 extra)时存 NULL,`round_coin``null`
| `mediation_rit` | string | 代码位 IDGroMore 带,目前仅入 raw 备查) |
| `prime_rit` | string | 广告位 ID(同上) |
| `adn_name` | string | 实际出广告的 ADN 名(同上,可用于收益分析) |
@@ -40,6 +48,6 @@ GroMore 以 GET 回调,关键参数:
**发奖唯一可信入口**:验签 → 取 `user_id`/`extra` → 按 `reward_scene` 分流 → 幂等处理(按 `trans_id` 去重)。客户端不直接发奖,被破解也刷不到钱。
- `reward_scene=reward_video` 或缺省:普通激励视频。金币按 `eCPM / 1000 * eCPM因子 * 当日次数因子 * 10000` 计算;若回调没有 `ecpm`,会按 `extra.ad_session_id` 查客户端 `/ad/ecpm-report` 的上报值;两边都没有 eCPM 时不发币,记录 `status=ecpm_missing`
- `reward_scene=signin_boost`:签到膨胀。要求用户当天已签到且不是 Day14;看完视频固定发 `2000` 金币,写 `signin_boost_record``coin_transaction.biz_type=signin_boost`
- ~~`reward_scene=signin_boost`~~(签到膨胀):**2026-07 已下线**。它按固定 3000 金币发、与广告实际收益脱钩,产品确认非设计内口径。签到弹窗的「看广告膨胀」现与福利页看视频同走 `reward_video`。现在传 `signin_boost` 会落到「未知场景」分支(不发币,`status=unknown_scene`)
- 未知 `reward_scene`:不发币,记录 `status=unknown_scene`,返回 `is_verify=false/reason=1`
- 验签过但参数缺/坏或 user 不存在 → 不发(`is_verify=false` + `reason`;granted / capped / ecpm_missing / 业务不满足已记录 → `is_verify=true` + `reason=0`