干小程序生态这几年有一个绕不开的组合拳就是“激励视频积分抽奖”。这三个东西单拎出来都不稀奇但串成一个闭环之后它就是一套很典型的小程序变现模型用户看广告获得积分积分驱动抽奖抽奖带来的奖励预期又反过来刺激用户继续看广告。我最近正好在维护一个开源的多端小程序项目做的就是这件事——看广告激励视频、积分大转盘抽奖、广告流量主变现一套代码同时跑微信、抖音、快手三个平台。这个项目用 uni-app 开发服务端用 Java 或者 Node 都能接前端整体源码是开源的拿来改改就能上线。这篇文章就把这个项目的核心结构、积分体系的设计逻辑、激励视频广告的接入方式、流量主收益的优化思路以及我在实际跑项目时踩过的坑一并整理出来。适合三类人看一是刚接触小程序广告变现、想快速搞一个MVP的开发者二是手里已有小程序但日活上不去、想换种玩法提升留存的产品/运营三是想研究 uni-app 多端适配、特别是抖音快手这些非微信平台广告接口差异的工程师。代码层面的示例我会尽量用贴出来的方式讲清楚不贴能跑的完整源码但会讲明白每一块为什么这么设计。1. 项目定位与整体设计思路1.1 激励视频广告如何形成变现闭环先把这个模型的逻辑链条理顺。很多人以为流量主变现就是“挂个 banner 广告位等点击”那是入门玩法收益低体验也差。激励视频的本质是“用户主动用时间换权益”它跟抽奖玩法结合之后逻辑就变成了用户每天有固定的抽奖次数比如 3 次免费次数。次数用光了想继续抽就得看一条 30 秒的激励视频看完之后平台广告系统回调一个“播放完成”的事件小程序拿到这个回调后给用户发积分或者直接补一次抽奖机会。用户抽中了积分、优惠券、实物奖品就会有种“赚到了”的心理第二天还会回来继续玩。广告主那边付出了广告费平台分成给开发者开发者的收益来自每一次用户主动观看。这个闭环里最关键的两个字是“主动”。用户不是为了看广告而看广告而是为了抽奖才看。所以整个过程用户不反感广告的填充率和完播率也会比被动展示高很多。1.2 技术选型为什么用 uni-app 而不是原生开发这个项目最开始的版本是微信小程序原生开发的跑通之后发现两个问题第一微信小程序的代码没法直接搬到抖音和快手抖音的tt.createRewardedVideoAd、快手的ks.createRewardedVideoAd和微信的wx.createRewardedVideoAd都是各自的 API虽然长得像但返回的事件名、参数细节都有差异第二维护三套原生代码的人力成本对一个开源项目来说太高了。所以后来整体重构换成了 uni-app。uniapp 在编译层面帮我们统一了生命周期、页面路由和组件语法广告这块虽然不能完全靠一套代码跑通但可以用条件编译把平台差异隔离起来——同一份代码微信端走wx.createRewardedVideoAd抖音端走tt.createRewardedVideoAd快手端走ks.createRewardedVideoAd业务逻辑不用改只替换最底层的广告封装层。这种方案的好处是业务代码积分、抽奖、用户中心全平台复用只有广告适配层和支付/登录等涉及平台能力的模块需要写条件编译。坏处也明显——每次微信更新广告组件你得检查另外两个平台有没有跟着变。实测下来抖音和快手的 API 演进速度比微信快微信经常加新参数比如multiton多实例抖音那边 API 相对更稳定。1.3 项目功能模块划分整个项目从前端到后端可以拆成这么几块模块职责说明登录授权微信/抖音/快手静默登录抖音和微信的静默登录逻辑一致快手稍特殊积分系统积分发放、消费、流水记录看广告加积分、抽奖扣积分、签到送积分抽奖模块大转盘前端动画、概率配置、奖品发放转盘角度计算、奖品库存扣减广告模块激励视频加载、播放、回调封装平台差异集中在这一层用户中心积分余额、抽奖记录、奖品列表列表页、详情页埋点统计广告点击、播放完成、抽奖行为用于复盘 eCPM 和留存后端方面开源仓库里给的是简易版——Node.js 或者 Java 任选数据库用的 MySQL缓存可以用 Redis。积分账户有一个独立的表所有积分变动都走流水表设计这个表结构的时候我特意加了biz_type字段区分是“看广告获得”还是“抽奖消耗”。后面查账、对账、防刷都靠这个字段。2. 大转盘抽奖玩法与积分体系设计2.1 大转盘的前端交互和动画实现大转盘这玩意儿玩法核心就是“转”前端交互的核心也就是“转动动画”。真正写起来比想象中要复杂点的地方在于转盘的格子数是不固定的常见的有 6 格、8 格、10 格、12 格格数一变每个扇区的角度就不一样动画的落点计算也跟着变。这个项目用的是 Canvas 绘制转盘而不是 CSS 拼扇形。原因有两个一是 Canvas 在高分屏下可以做到无级缩放图片和文字不会模糊二是转盘的奖品图片、背景图片一般都是运营上传的Canvas 动态绘制可以灵活处理数量和布局不用每次改图都动代码。动画部分用的是 CSS 过渡 JavaScript 控制角度。具体做法是先把转盘初始位置设在一个固定角度比如 0 度。用户点击抽奖后前端先请求后端接口后端根据概率算法算出中奖的奖品索引。前端根据奖品索引计算最终落点角度然后在一个 360 度范围内叠加基准圈数转 4 到 6 圈让转盘既有“猛转了好几圈”的感觉又能准确落在奖品扇区的中间。用 CSStransition: transform 4s cubic-bezier(0.2, 0.8, 0.2, 1)这个缓动函数让转盘先加速后减速最后稳稳停住。这里有个细节容易出错如果奖品顺序是顺时针排列的奖品索引 0 在顶部那计算落点角度的时候要考虑“从当前角度到目标角度”的差值而不是直接把目标角度设成当前的 transform 值。我吃过亏最开始的版本是让转盘每次都从 0 度开始转转到目标角度结果用户连抽几次后发现转盘“跳回起点”体验很差。后来改成了“在现有角度基础上累加圈数”才解决了这个问题。2.2 积分发放规则与防刷策略积分体系是这个项目的造血系统。太抠了用户没动力看广告太松了你会被刷破产。我实际跑的规则是新用户注册送 100 积分当天立即送刺激首抽。每日签到送 10 积分连续签到 7 天额外送 50 积分断签重新算。看完激励视频奖励 20 积分每个用户每天最多通过看广告获得 300 积分。抽奖一次消耗 30 积分每天前 3 次抽奖免积分用免费的抽奖机会。积分余额不设上限但超过 10000 积分后每天看广告获得的积分减半。这个设计是为了抑制“羊毛党”——他们刷积分的动力远大于普通用户如果不限制一个刷子号一天能贡献几百次广告播放但广告主结算时会对异常流量拒付。防刷方面后端在发放积分时做了三层校验频率控制同一个openid在同一分钟内最多成功回调 1 次广告播放完成事件超过就丢弃。时长校验前端播放广告会传一个watch_seconds字段后端校验这个值必须在 15 到 60 秒之间。太短说明是模拟器或者截图伪造的太长可能是挂机脚本。上下文校验广告播放的触发必须带一个scene_id比如ad_draw表示从抽奖页面触发、ad_sign表示从签到页触发。后端要校验这个场景确实存在且是合法入口。注意积分流水表有两个字段change_type积分变动类型和scene_id触发场景排查异常的时候这两个字段配合最有用。凡是change_typead但scene_id为空或者乱传的请求直接判为异常。2.3 中奖概率和奖品配比设计大转盘的中奖概率不是前端写死的前端只负责转盘转完后的动画展示和结果弹窗真正的概率计算在后端。为什么要放后端因为前端如果写死概率稍微懂点技术的人改一下内存变量或者请求参数就能中奖后端控概率才能保证奖品成本可控。奖品类型分为三类积分这个消耗成本最低出现的概率最高可以作为“保底奖品”。实物/虚拟奖品比如优惠券、小额红包、定制周边概率中等需要控制库存。谢谢参与这个要控制在一个合理的区间太高了用户挫败感强第二天不来了。我推荐的概率结构长这样8 格转盘参考奖品概率说明谢谢参与30%保底体验配合“再看一次”引导5 积分25%回本型奖品让用户觉得不亏10 积分15%小额激励15 积分10%中等额度50 积分8%大奖概率低但要有优惠券7%拉活线下/商城实物奖品3%拉新利器控制预算神秘大奖2%噱头可以放高价值低库存这个比例不是等概率的——注意看积分概率加起来占了 58%这是故意设计的。因为抽奖的核心目的是让用户“持续有盼头”如果大部分抽奖结果是“谢谢参与”用户会觉得自己被耍了这是大转盘留存崩掉的第一大原因。后端需要有一个库存控制器每个奖品在配置表里都设了total_inventory和daily_quota。特别是实物类奖品不能无限发一旦每日配额用完后端在抽奖时会把该奖品的概率临时归零并把概率权重按比例分给其他奖品这样前端动画显示的奖品和最终结果永远一致。后端概率抽奖的实现逻辑如下int randomVal ThreadLocalRandom.current().nextInt(1, 101); int cumulative 0; for (Prize prize : prizeList) { cumulative prize.getProbability(); if (randomVal cumulative) { return prize; } } return defaultPrize;这段代码的原理很简单——把 1 到 100 的区间按概率权重切分随机数落在哪一段就中哪个奖。真正要注意的是奖品列表的顺序要稳定否则每次请求顺序变了哪怕概率不变抽奖分布也会出现波动。我习惯把概率大的奖品放在列表后面这样 random 值小时先命中低概率奖品分布更均匀。3. 激励视频广告接入的完整实操3.1 微信小程序激励视频广告接入流程微信端的激励视频广告是这几家里文档最全的但也是最容易出问题的。接入时核心代码是创建广告实例、监听回调、展示广告三步。export function createRewardedAd() { const ad wx.createRewardedVideoAd({ adUnitId: adunit-xxxxxx, multiton: false }) let onClosePromise null // 用来包装广告回调 ad.onError(err { console.error(激励视频广告加载失败:, err.errCode, err.errMsg) }) ad.onClose(res { if (onClosePromise) { onClosePromise(res) onClosePromise null } }) return { show() { // 加载和显示相互独立要分别处理 return new Promise((resolve, reject) { onClosePromise resolve ad.show().catch(err { // show失败一般是因为广告还没加载好先load再show ad.load().then(() ad.show()).catch(loadErr { reject(loadErr) }) }) }) } } }这个封装有一个关键点ad.onClose回调里的res对象带一个isEnded字段true表示用户完整看完视频false表示中途退出。积分发放必须只在isEnded true时触发绝不能只看 onClose 就发积分。踩坑提示微信的激励视频组件在部分安卓机型上有一个“广告加载失败后没有任何回调”的历史 bug。处理方式是给load()方法加一个超时定时器超过 5 秒没返回就重新创建实例。虽然官方文档没提这事但实测某些低端安卓机上load()返回的 Promise 会一直 pending不做超时处理用户就会被卡死。3.2 抖音和快手平台的广告差异适配抖音端的接口跟微信高度相似主要差异点是创建广告实例的方法从wx换成了tt且支持同一个广告位创建多个实例。快手的差异相对大点ks.createRewardedVideoAd的 onClose 回调返回的参数结构跟微信不完全一致而且快手要求先调用ad.load()成功后才能ad.show()不像微信可以在 show 失败后再 load。uniapp 里处理这种差异用的是条件编译// #ifdef MP-WEIXIN import { createRewardedAd } from /platform/weixin/ad // #endif // #ifdef MP-TOUTIAO import { createRewardedAd } from /platform/toutiao/ad // #endif // #ifdef MP-KUAISHOU import { createRewardedAd } from /platform/kuaishou/ad // #endif每个平台的实现文件内部 API 完全不同但对外暴露的方法名保持一致init、show、onEnded。这样业务层和广告层完全解耦抽奖页面永远只调用ad.show()根本不关心底层运行在哪个平台。抖音端还有一个特殊点抖音小程序的流量主后台不给测试广告位只能在开发工具里直接调用假广告。测试代码得用平台自带的tt.preview或者实时真机调试没法像微信那样在开发者工具里模拟广告。3.3 广告实例的生命周期管理很多开发者在“广告实例要用一个还是多个”这个问题上纠结。我的结论是抽奖页面建议使用单例不要频繁创建销毁。原因是广告实例每次创建都会触发一次网络请求频繁创建会导致广告加载失败率上升而且部分平台的广告组件有并发上限。单例模式就是页面初始化时创建一次广告实例之后每次都复用同一个。不过要注意微信后来加了multiton参数含义是允许多个广告实例并存如果用了单例multiton必须设为false。广告实例的加载时机也值得一说。用户进入抽奖页面后前 3 次抽奖是免费的不需要看广告。等用户点“再看一次去抽奖”的时候才开始load()广告。更精细的做法是用户点击转盘按钮的一瞬间就预加载广告等用户确认“愿意看广告换次数”时广告已经加载好了show 的时候几乎没有等待时间。广告预加载的完整流程拆解一下进入抽奖页面 - 创建广告实例 - 立即 load() 用户点击“看广告抽奖” - 检查 loaded 状态 - 已加载: 直接 show() - 未加载: 先 load() 再 show() 播放完成 - 回调 isEnded - 发积分/更新抽奖次数3.4 广告回调与积分发放的时序处理广告回调是异步的积分接口和前端页面状态更新也是异步的这里最容易出现“用户看了广告但积分没到账”的纠纷。我在项目里加了一个“本地状态 服务端补偿”的双保险机制用户点击看广告时前端先本地记录pendingAdReward true。广告播放完成回调触发后前端调用后端接口POST /api/reward/ad-complete带上openid、adUnitId、sceneId、deviceId。后端校验通过后返回新的积分余额前端再更新界面。如果接口调用失败网络抖动前端本地保留pendingAdReward标记等用户下次进入页面时自动重试后端也有一个补偿 Job定时扫描流水表中statuspending的记录补发积分。这个设计确实会增加一点开发量但对于广告变现类小程序来说值得做。用户是冲着积分来的积分没到账的口碑风险远比多写几个接口高。4. 流量主开通与收益优化策略4.1 各平台流量主开通条件对比流量主功能不是注册就能开的各平台都有门槛。平台开通条件分成比例结算周期微信小程序累计独立访客UV1000 以上广告收入平台与开发者 5:5 分成每月结算抖音小程序暂未完全开放需满足类目与质量要求以平台规则为准每月结算快手小程序开发者实名认证小程序通过审核后申请以平台规则为准每月结算微信端的门槛是最明确的1000 UV 看着不高但对新项目来说冷启动还是有点费劲。所以开源项目里我额外做了“邀请有奖”和“每日签到”两个小功能都是用来拉初始流量的。签到的目的不是做留存而是尽早把日活和访客数顶上去把流量主权限解锁。有个很容易被忽略的点开通流量主之后小程序后台会要求设置“广告内容合规”相关选项。广告内容的分类、屏蔽策略建议尽早配置否则万一出现一些不适合的广告内容被用户投诉后会影响账号状态。4.2 激励视频的 eCPM 影响因素eCPM千次展示收益是衡量广告变现效率的核心指标。很多人以为是广告平台决定的实际上小程序的页面设计、广告触发场景对这个指标的影响非常大。影响 eCPM 的关键因素我排个序用户画像新用户、年轻用户、一二线城市用户的 eCPM 显著高于低活跃回访用户。这个没法短时间改变但可以做精细化运营——把激励视频入口放在“完成任务后的奖励领取页”让新用户更容易触达。广告完整播放率如果用户看了 2 秒就退出平台会判定这个广告位质量差连续几次后会降低广告填充率。所以激励视频入口的诱导文案一定要让用户做好心理预期不能打着“抽奖”的名义点进去却让用户看广告。广告场景匹配度平台的广告系统会分析小程序的内容属性如果你的小程序类目是“休闲娱乐”那它给你推的游戏类广告 eCPM 就高如果你选了“工具”类目广告类型和内容不匹配eCPM 会明显偏低。广告位复用频率同一个广告位在同一次会话内反复展示eCPM 会逐次降低。我建议同一个广告位每天每个用户最多触发 15 次超过后换成页面底部 banner不是心疼用户体验是广告主不愿意为高频失效流量买单。4.3 提升广告观看量与用户留存的几个实操技巧光有广告位不行得有人看。提升广告观看量最直接的办法是调整抽奖的“免费次数”和“看广告补次数”的比例。我试过几种方案免费 1 次 看广告补 4 次风险是用户抽完 1 次觉得意犹未尽看广告的动力最足但整体广告量有限。免费 3 次 看广告补 3 次这是平衡方案既保证新手前 3 次抽奖的良好体验又保留广告补偿的空间。免费 5 次 看广告无限次用户前 5 次已经来过瘾了后面看广告的意愿明显下降。实测这种方式的总广告播放量还不如方案二。最终我选了方案二然后在这一层基础上优化诱导文案。按钮文案不要写“看广告获得抽奖次数”而是写“再赚 1 次机会”。行为心理学上“获得新机会”的驱动力远大于“为了看广告而看广告”。另外每日签到的奖励也跟广告联动签到第 3 天和第 7 天用户点击领取奖励时先弹一个激励视频广告看完才能获得额外签到礼包。这不算强制因为正常签到积分还是能领额外礼包是增量收益用户抵触感不大。4.4 抽奖运营活动节奏开源版本里我加了一个后端配置接口可以动态配置每天的“转盘活动场次”。比如周末开启“双倍积分场”转盘的奖品配比自动换成高积分版本。这么做的好处是把抽奖从“日常功能”变成“运营活动”用户有“错过就亏了”的心理周末的活跃度能拉高一截。这个 playground 字段里我推荐把“神秘大奖”和“谢谢参与”的比例做成动态的工作日“谢谢参与”高一点、大奖概率低一点控制成本周末反过来大奖概率调高吸引用户周末回来玩。真实用户不是傻瓜连续抽了三天全是“谢谢参与”他第二天不会再来。偶尔让他小中一次他才愿意继续为下一次大奖养积分。5. 多端适配与常见问题排查实录5.1 广告组件显示异常加载失败、白屏、点击无效这一类问题在真机上最常出现开发工具里反而一切正常。我整理过一份排查顺序清单先看广告位 ID 是否填对。很多人把测试广告位的 ID 直接搬到正式环境微信平台通常会给个错误码抖音平台可能会异常回调但不会提示你填错了。确认adUnitId是否已经绑定到当前小程序 AppID 下。广告位是新后台申请的如果小程序版本跟广告位版本不一致校验也会失败。检查广告组件是否在主包或者已加载分包中。小程序分包加载时广告组件如果从分包里注册部分平台会出现资源路径错误广告直接不渲染。看广告实例是否被重复创建。频繁createRewardedVideoAd在低端安卓机上会导致前几个实例处于未释放状态新的实例加载失败。确认网络请求没被代理工具拦截。Charles、Fiddler 这类抓包工具会导致部分 HTTPS 请求失败广告 SDK 的请求如果走代理出现了证书问题广告自然加载不出来。实际开发中广告加载失败的比例控制在 5% 以内是正常的超过 10% 就需要重视了。我加了一个简单的统计上报每次ad.onError或者ad.load().catch都记一条日志后端聚合之后一天看一次很容易发现是单机问题还是平台整体故障。5.2 uniapp 多端编译差异与条件编译陷阱uniapp 虽然统一了大部分 API但细碎的坑还是不少。最经典的wx.showToast、tt.showToast、ks.showToast都能用但tt.showToast不支持icon: none之外的图标类型默认的图标在抖音端显示不出来。如果你写了通用组件调uni.showToast在抖音端可能有个延迟才显示。条件编译也有坑。我在项目里定义平台适配文件时最初把createRewardedAd放进了同一个文件用if (typeof wx ! undefined)去判断平台。这在微信端没问题但编译到抖音端时uniapp 的 tree-shaking 可能把wx相关的分支也保留下来导致抖音端代码里直接出现wx.createRewardedVideoAd运行时报wx is not defined。正确做法是彻底的平台文件隔离src/platform/ weixin/ad.js // 微信广告封装 toutiao/ad.js // 抖音广告封装 kuaishou/ad.js // 快手广告封装 index.js // 条件编译导出统一入口导出文件里用#ifdef包裹 import 语句确保编译时只打包当前平台的代码绝不靠运行时判断。这个原则对所有原生 API 都成立不光是广告模块。5.3 积分异常与并发扣减问题积分扣减和发放涉及并发最容易出现的经典 bug 是用户连续几次快速抽奖前端发了 5 个并发请求后端如果没做行锁或者乐观锁用户积分就被扣成负数了。解决方式有几种最简单的是数据库行锁积分账户表加一行UPDATE account SET balance balance - cost WHERE openid ? AND balance cost让数据库保证余额充足才扣减。更稳健的做法是加 Redis 分布式锁每个用户的积分操作都走SETNX lock:包一下。考虑到开源项目要容易部署我目前用的是 MySQL 的行锁方案在高并发下也能跑得不错。如果是日活几十万的项目再换 Redis 锁也不迟。还有一类“积分凭空增加”的问题通常是接口被直接调用刷积分。这种攻击的典型特征是调用频率高、单 IP 聚集、参数固定。我在网关层做了一道校验所有涉及积分变动的接口都必须带一个 30 分钟内有效的 token这个 token 由登录接口下发核对了 openid 和会话状态能挡掉一大半的脚本攻击。5.4 审核被拒的常见原因与规避小程序审核这个环节微信最严格抖音次之快手相对宽松。因为项目涉及抽奖和广告有几个坑特别容易踩诱导分享转盘活动中不要出现“分享给好友可获得额外抽奖机会”这种文案。微信明确禁止小程序内的抽奖活动强制分享才能继续。如果想做分享拉新改成“分享后好友打开页面分享者获得积分”要确保不是强制路径。概率说明不透明涉及抽奖类功能审核会要求页面展示奖品概率。开源项目的前端我已经默认加了一个“活动规则”弹窗里面明确列出每个奖品的概率和奖品总数。这个弹窗对审核通过率影响很大不能省。隐私协议缺失激励视频广告涉及设备信息、位置信息的上报小程序必须配置用户隐私保护指引声明采集和使用哪些信息。微信从某次更新之后隐私协议缺失直接审核不过这是最高频的驳回原因。诱导点击广告页面不能出现“点击广告赚积分”之类的文案这类诱导在审核时属于违规。正确的表述是“观看视频解锁机会”重点描述用户的主动行为不能直接要求用户点击广告。抖音端审核还有一个特例抖音对“诱导看广告”的限制比微信更严格文案上最好不要直接出现“广告”两个字用“解锁”或者“获取额外机会”更安全。6. 开源项目的目录结构与二次开发建议6.1 前端源码目录结构开源项目的前端部分是基于 uni-app 的 Vue3 版本构建的核心目录结构长这样src/ pages/ index/ // 首页签到入口 抽奖入口 积分展示 draw/ // 抽奖页大转盘核心 mine/ // 我的积分记录、中奖记录、奖品列表 login/ // 登录页 components/ draw-wheel/ // 大转盘组件Canvas ad-button/ // 广告触发按钮 prize-modal/ // 中奖弹窗 sign-in/ // 签到组件 platform/ weixin/ad.js // 微信激励视频适配 toutiao/ad.js // 抖音激励视频适配 kuaishou/ad.js // 快手激励视频适配 utils/ request.js // 统一请求封装 auth.js // 登录与 token 管理 probability.js // 概率计算工具前端展示用 config/ index.js // 平台配置、广告位ID配置二次开发的时候最优先改的是config/index.js里的广告位 ID 和 API 地址。这两个配置集中放避免上线时到处找代码替换。6.2 后端接口核心约定后端不限定语言我仓库里给的是 Java Spring Boot 版本也有 Node 版本的分支核心接口约定如下接口方法说明/api/auth/loginPOST静默登录传入code返回token和学生信息/api/reward/signPOST每日签到发放签到积分/api/reward/ad-completePOST广告播放完成回调发放广告积分/api/draw/startPOST抽奖接口扣积分/次数返回奖品结果/api/draw/recordsGET抽奖记录分页查询/api/prize/listGET奖品列表与概率配置前端转盘用后端积分变动的核心原则是“所有变动都走流水表禁止直接改 balance”。哪怕是管理员后台手动补积分也要先插入流水再更新余额。跟进账目排查的时候流水表就是唯一的真相来源。6.3 从零搭建一套演示环境的步骤如果你想快速把项目跑起来看看效果流程大概是这样的克隆仓库前端打开 HBuilderX 或者 VS Code用 uni-app 插件导入项目。后端启动 Java 服务MySQL 执行sql/init.sql建库建表改后端配置文件里的数据库连接。在微信开发者工具里导入前端项目AppID 填自己小程序的打开“不校验合法域名”选项本地调试用。广告位那一步如果尚未开通流量主平台没有正式广告位 ID先用测试广告位顶替。微信的测试广告位 ID 是固定的adunit-xxxxxxxx官方文档里有。如果不想立即接入真实广告可以在适配层直接 mock 一个“播放完成”的假回调先把积分和抽奖流程打通。我自己常用的调试顺序是先 mock 广告回调验证玩法闭环再接入真实广告位验证收益链路。这样每一步出问题都容易定位不会混在一起瞎猜。6.4 二次开发的几个扩展方向这个开源架子做出来后后续要加东西是很顺手的。几个实际的扩展方向加任务系统看完广告得积分太直白了可以升级成“完成连续 3 日签到”、“累计观看 10 条激励视频”等任务完成任务额外发大奖广告观看量会明显上升。加排行榜积分排行榜可以刺激部分用户“冲榜”配合周末双倍积分场活跃度提升明显。注意排行榜只能按“累计获得积分”排不能按“当前余额”排否则用户把钱花光了就不玩了。加分销/邀请机制新用户通过老用户分享链接进入小程序老用户获得广告积分奖励。这个小功能拉新效果很强但要注意微信的分享审核要求。接入订阅消息当用户中奖实物奖品后通过订阅消息通知用户填写收货地址。这个能显著提升奖品的核销率也减少客服咨询量。7. 写在最后的几点实操心得这个项目从立项到开源前前后后改了四版。最大的体会是激励视频广告变现的玩法本身不复杂复杂的是怎么把“用户看广告”这件事包装得让用户不反感同时还能保证平台的额度和自己的收益。最让我意外的数据是“跳转消耗”和“签到联动”这两个小细节带来的收益差距。一开始我直接把“看广告 抽奖”做成一个按钮用户点一次看一条广告抽一次奖数据看起来平稳后来改成“免费抽 3 次 观看解锁无限次”并且把签到的额外奖励挂在广告后面广告播放量整整翻了一倍而用户投诉和不满意度反而降了。原因也简单用户觉得是自己在“赚机会”而不是被强迫看广告。如果你准备拿这套代码做自己的小程序第一周上线不要追求完美重点盯两个数广告填充率和积分消耗率。前者决定你有没有钱赚后者决定积分系统会不会崩。这两个数字健康了再考虑优化动画效果、加新玩法。还有一个小技巧是埋点一定要从第一天就做。不要等到上线后再补统计那时候前期的数据已经丢了。至少要在前端埋三个事件ad_request广告加载请求、ad_shown广告展示、ad_rewarded广告播放完成发积分。这三个数据能直接告诉你漏斗在哪一步流失不管是技术问题还是用户意愿问题都能很快定位。最后提醒一句开源版本里我隐藏了各平台真实的私有 AppID 和广告位配置替换成自己的时记得同时检查project.config.json的 AppID 和代码里的adUnitId是否一致。这个坑我亲眼见过不下十个人踩了明明广告代码没问题但就是不展示广告最后才发现两个 ID 对不上。项目持续迭代中有问题可以在仓库的 issue 区交流如果能顺手 star 一下开源维护的动力会足很多。
