抽奖活动总结

[codcodog]

抽奖活动总结

场景

临近年底，产品提了一个「春运活动」的需求，主要是「抽奖活动」，用以实现用户导流.

活动主要分为三期抽奖，分别是：元旦，春运，新春.

问题

由于需求提出的时间为12月底，项目元旦前就要上了，只开发了短短3天就上线，导致后面有很多细节问题以及一些比较严重的 bug.

在这里整理下，用以记录.

• 活动没有做后台，很多东西在代码写死（前端，后端），导致后期运营那边很多东西修改，都是需要修改代码重新上线，并且经常性更新 SQL.
• 抽奖概率设计有问题，在第二期（春运）的时候，没有设置当期的时间段，导致（中奖概率过高）第二期开始的第一天，奖品几乎被抽完了，等运营那边反馈过来的时候已经晚了，几乎无法挽救.

总结

1. 当一个需求过来的时候，应合理评估，并且保持适当的开发时间，而不是仓促开发，仓促上线，这样是对自己的不负责，也是对自己代码的不尊重.
2. 当没有后台的时候，一些类似配置的东西不能在代码写死，而应该在配置文件里配置，根据环境（测试，预发布，生产）读取.
3. 当后期还需要修改活动信息什么的，必须要做后台来进行操作，项目上线之后不进行重复修改代码重复上线这个操作.
4. 上面所说的第二期的那个中奖问题，由于中奖概率那部分是另外一个同事写的，所以第二期来的时候，不知道要配置那个时间段，导致出现了严重的过失. 说明了自己对负责的项目没有一个全局的把控.
5. 由于中奖概率的过高，那天吸引来的用户是平时的5倍以上，这真的是不幸中的万幸（估计这是公司没有辞退我的原因 org）.

抽奖活动设计

对于「抽奖活动」的中奖概率设计，其实概率如何变化并不是真正的要点所在.
应该设计一个奖品池，运营根据节日或者运营情况，可以在某个时间段放出大量的奖品来吸引用户，进行吸粉导流.
而不是，设计概率的平均分布.
而且，奖品池这种设计更好地处理了运营在没有确认赞助商的合作或者申请经费未确认的情况，后期若有其他的合作也可以更灵活地处理.