Files
shaguabijia-app-server/docs/api/ad/ad-reward-result.md
T
左辰勇 de1fd58749 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>
2026-07-20 16:55:25 +08:00

3.2 KiB
Raw Blame History

GET /api/v1/ad/reward-result/{ad_session_id} — 查本次广告的权威发奖结果 + 本轮累计

客户端看完激励视频后轮询本接口,拿本次实发金币本轮累计用于「恭喜累计获得奖励」弹窗。不再用余额差 / coin_per_ad 估算。

纯只读:发奖仍只由验签过的 S2S 回调完成,本接口不写库、不产生任何奖励。按 user_id 收窄,被刷也只能查到自己的记录。

鉴权

需要 Bearer token。

路径参数

参数 类型 约束 说明
ad_session_id string 长度 8~64 本次广告会话 id,客户端生成,与 mediaExtra / ecpm-report 同值

响应

字段 类型 说明
ad_session_id string 回显请求值
status string pending(S2S 未到账,继续轮询) / granted / capped(当日超限) / ecpm_missing / closed_early(提前关闭)
coin int | null 本条实发金币。granted 为真实到账额;未发奖的状态为 0;pending 为 null
round_coin int | null 本轮累计已发金币(含本条) ← 弹窗显示的就是它
{ "ad_session_id": "3f2a9c1b7e4d8a60", "status": "granted", "coin": 20, "round_coin": 60 }

round_coin 的口径

「轮」= 用户点「去膨胀」到点「放弃赚钱」之间连看的若干条广告,边界由客户端的 boost_round_id 定(见 ad-pangle-callback)。

SELECT COALESCE(SUM(coin), 0) FROM ad_reward_record
WHERE user_id = :user_id                        -- 恒带,轮 id 是客户端生成的不可跨用户信任
  AND boost_round_id = :该会话记录的 boost_round_id
  AND status = 'granted'

由服务端求和而非客户端自己累加:客户端进程被杀 / 低内存重建后本地累计会丢,发奖记录不会。

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

情形 round_coin
本条 granted 本轮累计(含本条)
本条 capped / closed_early / ecpm_missing 仍返本轮累计,该条按 0 计(撞上限那下的 toast 要能显示前几条的总额,不能是空)
status=pending(没记录) null —— 连属于哪一轮都不知道。不是 00 会被读成「本轮没赚到」
该记录没有 boost_round_id(老客户端 / extra 丢失) null,客户端退回只显示单条 coin

错误

  • 401: 未登录
  • 422: ad_session_id 长度不在 8~64

查不到记录不返 404,而是 200 + status="pending"。404 只应表示路由不存在;两者混在一起客户端没法区分「后端没部署」和「再等等」。

实现注意

同一 ad_session_id 可能有多条记录,取值时显式优先 granted,不能只取最近一条:

  • 客户端先报 closed_early、S2S 随后姗姗来迟 → 两条,granted 反而是后写的
  • 本地联调重复调 test-grant → 同 session 多条 grantedtrans_id 各不相同)

都没有 granted 才取最近一条,让客户端知道没发的原因。