企业官网建设流程全解析

“看激励视频广告答题金币”这个需求，每隔几天就会有人来问一次，问法基本都一样：想做一个答题类App或H5，用户答对了奖励金币，金币能提现，平台靠激励视频广告赚钱，问我有没有开源的、能直接改改上线的项目。

说实话，这类项目不复杂，但也不是随便搭个页面就能跑通的。你要面对的不是"答题逻辑怎么写"，而是整个广告变现闭环怎么成立：用户看了广告、广告平台回调确认、你给用户发金币、用户提现、你和广告平台结算——任何一个环节断了，要么用户骂娘，要么你自己赔钱。这篇就结合我实际做过的几个答题金币类项目，把这个从零到上线要处理的关键点全部讲透，从广告联盟选型到服务端回调验签，再到防刷和合规，一次性说清楚。

1. 答题金币和激励视频为什么是天生一对

先聊点反直觉的。很多人刚接触这个方向时，总以为产品核心是"题库质量"，想着要把题出得多难、多有趣，才能留住人。做出来之后数据却很难看：用户答两轮就跑了，广告没人看，金币发了半天也没人提现。

实际上，这类产品的核心根本不是"答题"，而是答题作为一个触发激励视频的容器。你把用户放在一个"再做一题就有奖励"的状态里，他才愿意停下来花30秒看一个广告。激励视频是目前所有移动广告形态里eCPM天花板最高的，因为广告主只在用户完整看完并且自愿点击的情况下才付费，用户注意力质量极高。对中小产品来说，这个单价往往比横幅、插屏高出一个量级。

答题在这里承担的是"给用户一个看广告的正当理由"。

• 答题本身提供正反馈：答对了有金币，有成就感。
• 金币积累到一定数量可以提现：给用户一个明确的行动目标。
• 每当用户金币不足、答错没奖励、想翻倍奖励时，激励视频就会出现：用户自发主动地看广告，不需要你强制。

这个逻辑里最关键的一个认知是：题目难度必须压得很低。我见过不少项目把题库搞得特别硬核，结果用户连续答错三题就卸载了。合理的做法是让大部分题目用户看一眼就能答对，偶尔错一两道，让他愿意用"看广告复活"或"看广告拿提示"的方式继续玩。你要设计的是"顺滑的看广告路径"，不是"考试"。

金币体系也要仔细设计，核心是控制一个虚拟汇率。比如约定1元=10000金币，那么答题奖励、签到奖励、看广告奖励都按这个锚定来定。提现门槛通常设在1元到10元之间，太低会引来大批薅羊毛的，太高用户觉得没希望就不攒了。

适合参考这套做的场景很广，常见的包括题库刷题类工具、儿童启蒙答题、综艺趣味答题、行业知识竞赛。这些产品都是同一个框架：一套题库、一个金币账本、一个广告接入层、一个提现审核后台。也是下面要展开的全套架构。

2. 广告联盟怎么选：先别迷信高单价，填充率才是生死线

广告联盟选型这一步，很多第一次做的人直接去穿山甲单开个广告位，然后发现上线前三天填充率惨不忍睹——不是广告平台不给你量，而是新App没有任何用户画像数据，广告主不愿意投，结果就是大量用户看完转圈、没广告可看，金币发不出去。这个环节的决策顺序应该是：先保证填充，再追求单价。

2.1 国内主流联盟的差异化定位

做H5/APP双端的答题产品，我实际用过的主要是以下几家：

新项目上线头两周，建议同时接入穿山甲和优量汇，用聚合层统一调度。不要一开始就只盯哪家高几块钱，先看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 App，H5还能直接封装成小程序（如果以后想扩展到微信生态的话），维护成本直接砍半。很多人在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的差异处理细节

跨端编译能省事，但几个适配点必须提前处理：

1. iOS H5下载问题。iOS的Safari对文件下载有天然限制，如果用户想下载App装包，非常容易变成"打开PDF预览"这种尴尬局面。开源项目里通常的做法是：检测到iOS环境时，不再提供直接下载链接，而是引导跳转App Store或企业签名安装流程。

2. H5里input输入框的键盘遮挡。这个在答题类产品里很容易遇到，用户输入昵称、手机号时，键盘弹起来把输入框完全挡住。uni-app编译到H5后，需要自己监听键盘高度变化并调整滚动位置。很多开源项目不处理这个细节，上线的评论区一片骂声。

3. 微信内嵌浏览器和普通浏览器的差异。如果用户从公众号或微信卡片进入H5，很可能会遇到登录态丢失、广告加载被拦截、或者页面刷新导致重复请求的问题。我在微信里实测过，部分广告联盟的H5激励视频在微信内置浏览器里会出现内存不足闪退的情况，所以需要在广告管理器里做环境判断：遇到微信浏览器时，优先降级为"传统插屏广告"或者提示用户用系统浏览器打开。

4. 域名和多环境指向。开源项目一般会提供两种运行模式：H5开发模式指向测试环境域名，正式打包后指向生产环境域名。如果还要封装成不同品牌的白标产品，域名配置就得做成动态的，不能写死在代码里。一个实用做法是：把API地址和广告位ID放到config.js，每次打包前只改这个文件。

4. 激励视频"完成回调"链路：客户端发币是新手最容易踩的深坑

做过广告接入的人都知道：激励视频的奖励发放，绝对不能依赖客户端回调。原因很直白——客户端的回调是可以伪造的。懂技术的人随便抓个包、改个内存，就能伪造"广告看完"的消息。市面上卖的黑产脚本，很多就是干这个的。所以从设计消费的第一天起，就必须把奖励发放放到服务端来做。

4.1 服务端回调验证（SSV）机制

激励视频从用户点击到奖励到账，完整链路是这样的：

1. 客户端向广告平台请求一个激励视频广告位。
2. 用户完整看完广告并点击关闭按钮。
3. 广告平台的后端直接向你的服务端发送一个回调请求，告知"某个用户在某个广告位完成了观看"。
4. 你的服务端收到回调后，通过验签确认请求确实来自广告平台，再给用户发金币。

这个"广告平台直接通知服务端"的机制，叫SSV。穿山甲、优量汇都有完整的服务端回调文档。开通后，你需要在自己服务器的接口里做一次验签。以穿山甲为例，它通过RSA签名对回调内容做校验，你的服务端拿到回调参数后，用平台提供的公钥做验签，验签通过才发币。

4.2 回调接口的幂等和时序问题

回调接口看起来是一件事，实操里两个问题很容易被忽略：

1. 重复回调。广告平台出于消息可靠性的考虑，回调可能不止一次。你的发币逻辑必须做幂等。最简单的做法是给每次广告观看生成一个唯一回调ID，在你的金币流水表里加唯一索引，重复回调时直接返回成功，不重复加金币。

2. 回调延迟和乱序。在某些网络环境下，用户看完广告后正常情况下3-5秒内就能收到回调，但极端情况可能延迟到几分钟。如果用户看完广告发现金币没到账，立刻点"补发金币"，你的服务端就要处理好"先收到补发请求、后收到广告回调"的时序问题。我通常的做法是：服务端记录"待发金币"状态，用户查询时如果发现还没到账，就把这个请求挂起来等回调，最多等30秒。超时后再提示用户联系客服。

4.3 开发环境要区分沙箱和正式广告位

这个坑几乎所有第一次接激励视频的人都踩过：开发测试时用的是正式广告位，结果测试过程中产生了大量有效观看，广告平台照样给你算了消耗，等月底结算时发现对不上账。

正确的做法是：开发环境一律用广告平台提供的测试广告位ID，测试完成后，打包前再统一替换成正式广告位ID。测试广告位不会产生真实收入，但也不会扣你的钱。配置表最好放在服务端下发，方便随时调整，不用频繁发版。

5. 金币账本和提现风控：防刷要从第一天开始做

答题金币类产品最容易吸引的不是普通用户，而是专业薅羊毛团队。他们手里捏着大量设备农场、IP池、手机小号，目标就是批量注册、批量看广告、批量提现。如果你不从一开始做风控，等羊毛大军进来再想堵，已经晚了。这个品类最核心的说一句：提现的钱是铁定要出去的，出去的每一分都是你自己的真金白银。

5.1 金币发放前的三道门槛

我在做这类项目时，给自己定了几条硬规矩：

• 每个用户每天看激励视频的次数设上限。普通用户一天看20-30个广告已经很多了，把上限设在20次，不影响正常留存，但能卡掉大部分批量作业的脚本。
• 同一设备指纹每天最多关联3个账号。设备指纹在H5端可以用canvas指纹加浏览器特征生成，在APP端可以直接取Android ID或IDFA。薅羊毛团队再怎么换手机号，设备数量总是有限的。
• 提现前必须绑手机号并开启实名认证（至少是身份证号校验或支付宝实名回调）。这个门槛不复杂，但能直接劝退一大批没有真实身份的批量账号。

5.2 提现风控策略落地

提现环节本身也要做策略，不可能跟用户说"你自己点提现我就打钱"：

拿我自己跑过的一个项目举例：当时日活大概3万，单用户日均看广告10次，单次广告收入按行业平均的中间值估算，一天的总收入是相当可观的。但是其中大概有8%左右的请求在风控系统里被判为可疑流量。如果没有风控，这8%的提现就是直接亏损。风控系统跑起来之后，这部分损失能压到2%以内，这6个点的差异就是纯利润。

5.3 和广告平台对账的"双账本"思维

这类产品做久了，你会发现一个很奇怪的现象：你的后台显示用户看了1000个广告，广告平台报表里可能只有950个；反过来也可能平台显示1200个，你的后台只有1000个。前者通常是加载失败或用户中途退出，平台不计费；后者可能是平台的回调延迟，或者用户看完广告后网络闪断，回调没送达。

所以一定要建立双账本的习惯：一边是自己系统的金币流水，一边是广告平台后台的收益报表。每天早上花十分钟拉一次昨天的数据，两边做差，超过一定比例就要查原因。这不是可做可不做的环节，而是这类产品参与方结算的硬需求。拉账单做到日度，你才不会在月底的时候被平台报表结算吓一跳。

6. 开源项目落地部署：从代码到上线的最后一公里

如果是从开源项目起步，通常拿到手的是一个uni-app前端加一个后端接口工程。代码能跑起来只是第一步，后面还有一堆和钱相关的事情。

6.1 部署与域名要求

H5产品需要一台云服务器和备案域名，这是绕不过去的。所有广告平台的H5广告位都要求HTTPS，所以正式上线之前必须把证书配好。域名建议用独立的一级域名，不要用二级目录拼在别人的域名下，因为广告平台审核时会看页面内容是否垂直、是否有完整的隐私政策。

APP端更需要提前准备的三个资质：营业执照（个人开发者很难申请穿山甲等正规广告联盟的激励视频广告位）、软件著作权（软著，申请广告平台账号时往往需要提供）、以及应用内隐私政策弹窗。没有营业执照的话，很多联盟根本不给你开通激励视频权限，这是硬门槛。

6.2 广告平台审核的高频被拒点

即使代码写完、子弹备齐，还有最后一关：广告平台的代码审核。这一关大坑很多，为了让你们少走弯路，我把自己被拒过的坑全贡献出来：

1. 广告标识不清。激励视频广告必须明确告诉用户"即将播放广告"，不能把广告伪装成普通游戏流程。页面上要有明显的"广告"字样或平台要求的角标。
2. 诱导点击。不要用"马上提现""领红包"这类诱导性文案引导用户去点广告。平台对此类文案的打击非常严。你需要把话术改成"观看广告获得额外奖励"这种描述方式。
3. 广告占比过高。如果用户每完成一步操作就弹一个广告，很容易被判为"广告体验过差"。一般的经验法则是：用户在一个完整流程里看广告的次数控制在总操作步骤的三分之一以内。
4. 奖励未及时到账。这里有个两难：如果使用客户端回调发币，到账快但容易刷；如果用服务端回调发币，到账慢但安全。平台不希望用户投诉"看完广告没到账"，所以你需要做用户提示："奖励将在10秒内自动到账"，同时在技术侧把服务端回调超时时间压到最短。

6.3 开源许可证的选择

这个细节看着小，但真的会影响你项目能不能被更多人用起来。开源项目建议用Apache 2.0或MIT。如果你用GPL协议，很多商业团队因为担心传染性根本不敢碰你的代码，社区就冷清了。做开源本来就是为了攒口碑，别用一个协议把潜在使用者全赶跑了。

6.4 上线后的数据观察清单

项目上线后不要急着看收入总额，先看几个更核心的指标：

• 激励视频人均观看次数（不是总收入）：这个数字低于5次/人/日，说明你的广告路径有问题。
• 广告加载失败率：超过15%，优先检查网络策略和广告位配置。
• 看完广告后奖励到账率：低于90%，基本可以确定是回调链路有损耗。
• 金币发放后的次留率：这个数据能直接反映你的金币汇率设计得合不合理。

我个人做这类项目的经验是：上线第一周别急着放量，找几十个熟人真实使用，让他们记录"哪一步最想放弃""哪个弹窗最烦人"。这些真实反馈比后台数据维度可靠得多。把流畅度打磨到位之后，再去投一点量，放大验证。做这类产品，最怕的不是技术难点，而是前期没把小问题打磨掉就急着放大，结果放大了一堆体验问题。

最后再分享一个实战小技巧：广告位场景ID一定要从一开始就设计好，比如"popup_ad_revival""ads_reward_coin_double"这种命名。很多项目做到中期想优化广告场景投放，发现没有场景统计，只能重置代码。场景埋点做得早，等于给后续优化留了一扇窗。