借一个例子说说我在做活动产品时踩过的坑上
⇨⇦
本文主要写给新入门做活动产品的产品狗们，每天各个部门大大小小的活动砸过来，接，还是不接？怎么接？这当中会存在哪些问题？我想就以我负责过得一个跨期较长的传统行业与互联网合作项目来谈谈做活动产品会存在哪些问题，该如何解决这些问题。
一. 需求背景
这是一个什么活动？我们为什么要做这个活动？
是为了开拓新粉丝？引流？还是为了活跃用户？促转化？
无论是什么活动，产品经理需要考虑的不仅仅是需求提出方想要达到的一些效果，还有这个活动能为我们本身的产品带来些什么？比如有些活动需要用户提供信息，那这些用户信息能否通过活动流入我们的后台，为我们日后营销所用；再比如一些活动需要用户给自己打标签，那这些标签能否成为我们日后绘制用户画像的基础？理清了这些，在之后做需求规划的时候就能更具有针对性。
二. 流程梳理
就拿我之前提到过的合作项目为例：
我们与一个传统食品零售业合作了一次线上活动，跨时一年。流程主要是在他们的食品包装上印上活动二维码，扫码进入后可以通过包装上的串码来参与抽奖。由于我们是旅游类电商，所以提供的奖品都是旅游产品，一二等奖为旅游线路，三等奖为门票，四等奖为优惠券。流程说起来很简单，但背后需要考虑的逻辑还是蛮深的。
1. 异常流程
在梳理完活动流程后，我们最需要考虑的是异常流程，尽管它出现的可能性极低。
串码错误，串码已使用的情况应该给出什么提醒？
抽中奖品但没库存了给出什么提醒？（按道理如果没库存了该奖品不可能被用户抽到）
出现高并发但库存不足时怎么办？（系统判断库存大于0可以被抽到，但是同时抽中该奖品的人大于实际库存）
兑换券，门票都有有效期，中奖日期不在有效期内怎么办？（这多是针对过了有效期的情况）
在跟开发对需求之前，尽量把能考虑到的异常流程考虑全，不要在开需求会时，让开发提很多你根本没想到的问题，那就尴尬了。
2. 防刷机制
既然是抽奖类活动，就免不了会出现有人恶意刷奖的行为。刷奖是指一些人通过技术等非正常手段取得奖品。由于我们这个活动涉及的串码有1000w，并且每个兑奖串码的成本最低在1元。所以如果有人恶意刷奖成功，那损失将是很惨重的。
建议自己先在网上找一些防刷的措施（如图形验证码，cookie限制，ip限制，短信验证码，微信登录等），然后再和开发讨论，针对活动的实际情况定下一套该活动的防刷机制。
我们当时定的方案是：同一微信号，2分钟内连续错10次，页面出现图形验证码；2分钟内连续错30次，页面在图形验证码基础上，增加手机短信验证码。
三. 功能规划
1. 前后端功能对应
前端只是一个展现形式，大量的逻辑和层级关系都在后台。
后台规划原则：只要不是前端写死的地方，都需要在后台规划相应的维护字段，并且注意这些字段的层级关系是否符合逻辑。
（1）添加后台活动版块
（2）添加奖项
一共是四个奖项，每个奖项下面有一个或多个奖品，每个奖项又有不同的中奖概率，这么一分析。添加奖项可分为两步走：
添加奖项，同时设置概率等一系列东西
关联产品，同时设置每个产品的库存
概率只决定大奖项的中奖情况，中了该奖项后，如果该奖项下面关联了多个产品，则产品随机发放。（这里可以考虑一下为什么不对每个关联的产品也设置概率）
＂是否需要指定＂是上线后新加的功能，针对像一二等奖这样的大奖可能有些内部指定的名额，需要在特定的时间发给特定的人。值得注意的是指定一旦开启，概率完全不受奖项大概率的影响，但库存要小于等于该关联产品的库存。
产品在做规划的时候，除了为达到活动目的做的功能外，还可以思考一下有没有什么附加的增值功能以后可能会用到，先记到平日的工作簿上。这样当对方之后有需要提出的时候可以说我们早就想到了，并把对应的规划方案提出来，增加我们的专业性。
后台规划到这里基本的功能能够满足了，但一个活动的目的很大程度上并不在于做这个活动本身，而是看这个活动带给我们的数据价值，所以做任一个项目，报表功能都是不能少的。
2. 报表功能
对抽奖类活动主要需要统计的是：活动本身统计和中奖情况统计。
（1）活动统计
可以采用漏斗模型对每一步进行数据埋点，看每一步的转化率。就这个活动来说，我们比较关心的是有多少人扫码进入这个页面，有多少点击参与抽奖，有多少人实际中奖。而通过折线图的形式就可以更好的看出哪些天是参与高峰，哪些天参与的较少，较少的时候可以采取一些别的营销措施促参与。
（2）中奖统计
中奖统计主要是对中奖情况做一个记录，每个奖项中了多少个，中奖者的手机号，中奖串码，中奖时间等。除了方便之后用户的兑奖外还能对我们的放奖情况做一个清晰的记录。在这里我想说，报表的功能一定要仔细再仔细测，无论是测试环境还是正式环境，报表的失误将会直接影响发奖的情况。下篇我将讲述由于线上报表没测好而引发的较大的线上事故。
相关阅读
借一个例子，说说我在做活动产品时踩过的坑（下）