产品设计|奖品发放规则如何控制成本及风险？

-- NO.10 --

这是Becomewiser的第10篇文章

营销活动是用户运营很重要的一部分，它能帮助我们达成拉新、促活、转化等目标。而在其中 撬动用户完成某些行为 的支点则是奖品。

而在发放奖品的时绕不过的总是成本和风险，前者是希望同样的投入能为平台创造更多的价值，后者则是避免损失。

本文将简述 发放规则的设计思路 和 监控维度 ，希望能帮助大家拓宽思路。

01 发放规则

为什么要设计发放的限制规则呢？发放规则是否仅是用户中奖，平台发奖呢？

其目的主要有三点：

1） 成本控制

不宜让同一名 用户获得过多的奖品，这并 不一定符合投入产出比

2）活动效果

对奖品发放做出一定的限制有利于活动时间延长及覆盖面的扩宽

3）风险控制

奖品是给真实用户而非羊毛用户的，其次也便于我们更迅速发现问题 。

为了解决上述的几个问题，我们会做如下的限制，接下来将以下表为例辅助各位理解。

1-1、中奖次数限制

1）时间维度

设置每日中奖总次数、每日奖项中奖次数，如果有需要，其粒度可以进一步细化。

2）用户维度

每人中奖总次数、每人奖项中奖次数

1-2、奖项互斥限制

1）组间互斥

例：中了一等奖，不可中二等奖，但可获三等奖。

2）组内互斥

例：一等奖中，中了手机不可中电视。

1-3、奖项优先级

1）当奖项中奖概率相同，优先发放某奖品

如：二等奖中，话费、流量中奖概率相同，因流量成本更低，库存更多，优先发放流量。

2）当库存不足，按优先级从有库存奖品发放

在活动中，我们常常会遇到奖品库存不足的情况，这并 不应让用户感知 。用户中奖后再提示库存不足，会对用户造成很大的伤害。

最简单粗暴的是直接使用 “不中奖”选项填补空缺，但对用户并不公平，我们 不应为了逻辑上的自洽却破坏了用户价值。

这里会更建议使用 有库存的奖品填补空缺，并根据奖项优先级设计算法的遍历顺序。

1-4、身份限制

随着技术发展，羊毛党的手段也越来越成熟，他们会 使用真实的手机号、 IP、身份证对奖品进行盗刷。

作为平台而言，我们很难判断这是否是羊毛党，由于数据过于真实贸然设置过滤规则很容易造成误伤 。

在身份限制层面，除了接入 各类云服务供应商 的风控接 口。 还应结合平台自身的用户层级进行辅助判断。 将奖品与用户身份绑定， 一方面能够避免风险，另一方面也能提升 重 要 用户的忠诚度。

假设平台的身份与用户的注册时间无关，建议对注册 做多一层过滤，其原因是羊毛党多为新注册且无成交用户，通过注册时间长度的拦截也能帮助我们减少许多风险。

02  监控维度
在奖品发放中，除了发放规则，更重要的是安全规则的设置。

1）库存余量告警

2）发放失败告警

3）增量监控
当数据高于平均值或出现极值，考虑是否出现恶意攻击等作弊行为。如： 平均每日中奖人数、 平均每日中奖次数、平均 每日奖项中奖次数等

4）异常行为监控
面向与正常数据波动不一致的行为数据，考虑是否出现恶意攻击等作弊行为。

常见的监控行为和方式如下：

a、流量异常：主要为云服务器监测。
b、中奖频次：时间段内频次异常，事实上也是接口异常相关场景。
c、区域异常：注册IP与访问IP不匹配、手机号归属与访问IP所在地不匹配、境外IP预警。
d、行为异常：多个账户为同一手机号充值、中奖概率异常
……

5）接口监控

接口监控包含数据、时序及频率的校验。

时序层面，在设计上 应更为规范， 如： 积分兑换失败时，应先修改兑换状态，再返还积分。 防止先返还积分再修改状态，导致接口被攻击。

其次假设时序校验不通过是不允许发放奖品的。

接口调用频率限制，假设不做校验很容易遭受大流量的攻击，其次对于游戏中的道具接口不做限制会导致被多次使用。

6）压力监控
这一点，主要防止大流量进入压垮服务器，设置告警能够帮助我们及时扩容。

最后

把很久之前写的文章重新改了一遍，原文的文章逻辑及描述是有一定错误的，很是对不起当年发布的小雨伞PEC和馒头商学院。 如果浪费了各位的阅读时间，还请多多包涵。

重发的原因更重要的还是为了记录那个瞬间，写下原文的时候 是产品最初的起点吧，也感谢那时对我耐心、给予的你们。