举一个例子，说说我在做活动产品时踩过的坑.docVIP

举一个例子，说说我在做活动产品时踩过的坑 　　上篇，我主要讲了在接到一个项目后该如何做需求规划，下篇则重在讨论开发过程中遇到的问题，上线后出的bug及补救措施，根据数据分析对活动流程进行的调整以及我对做活动产品的一些思考。上篇阅读量即将破万，感谢大家对作者的支持，如果对上篇感兴趣的可以点击：借一个例子，说说我在做活动产品时踩过的坑（上） 　　 　　说好的下篇因为我突然感染肺炎一拖再拖，这次终于要写出来了，在此提醒各位产品狗们，投身工作的同时也别忘了照顾好自己的身体哦！ 　　四. 开发过程中遇到的问题 　　1. 跟业务以及后台现有流程相结合，争取以最小的开发难度满足业务需求 　　把一二等奖的线路产品包装成门票 　　活动送奖不同于线上购买线路产品，走的应该是后台的兑奖流程，如果你能抽中，拿到你的手机号就能帮你下单。 　　但实际上我们的后台是不具备线路下单的功能的。线路的下单需要客服介入，并且活动的奖品无法直接关联线路。但是门票的兑奖可以做到，到时候只需要拿着串码去核销就可以了。 　　所以在新建价格体系的时候就直接把一二等奖的线路包装成门票，走门票的兑奖流程就可以了。唯一多的一步也就是等名单确定了之后客服需要跟中奖用户联系确认一下团期即可。相比于开发出一套后台兑线路产品，并且往后基本无可复用的功能来说是省了很多开发成本的。 　　用优惠券如假包换兑换券的概念 　　四等奖业务的要求是指定日景区兑换券，兑换券的意思也就是说我凭兑换码可以在指定app内兑换相应的门票。 　　但是我们app没有兑奖流程，如果强行开发，成本不低不说，可复用性也不强。 　　但是优惠券，每个app都不得不做吧，如果我们新建的这些门票的价格体系都采用一个价格，并与优惠券的金额相等，那不就走了一个0元支付的过程吗？并且在下单的时候设定一下这些票种是必须使用优惠券才能购买的，就能完美的解决这个问题了（虽然有可能失去点用户体验）。 　　我一直觉得产品经理除了做好需求规划以外，还有很重要的一点是要学会以最小的成本去平衡开发和砸过来的需求，争取利益最大化。当然这是建立在对后台全盘的了解和对开发难度的认知上的。 　　2. 奖品类型不能更改 　　 　　其实这种一旦保存不能更改的情况在后台很常见，比如建价格体系的时候对应的景区或者房型无法更改，因为如果改了会造成很多关联关系的混乱，所以原则上这一类的如果建错只能删除重建。、 　　3. 关于一些可视化功能的开发（能做成可配的地方绝不要写死） 　　这么说可能有点绝对，但是规划成可配绝对是利大于弊的。 　　上图中的“是否需要指定”一开始只说在大年三十18：00—24:00中间进行，即如果这些指定人员的手机号在指定时间段内玩了我们这个活动，可直接中奖。所以当时直接加了段代码在老代码里，导致线上测试极不方便，万一出了问题，在那么重要的时间段内，损失是不言而喻的。 　　最头疼的是之后业务又提了这种需求，这相当于重复劳动力，如果改不好还可能出现其他bug，所以最简单的办法就是做成可配的呗，这样既解决了指定人的问题也解决了万一你想在什么时间提升或者降低概率也不用到那个时间死死守着电脑了。 　　 　　所以在这里指定中奖概率应该是在指定时间内除了指定名单以外的人中这一等奖的中奖概率，也就是说在这一时间段就把原中奖概率覆盖掉了。 　　4. 为什么一级放概率，二级放库存？ 　　也就是说我是先建立了奖项，并且设立这个奖项的中奖概率，然后去关联产品，并且设定这个产品的库存。 　　如果是一二等奖还好说，因为关联的产品只有一个，关联产品的库存实际上也就是一二等奖奖项的库存，也就是这个时候产品，是和奖项直接画等的。但如果像三等奖一样需要关联多个产品，那么如果你在一级里设立了库存，那这个库存其实就是一个共享库存的概念。分到每一个产品上的实际库存是不一定的。如果该产品是新建的价格体系还好，还能通过这里的库存控制成本，但如果关联的是原票种的价格体系，那很容易成本就超了（虽然同为三等奖，每个景区的成本也不一样），所以库存放在二级里更为合适。概率的话我觉得对每个关联的产品都设置概率其实没必要，三等奖要关联一二十个产品，如果从成本的角度来考虑用库存去控制就够了。 　　5. 数据埋点 　　 　　根据流程我主要统计了到达活动页面的pv（page view）， “一键领取”点击量，中奖人数。由此算出了活动参与率跟活动中奖率。 　　 　　 　　一段时间后对数据进行分析（数据量一定要够大，排出偶然因素造成的干扰），活动参与率在54%左右，活动中奖率在72%左右，进一步分析，影响活动参与的情况有三：输入手机号引起用户反感，页面设计，串码不清晰。我们的活动中奖率是百分百的，也就是最不济也能抽中四等奖，所以影响中奖率的原因只可能是串码错误（很少一部分人会把手机号位数输错。。。）。 　　针对这些原