“看激励视频广告答题金币”这个需求每隔几天就会有人来问一次问法基本都一样想做一个答题类App或H5用户答对了奖励金币金币能提现平台靠激励视频广告赚钱问我有没有开源的、能直接改改上线的项目。说实话这类项目不复杂但也不是随便搭个页面就能跑通的。你要面对的不是答题逻辑怎么写而是整个广告变现闭环怎么成立用户看了广告、广告平台回调确认、你给用户发金币、用户提现、你和广告平台结算——任何一个环节断了要么用户骂娘要么你自己赔钱。这篇就结合我实际做过的几个答题金币类项目把这个从零到上线要处理的关键点全部讲透从广告联盟选型到服务端回调验签再到防刷和合规一次性说清楚。1. 答题金币和激励视频为什么是天生一对先聊点反直觉的。很多人刚接触这个方向时总以为产品核心是题库质量想着要把题出得多难、多有趣才能留住人。做出来之后数据却很难看用户答两轮就跑了广告没人看金币发了半天也没人提现。实际上这类产品的核心根本不是答题而是答题作为一个触发激励视频的容器。你把用户放在一个再做一题就有奖励的状态里他才愿意停下来花30秒看一个广告。激励视频是目前所有移动广告形态里eCPM天花板最高的因为广告主只在用户完整看完并且自愿点击的情况下才付费用户注意力质量极高。对中小产品来说这个单价往往比横幅、插屏高出一个量级。答题在这里承担的是给用户一个看广告的正当理由。答题本身提供正反馈答对了有金币有成就感。金币积累到一定数量可以提现给用户一个明确的行动目标。每当用户金币不足、答错没奖励、想翻倍奖励时激励视频就会出现用户自发主动地看广告不需要你强制。这个逻辑里最关键的一个认知是题目难度必须压得很低。我见过不少项目把题库搞得特别硬核结果用户连续答错三题就卸载了。合理的做法是让大部分题目用户看一眼就能答对偶尔错一两道让他愿意用看广告复活或看广告拿提示的方式继续玩。你要设计的是顺滑的看广告路径不是考试。金币体系也要仔细设计核心是控制一个虚拟汇率。比如约定1元10000金币那么答题奖励、签到奖励、看广告奖励都按这个锚定来定。提现门槛通常设在1元到10元之间太低会引来大批薅羊毛的太高用户觉得没希望就不攒了。适合参考这套做的场景很广常见的包括题库刷题类工具、儿童启蒙答题、综艺趣味答题、行业知识竞赛。这些产品都是同一个框架一套题库、一个金币账本、一个广告接入层、一个提现审核后台。也是下面要展开的全套架构。2. 广告联盟怎么选先别迷信高单价填充率才是生死线广告联盟选型这一步很多第一次做的人直接去穿山甲单开个广告位然后发现上线前三天填充率惨不忍睹——不是广告平台不给你量而是新App没有任何用户画像数据广告主不愿意投结果就是大量用户看完转圈、没广告可看金币发不出去。这个环节的决策顺序应该是先保证填充再追求单价。2.1 国内主流联盟的差异化定位做H5/APP双端的答题产品我实际用过的主要是以下几家广告平台优势劣势适合阶段穿山甲流量体量大填充稳定激励视频类目成熟中小开发者单价波动较大主力接入适合大多数产品优量汇腾讯系生态电商、网服类广告主多激励视频场景需要申请与穿山甲组合互补快手联盟下沉市场用户覆盖好游戏类广告主多API相对小众辅助补量百度联盟不挑域名历史审核宽松单价整体偏低H5站点的兜底新项目上线头两周建议同时接入穿山甲和优量汇用聚合层统一调度。不要一开始就只盯哪家高几块钱先看eCPM能不能保持在一个区间、填充率有没有稳定在90%以上。如果一家长期低于这个数果断调低权重让另一家顶上来。2.2 H5和APP的广告接入差别这个最关键H5的激励视频和APP的激励视频在技术上是完全不同的东西。APP端接的是Android/iOS的SDK通过服务端回调解锁奖励。H5端大多数联盟提供的是JS代码片段或是iframe地址在Web环境中加载广告页。两者的体验差距会被很多用户直接体感感知到。APP端的激励视频成功率通常在95%以上而H5端受浏览器兼容性、微信内浏览器拦截、广告页加载失败等因素影响成功率可能只有70%-80%。这也意味着如果你的产品是H5为主需要在失败重试和加载埋点上多做功夫否则用户点完看广告领金币广告没出来很大概率直接流失。我个人的习惯是如果产品长期打算做优先APP如果只是想快速验证玩法先用H5把数据跑出来。H5的开发成本低很多但别把H5的收入预期定得和APP一样高——同流量下H5的eCPM通常只有APP的五六成。这不只是SDK和JS的渲染差异更是广告主预算分配决定的他们更愿意为安装过App的用户付费。2.3 聚合平台要不要上很多开源项目会直接内嵌一个聚合SDK比如TopOn、GroMore。聚合层的好处是能同时调多家联盟动态选最高价坏处是增加了一层依赖和配置成本而且对刚冷启动的新项目来说几家的数据都不够调优意义不大。我的建议是团队不大、项目刚起步、只想快速跑通的阶段直连穿山甲优量汇两个广告位就够了。当单日请求量稳定到几万次之后再上聚合层做精细化运营。聚合层是规模化以后的事不是起步阶段的事。3. 双端架构设计一套代码库吃下H5和APP到了技术选型这一步别看市面上各种高大上的方案对大多数独立开发者和小团队来说uni-app仍然是做答题金币类H5/APP双端的最短路径。这是有现实依据的。这类项目逻辑不复杂主要就是页面展示、答题交互、广告触发、虚拟支付和后台接口。用uni-app一套Vue语法能同时编译输出H5和Android/iOS AppH5还能直接封装成小程序如果以后想扩展到微信生态的话维护成本直接砍半。很多人在Gitee和GitHub上看到这类开源项目十有八九也是uni-app写的原因就在这里。3.1 模块划分和代码组织一个可复用的开源项目结构我建议这样切模块answer-gold/ ├── api/ # 接口请求封装 │ ├── user.js # 用户登录/信息 │ ├── answer.js # 题库/答题/领取奖励 │ ├── gold.js # 金币流水/提现 │ └── ad.js # 广告回调状态查询 ├── pages/ │ ├── home/ # 首页答题入口、签到、任务列表 │ ├── quiz/ # 答题页题目、选项、倒计时 │ ├── result/ # 答题结果金币奖励、广告提示 │ ├── wallet/ # 钱包余额、流水、提现 │ └── mine/ # 我的登录状态、设置、客服 ├── components/ │ ├── ad-manager.vue # 统一广告管理器核心组件 │ └── gold-toast.vue # 金币到账通知 ├── store/ # 用户状态、金币状态 └── utils/ ├── device.js # 设备指纹/ID生成 └── validate.js # 请求验签、参数校验这套结构的关键在ad-manager.vue这个广告管理器。它把穿山甲、优量汇、H5的JS广告位全部封装成一个统一组件向外只暴露一个方法showRewardVideo(sceneId)。场景ID用来区分是答题复活金币翻倍还是签到双倍方便你后续做数据统计知道哪个场景的广告转化率最高。3.2 H5和APP的差异处理细节跨端编译能省事但几个适配点必须提前处理iOS H5下载问题。iOS的Safari对文件下载有天然限制如果用户想下载App装包非常容易变成打开PDF预览这种尴尬局面。开源项目里通常的做法是检测到iOS环境时不再提供直接下载链接而是引导跳转App Store或企业签名安装流程。H5里input输入框的键盘遮挡。这个在答题类产品里很容易遇到用户输入昵称、手机号时键盘弹起来把输入框完全挡住。uni-app编译到H5后需要自己监听键盘高度变化并调整滚动位置。很多开源项目不处理这个细节上线的评论区一片骂声。微信内嵌浏览器和普通浏览器的差异。如果用户从公众号或微信卡片进入H5很可能会遇到登录态丢失、广告加载被拦截、或者页面刷新导致重复请求的问题。我在微信里实测过部分广告联盟的H5激励视频在微信内置浏览器里会出现内存不足闪退的情况所以需要在广告管理器里做环境判断遇到微信浏览器时优先降级为传统插屏广告或者提示用户用系统浏览器打开。域名和多环境指向。开源项目一般会提供两种运行模式H5开发模式指向测试环境域名正式打包后指向生产环境域名。如果还要封装成不同品牌的白标产品域名配置就得做成动态的不能写死在代码里。一个实用做法是把API地址和广告位ID放到config.js每次打包前只改这个文件。4. 激励视频完成回调链路客户端发币是新手最容易踩的深坑做过广告接入的人都知道激励视频的奖励发放绝对不能依赖客户端回调。原因很直白——客户端的回调是可以伪造的。懂技术的人随便抓个包、改个内存就能伪造广告看完的消息。市面上卖的黑产脚本很多就是干这个的。所以从设计消费的第一天起就必须把奖励发放放到服务端来做。4.1 服务端回调验证SSV机制激励视频从用户点击到奖励到账完整链路是这样的客户端向广告平台请求一个激励视频广告位。用户完整看完广告并点击关闭按钮。广告平台的后端直接向你的服务端发送一个回调请求告知某个用户在某个广告位完成了观看。你的服务端收到回调后通过验签确认请求确实来自广告平台再给用户发金币。这个广告平台直接通知服务端的机制叫SSV。穿山甲、优量汇都有完整的服务端回调文档。开通后你需要在自己服务器的接口里做一次验签。以穿山甲为例它通过RSA签名对回调内容做校验你的服务端拿到回调参数后用平台提供的公钥做验签验签通过才发币。4.2 回调接口的幂等和时序问题回调接口看起来是一件事实操里两个问题很容易被忽略重复回调。广告平台出于消息可靠性的考虑回调可能不止一次。你的发币逻辑必须做幂等。最简单的做法是给每次广告观看生成一个唯一回调ID在你的金币流水表里加唯一索引重复回调时直接返回成功不重复加金币。回调延迟和乱序。在某些网络环境下用户看完广告后正常情况下3-5秒内就能收到回调但极端情况可能延迟到几分钟。如果用户看完广告发现金币没到账立刻点补发金币你的服务端就要处理好先收到补发请求、后收到广告回调的时序问题。我通常的做法是服务端记录待发金币状态用户查询时如果发现还没到账就把这个请求挂起来等回调最多等30秒。超时后再提示用户联系客服。4.3 开发环境要区分沙箱和正式广告位这个坑几乎所有第一次接激励视频的人都踩过开发测试时用的是正式广告位结果测试过程中产生了大量有效观看广告平台照样给你算了消耗等月底结算时发现对不上账。正确的做法是开发环境一律用广告平台提供的测试广告位ID测试完成后打包前再统一替换成正式广告位ID。测试广告位不会产生真实收入但也不会扣你的钱。配置表最好放在服务端下发方便随时调整不用频繁发版。5. 金币账本和提现风控防刷要从第一天开始做答题金币类产品最容易吸引的不是普通用户而是专业薅羊毛团队。他们手里捏着大量设备农场、IP池、手机小号目标就是批量注册、批量看广告、批量提现。如果你不从一开始做风控等羊毛大军进来再想堵已经晚了。这个品类最核心的说一句提现的钱是铁定要出去的出去的每一分都是你自己的真金白银。5.1 金币发放前的三道门槛我在做这类项目时给自己定了几条硬规矩每个用户每天看激励视频的次数设上限。普通用户一天看20-30个广告已经很多了把上限设在20次不影响正常留存但能卡掉大部分批量作业的脚本。同一设备指纹每天最多关联3个账号。设备指纹在H5端可以用canvas指纹加浏览器特征生成在APP端可以直接取Android ID或IDFA。薅羊毛团队再怎么换手机号设备数量总是有限的。提现前必须绑手机号并开启实名认证至少是身份证号校验或支付宝实名回调。这个门槛不复杂但能直接劝退一大批没有真实身份的批量账号。5.2 提现风控策略落地提现环节本身也要做策略不可能跟用户说你自己点提现我就打钱策略具体值目的最低提现门槛1元或5元起过滤小额羊毛每日提现次数每账号每天最多1次控制结算风险提现审核1元以下自动5元以上人工识别批量欺诈对账周期每24小时和广告平台结算报表对一次防止漏算坏账拿我自己跑过的一个项目举例当时日活大概3万单用户日均看广告10次单次广告收入按行业平均的中间值估算一天的总收入是相当可观的。但是其中大概有8%左右的请求在风控系统里被判为可疑流量。如果没有风控这8%的提现就是直接亏损。风控系统跑起来之后这部分损失能压到2%以内这6个点的差异就是纯利润。5.3 和广告平台对账的双账本思维这类产品做久了你会发现一个很奇怪的现象你的后台显示用户看了1000个广告广告平台报表里可能只有950个反过来也可能平台显示1200个你的后台只有1000个。前者通常是加载失败或用户中途退出平台不计费后者可能是平台的回调延迟或者用户看完广告后网络闪断回调没送达。所以一定要建立双账本的习惯一边是自己系统的金币流水一边是广告平台后台的收益报表。每天早上花十分钟拉一次昨天的数据两边做差超过一定比例就要查原因。这不是可做可不做的环节而是这类产品参与方结算的硬需求。拉账单做到日度你才不会在月底的时候被平台报表结算吓一跳。6. 开源项目落地部署从代码到上线的最后一公里如果是从开源项目起步通常拿到手的是一个uni-app前端加一个后端接口工程。代码能跑起来只是第一步后面还有一堆和钱相关的事情。6.1 部署与域名要求H5产品需要一台云服务器和备案域名这是绕不过去的。所有广告平台的H5广告位都要求HTTPS所以正式上线之前必须把证书配好。域名建议用独立的一级域名不要用二级目录拼在别人的域名下因为广告平台审核时会看页面内容是否垂直、是否有完整的隐私政策。APP端更需要提前准备的三个资质营业执照个人开发者很难申请穿山甲等正规广告联盟的激励视频广告位、软件著作权软著申请广告平台账号时往往需要提供、以及应用内隐私政策弹窗。没有营业执照的话很多联盟根本不给你开通激励视频权限这是硬门槛。6.2 广告平台审核的高频被拒点即使代码写完、子弹备齐还有最后一关广告平台的代码审核。这一关大坑很多为了让你们少走弯路我把自己被拒过的坑全贡献出来广告标识不清。激励视频广告必须明确告诉用户即将播放广告不能把广告伪装成普通游戏流程。页面上要有明显的广告字样或平台要求的角标。诱导点击。不要用马上提现领红包这类诱导性文案引导用户去点广告。平台对此类文案的打击非常严。你需要把话术改成观看广告获得额外奖励这种描述方式。广告占比过高。如果用户每完成一步操作就弹一个广告很容易被判为广告体验过差。一般的经验法则是用户在一个完整流程里看广告的次数控制在总操作步骤的三分之一以内。奖励未及时到账。这里有个两难如果使用客户端回调发币到账快但容易刷如果用服务端回调发币到账慢但安全。平台不希望用户投诉看完广告没到账所以你需要做用户提示奖励将在10秒内自动到账同时在技术侧把服务端回调超时时间压到最短。6.3 开源许可证的选择这个细节看着小但真的会影响你项目能不能被更多人用起来。开源项目建议用Apache 2.0或MIT。如果你用GPL协议很多商业团队因为担心传染性根本不敢碰你的代码社区就冷清了。做开源本来就是为了攒口碑别用一个协议把潜在使用者全赶跑了。6.4 上线后的数据观察清单项目上线后不要急着看收入总额先看几个更核心的指标激励视频人均观看次数不是总收入这个数字低于5次/人/日说明你的广告路径有问题。广告加载失败率超过15%优先检查网络策略和广告位配置。看完广告后奖励到账率低于90%基本可以确定是回调链路有损耗。金币发放后的次留率这个数据能直接反映你的金币汇率设计得合不合理。我个人做这类项目的经验是上线第一周别急着放量找几十个熟人真实使用让他们记录哪一步最想放弃哪个弹窗最烦人。这些真实反馈比后台数据维度可靠得多。把流畅度打磨到位之后再去投一点量放大验证。做这类产品最怕的不是技术难点而是前期没把小问题打磨掉就急着放大结果放大了一堆体验问题。最后再分享一个实战小技巧广告位场景ID一定要从一开始就设计好比如popup_ad_revivalads_reward_coin_double这种命名。很多项目做到中期想优化广告场景投放发现没有场景统计只能重置代码。场景埋点做得早等于给后续优化留了一扇窗。