重新做一个“做任务换钱”的应用，先算三笔成本和四类作弊
一、发放是一笔支出，先把三本常被漏算的成本摊开
据公开报道，一款靠做任务换金币、听歌赚金币的独立应用又回到了应用市场。这类产品的机制并不新，新的是它被逼着回答的那个问题：每一次发放到底买到了什么。任务列表是界面，底下的东西是一份营销预算。预算能不能被审计，取决于发放有没有跟一个可核验的事件绑在一起。
三笔成本经常被漏掉。
第一笔是直接发放成本，即用户最终兑走的部分折算成现金是多少。这笔最容易记，但也最容易只记总额：不按任务类型拆、不按人群拆、不按渠道拆。只看一个总数，能得出的结论只有“发超了”，得不出“哪一类任务发得不划算”。
第二笔是被薅走的边际损失。虚拟激励的边际成本看着接近零：多给一天会员、多放一份可再生的额度，账面不多花钱，于是风控松一点似乎没关系。一旦发放能兑换成有市场价的东西，边际成本就不再是零，而且损失集中发生在规则最松的那几天，等发现时批量领取早就完成了。
第三笔最隐蔽：为了防作弊加上的验证摩擦导致的转化下降。多一道验证、多一次绑定、多一段等待，都会把一部分真实用户挡在门外。这笔损失在报表里没有对应字段，只能靠人为留对照：同一条任务链，加验证前后的完成人数差、加验证那一步的流失位置。三笔合起来才是发放的真实单价。只算第一笔，一定低估；只算前两笔，会把产品越做越难用。
二、任务分三类，验证强度按类定
把所有任务当成同一类，是做这类产品最常犯的错误：要么一律不严，钱被搬走；一律很严，真人跑光。正确的切法是按“这个行为能不能被系统独立确认”分三类。
第一类是可自证的被动型，比如听歌时长、页面浏览、内容停留。这类行为的证据在客户端和服务端的时序里天然存在，验证重点不是“有没有发生”，而是“发生的是不是人的节奏”，所以强度定在抽样校验加节律判定即可，不必给用户加步骤。
第二类是需要外部核对的主动型，比如签到、分享、邀请。这类行为的发生本身可能是假的，需要外部信号确认：签到要看设备位置或网络环境的一致性，分享要看回跳是不是来自真实的新设备。强度定在每次都要跨源核对，核对不过就先挂起而不是直接拒绝。
第三类是有真实资金或数据风险的动作，比如绑定支付、填写资料、开会员。这类一旦发放错误会直接产生资损或合规问题，强度要定到最高：本人确认、限额、延迟到账、可撤销窗口都要有。
一个可执行的写法是给每类任务在配置表上固定三列：证据来源、核对方式、不通过时的处置（挂起、拒绝、转人工）。三列有空格的配置不允许上线，这是最省事的自保办法。
三、四类典型作弊：先定信号，再补埋点
作弊不是“有人使坏”这种道德问题，是一个必然发生的用量分布问题。四类最常见，每类的信号不一样。
| 作弊类型 | 可见信号 | 必须埋的字段 |
|---|---|---|
| 脚本批量做任务 | 设备指纹高度一致、操作节律过于整齐、行为时间分布均匀到不像人 | 设备与账号的关联关系、行为时间序列 |
| 一机多号与设备农场 | 同一网段、同一设备簇集中领取，账号画像字段高度雷同 | 设备与账号的关联关系、账号注册与资料完备度 |
| 只领不用的空转 | 完成任务后没有任何后续行为，隔日不回访 | 任务前后事件链 |
| 诱导分享回流 | 同一批账号互相回流、回跳来源集中在少数渠道标识 | 来源与回跳标识 |
四类字段里有两件事要说清。第一，字段要在做任务之前埋，不是出事后补。补上来的数据没有历史，等于同一批作弊要重新经历一次才能识别。第二，“任务前后事件链”这一项最容易被省掉，因为产品侧只关心任务完成，不关心完成之后。但空转这一类唯一的判据就在后面：一个账号做完了所有任务，然后什么都不做，这本身就是最强的信号，而它只能靠事件链的时间跨度看出来。
节律判定要注意不要走极端。把行为时间分布均匀当信号可以，把它当唯一判据会误伤真实用户里那些使用习惯极其规律的人。判据要写成组合：节律加设备关联加账号画像，三者同时命中才升级处置。
四、发放的延迟与限额：把钱先扣在中间一步
发放一旦即时到账，就没有任何补救空间。设计上要留一层缓冲。
先入账后到账是最有效的一招。完成动作时先把数额写进“待确认”状态，经过一段观察期再转为可用。观察期内如果关联的风控信号变坏，这笔发放还能撤回。用户侧要把这个状态显示出来并说明原因，不能让人以为系统吞了。
限额要按两个维度同时设：账号维度和设备维度。只限账号，等于鼓励多开；只限设备，等于限制家庭共享设备上的正常用户。两个维度的日额都要能配置，并且配置变更要留操作记录，便于事后解释为什么某天某批人被限住了。
异常时的处置顺序是先冻结、后人工复核，不是先封号。冻结只需要停止增量发放，保留历史与兑换入口；复核要有明确的时限和结果字段，包括命中判据、复核结论、恢复或维持的操作者。如果复核没有时限，冻结就会变成事实上的封禁，投诉全部转向客服。这一层还有一个纪律：判据和处置动作要能对上，不能出现“命中的是低风险信号，执行的却是最重处置”。
五、把金币当负债看：余额科目化与对账三口径
发放出去但未兑换的部分，本质是一项待兑付义务，应当当成余额科目来管理，而不是当成“发出去了就不关我事了”。这个视角一转，很多判断会变清楚：余额增长快，说明激励并没有换成行为，用户在攒而不是在用；余额忽然下降，可能是兑换通道被集中清空，要查是不是有人在批量套现。科目要定期核算，核算要留下每次的余额快照，只看当期发放量看不出问题。
对账口径要在上线之前定，不能等财务来问。最小三口径是：发放记录、消耗记录、余额，三者要能接上。发放记录里要有唯一发放标识、命中的任务、当时的验证结果；消耗记录里要有核销对象和核销时间；余额是前两者的差再加期初。缺任何一项，财务侧不会接受这笔支出被确认，最后变成运营自己解释、谁也不敢签字。
还有一个容易被忽略的细节：同一笔发放如果在不同系统里用不同的主键，对账会永远差几个。要在设计阶段就规定，以发放记录的主键为唯一口径，其他系统只能引用不能自造。
六、停发测试、三张表，以及能迁移到 SaaS 的那条结论
怎么知道激励到底买到了什么？最直接的测试不是归因模型，是把它停掉：选择一个可控窗口停发几天，看核心指标掉多少。掉得厉害，说明买的是“有便宜可占”这件事，用户没有对产品本体的需求；基本不掉，说明激励只是加速了本来会发生的行为，那这部分预算的优先级就该往后放。这类测试要提前告知会被观察到哪些指标，并且要设计好恢复条件，避免做成一次没有对照的赌博。
上线前必须有的三张表：发放流水，逐条记录谁在什么时间因哪个任务拿到多少、当时通过的是哪一档验证；账号风险分层，按设备关联、节律特征、后续行为把账号分成正常、观察、高危三层，并记录分层的依据；日成本与留存对照曲线，把每天的发放成本和次日回访、时长放在同一张图上，一眼看出成本涨了留存有没有跟着涨。洹拓在给做 SaaS 与内容业务的客户做数据侧方案时，一般要求这三张表跑通再谈活动上线，因为跑不通的活动复盘只能靠嘴解释。
可迁移的结论其实只有一条：激励可以是冷启动的手段，但必须有退出条件。退出条件要在活动设计阶段写死，包括什么指标达到多少就降档、什么时候整段下线。没有退出条件的激励，会把为拦截作弊而加的验证摩擦、为兑现承诺而保的兑付成本，永久摊到真实用户的使用价格里，最后产品自己背着这笔账走不动。