借一个例子，说说我在做活动产品时踩过的坑（下）

　　上篇，我主要讲了在接到一个项目后该如何做需求规划，下篇则重在讨论开发过程中遇到的问题，上线后出的bug及补救措施，根据数据分析对活动流程进行的调整以及我对做活动产品的一些思考。上篇阅读量即将破万，感谢大家对作者的支持，如果对上篇感兴趣的可以点击：借一个例子，说说我在做活动产品时踩过的坑（上）
　　说好的下篇因为我突然感染肺炎一拖再拖，这次终于要写出来了，在此提醒各位产品狗们，投身工作的同时也别忘了照顾好自己的身体哦！
　　四。开发过程中遇到的问题
　　1。跟业务以及后台现有流程相结合，争取以最小的开发难度满足业务需求
　　把一二等奖的线路产品包装成门票
　　活动送奖不同于线上购买线路产品，走的应该是后台的兑奖流程，如果你能抽中，拿到你的手机号就能帮你下单。
　　但实际上我们的后台是不具备线路下单的功能的。线路的下单需要客服介入，并且活动的奖品无法直接关联线路。但是门票的兑奖可以做到，到时候只需要拿着串码去核销就可以了。
　　所以在新建价格体系的时候就直接把一二等奖的线路包装成门票，走门票的兑奖流程就可以了。唯一多的一步也就是等名单确定了之后客服需要跟中奖用户联系确认一下团期即可。相比于开发出一套后台兑线路产品，并且往后基本无可复用的功能来说是省了很多开发成本的。
　　用优惠券如假包换兑换券的概念
　　四等奖业务的要求是指定日景区兑换券，兑换券的意思也就是说我凭兑换码可以在指定app内兑换相应的门票。
　　但是我们app没有兑奖流程，如果强行开发，成本不低不说，可复用性也不强。
　　但是优惠券，每个app都不得不做吧，如果我们新建的这些门票的价格体系都采用一个价格，并与优惠券的金额相等，那不就走了一个0元支付的过程吗？并且在下单的时候设定一下这些票种是必须使用优惠券才能购买的，就能完美的解决这个问题了（虽然有可能失去点用户体验）。
　　我一直觉得产品经理除了做好需求规划以外，还有很重要的一点是要学会以最小的成本去平衡开发和砸过来的需求，争取利益最大化。当然这是建立在对后台全盘的了解和对开发难度的认知上的。
　　2。奖品类型不能更改
　　其实这种一旦保存不能更改的情况在后台很常见，比如建价格体系的时候对应的景区或者房型无法更改，因为如果改了会造成很多关联关系的混乱，所以原则上这一类的如果建错只能删除重建。、
　　3。关于一些可视化功能的开发（能做成可配的地方绝不要写死）
　　这么说可能有点绝对，但是规划成可配绝对是利大于弊的。
　　上图中的“是否需要指定”一开始只说在大年三十18：0024：00中间进行，即如果这些指定人员的手机号在指定时间段内玩了我们这个活动，可直接中奖。所以当时直接加了段代码在老代码里，导致线上测试极不方便，万一出了问题，在那么重要的时间段内，损失是不言而喻的。
　　最头疼的是之后业务又提了这种需求，这相当于重复劳动力，如果改不好还可能出现其他bug，所以最简单的办法就是做成可配的呗，这样既解决了指定人的问题也解决了万一你想在什么时间提升或者降低概率也不用到那个时间死死守着电脑了。
　　所以在这里指定中奖概率应该是在指定时间内除了指定名单以外的人中这一等奖的中奖概率，也就是说在这一时间段就把原中奖概率覆盖掉了。
　　4。为什么一级放概率，二级放库存？
　　也就是说我是先建立了奖项，并且设立这个奖项的中奖概率，然后去关联产品，并且设定这个产品的库存。
　　如果是一二等奖还好说，因为关联的产品只有一个，关联产品的库存实际上也就是一二等奖奖项的库存，也就是这个时候产品，是和奖项直接画等的。但如果像三等奖一样需要关联多个产品，那么如果你在一级里设立了库存，那这个库存其实就是一个共享库存的概念。分到每一个产品上的实际库存是不一定的。如果该产品是新建的价格体系还好，还能通过这里的库存控制成本，但如果关联的是原票种的价格体系，那很容易成本就超了（虽然同为三等奖，每个景区的成本也不一样），所以库存放在二级里更为合适。概率的话我觉得对每个关联的产品都设置概率其实没必要，三等奖要关联一二十个产品，如果从成本的角度来考虑用库存去控制就够了。
　　5。数据埋点
　　根据流程我主要统计了到达活动页面的pv（pageview），“一键领取”点击量，中奖人数。由此算出了活动参与率跟活动中奖率。
　　一段时间后对数据进行分析（数据量一定要够大，排出偶然因素造成的干扰），活动参与率在54左右，活动中奖率在72左右，进一步分析，影响活动参与的情况有三：输入手机号引起用户反感，页面设计，串码不清晰。我们的活动中奖率是百分百的，也就是最不济也能抽中四等奖，所以影响中奖率的原因只可能是串码错误（很少一部分人会把手机号位数输错。。。）。
　　针对这些原因我们对活动的流程稍作了更改，第一步先对串码做校验，校验成功再输入手机号和验证码，降低用户因为输入手机号却一直报串码错误而对活动产生的疑问。如果串码校验成功，并且输入的手机号和验证码无误，是百分百中奖的。
　　除此之外，对于还没交付生产的串码采取了规避相近字母数字的方式重新生成，如0o，8B，1I提高串码输入的正确率。
　　流程更改后毫无疑问要再埋一些点来验证你的更改是否正确，对于以前埋的可能不需要的数据原则上是只能添加不删除不更改的，所以如果实在不需要，屏蔽也比删除好得多。
　　五。线上事故
　　1。报表没统计上致使一二三等奖额外出了很多库存
　　关联产品的库存已消耗完，但是奖品报表里没显示。当时发现这个问题没在意以为是谁登后台把库存改了，然后又补了很多库存，依然是这个问题。随手翻订单的时候发现补的两次库存全部生成订单了！！！也就是说只是报表里没统计上，其实是全部出去了，成本超了大几千！！！当时我就崩溃了
　　但因为前端流程也有问题，中奖用户并没有得到中奖反馈（也就是除非登我们app订单里查看不然根本不知道自己中奖），所以最后经过多方努力最后把这个损失挽回了，但是，我也被记了大大的一笔
　　这次问题主要原因有三：
　　流程优化是新的人接手，新老并未做好交接导致部分代码被覆盖
　　只在测试环境测试，并未在线上测试
　　第一次库存无故减少并未追究原因，而是直接补库存。如果第一次出问题能查清原因，就能很好的避免这次事故。
　　望各位产品狗们吸取我血泪教训！
　　2。服务器挂了半天才发现
　　当时有用户给我反馈扫码进不去活动页面了，我本能的拿活动链接生成了个二维码测试了下发现没问题，就跟人家反馈说是网的问题或者二维码没印好（掩面），但实际用户扫码后并不是直接跳转到活动页面而是通过服务器做了二次跳转，所以服务器挂了半天我才发现如果不是写这篇文章这些尴尬的坑我简直不愿意回忆啊！
　　总结
　　相较于做app版块的开发，后台系统的开发，活动产品明显有其自己的特色，大到一个跨时很长的合作项目，小到一个营销活动或者h5游戏，都需要考虑到很多东西。所以，多踩坑，多总结，慢慢就能形成自己的活动体系，做起活动来也会更加得心应手
　　相关阅读
　　借一个例子，说说我在做活动产品时踩过的坑（上）