营销活动一直在不断地变化与进步中，本篇文章作者通过分享自己的经验，告诉大家奖品发放的一系列规则，以及如何建立安全机制。
营销活动的形式一直在不断的进化着，从最开始简单粗暴的摇一摇，到砸金蛋、大转盘、发红包，再到后来的砍价（助力）、积分商城、小游戏。外在形式的丰富了，但内在总是绕不过如何发放奖品。
本文便从发放奖品的规则和安全，和大家分享一下踩过的坑。
在营销活动中，我们为了追求更好的活动效果，又或者受限于成本、库存等原因，会对发放奖品制定一系列规则，这些规则会导致奖品概率不准确。
接下来以表1为例进行举例阐述：
表1 奖品发放需求
一、发放规则
1. 库存控制规则
库存控制规则，其实也是奖品的均匀发放机制，目的是使奖品不至于过早发放完毕。
1.1 中奖次数
- 时间维度：设置每日中奖总次数、每日奖项中奖次数，甚至可精确到时间段。
- 用户维度：每人中奖总次数、每人奖项中奖次数。
1.2 奖项互斥
- 组间互斥，如：中了一等奖，不可中二等奖，但可获三等奖。
- 组内互斥，如：一等奖中，中了手机不可中电视。
1.3 奖项优先级
- 当奖项中奖概率相同，优先发放某奖品。如：二等奖中，话费、流量中奖概率相同，因流量成本更低，库存更多，优先发放流量。
- 当库存不足，从拥有库存奖品抽取，并设置抽取优先级。如：第2点库存补足机制的方案2。
1.4 奖品真实库存不足
除了主动控制库存，也有真实的库存不足导致了概率不准确。
当“一等奖：手机”全部发放完毕，库存为0。逻辑上程序不再抽取此奖项，在库存为0至库存补充的过程中，如不加控制，抽取另一个“一等奖：电视”的概率，则变成了2.5%÷97.5。
2. 库存补足机制
那么这些概率不准确的地方应该如何避免呢？避免概率不准确，其实也是避免库存不足。
当抽中手机时，手机库存为0，不予发放手机，可采取以下两种方案：
- 方案1：以“不中奖”选项填补空缺，补足概率。
- 方案2：以其余拥有库存的某项奖品填补空缺，提高其概率重新抽取。重新抽取时以卡券1为例，中奖概率理论上为15%+2.5%=17.5%。
二、发放奖品：安全机制的建立
在奖品发放中，除了发放规则，更重要的是安全规则的设置，毕竟有利益的地方，就有冲突。
在奖品发放的安全机制中，主要从运维监测、开发规范两个方面进行描述。
1. 运维监测机制
运维监测，事实上也是数据监测。
常见的按钮数据、页面数据指向的产品优化。而运维监测，则指向了产品的风控。
1.1 库存监控
1.1.1 监控目的：
a、防止库存消耗过快，活动无法进行。
b、防止恶意攻击等作弊行为，盗刷奖品。
c、防止奖品兑换/抽取失败场景。
1.1.2 监测手段：
库存的余量监控根据库存限制类型不同，监测手段不同：
a、 库存受自身限制类奖品：
即库存数据源来自自身，能根据平台发放奖品数据监测自身库存。
监控方式：奖品库存剩余50%、30%、10%预警。
b、库存受第三方限制类奖品：
即库存数据源来自第三方，常见于积分商城，商城内奖品为接入第三方接口，库存数据不主动推送给接入方。
监控方式：
- 实时获取库存：商品列表页、商品详情页及订单支付（兑换）页调取库存接口，获取库存状态。
- 定时刷新机制：如商品积分兑换价格是根据第三方供应价格变动而自动换算，其监测做法也可采取同样的方式。但为了提高性能，较少采用在商品列表页获取库存及价格状态。
- 流水账单记录：流水账单记录主要防止我方产品用户消耗次数/积分，奖品发放失败场景，如：积分兑换场景，当存在奖品领取记录，不存在第三方反馈记录或第三方反馈失败记录也可考虑自动退回积分的操作。
当涉及到虚拟奖品如流量、话费类，奖品发放失败记录应在某时间段汇总以邮件或其他方式进行提醒，由运营人员进行补发操作。
1.2 增量监控
1.2.1 监控目的
当数据高于平均值或出现极值，考虑是否出现恶意攻击等作弊行为。
1.2.2 监控方式
主要列举增量例子：
- 平均每日中奖人数
- 平均每日中奖次数
- 平均每日奖项中奖次数
- ……
1.3 异常行为监控
1.3.1 监控目的：
主要针对违背正常逻辑的行为做监控，考虑是否出现恶意攻击等作弊行为。
1.3.2 监控方式：
- 流量异常：主要为云服务器监测。
- 中奖频次：时间段内频次异常，事实上也是接口异常相关场景。
- 区域异常：注册IP与访问IP不匹配、手机号归属与访问IP所在地不匹配、境外IP预警。
- 行为异常：多个账户为同一手机号充值、中奖概率异常
- ……
2. 开发规范
此类问题主要去研发、测试、运维人员相关。
2.1 主从服务器
a、实现服务器负载均衡：
在主服务器和从服务器之间实现负载均衡。即可以通过在主服务器和从服务器之间切分处理客户查询的负荷，从而得到更好的客户响应时间。
b、实现数据的异地备份:
定期将数据从主服务器上复制到从服务器上，提高信息安全。
c、提高数据库系统的可用性
数据库复制功能实现了主服务器与从服务器之间数据的同步，当主服务器出现问题时，数据库管理员可以马上让从服务器作为主服务器，用来数据的更新与查询服务。
2.2 接口数据校验
接口传输的数据是否符合规范，防止接口攻击。
2.3 接口调用顺序
如：积分兑换失败时，应先修改兑换状态，再返还积分。
防止先返还积分再修改状态，导致接口被攻击。
2.4 接口调用频率
设置接口调用时间限制，如:游戏中30秒限制使用1次道具，调用接口后，30秒内不得重复调用。
2.5 配置文件、写死代码自检
在测试阶段为了测试便利，常常会修改配置文件或写死某部分代码，容易造成上线时未替换正确的配置文件和代码。
上线阶段也需要检测配置文件是否生效等问题。
2.6 压力测试
对用户量大的程序，是否可达到期望的并发量，接受的接口错误率是多少？当压力过大，可能会导致数据丢失、接口卡死等情况。
三、总结
奖品发放的相关逻辑非常的多，发放逻辑、监测机制、安全机制每一个都不是简单能够完善的，当无法完全考虑详细时，一定要尽可能有足够多的运维措施和应急预案。
除此之外，不单是奖品发放，其他产品设计中异常流、非功能性需求的考虑深度亦或者是解决能力，也是产品经理进阶不可少的一环，也希望通过这一次简单的分享，能够做到抛转引玉，与大家共同交流。
本文为@运营喵原创，运营喵专栏作者。
