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

上篇，我首要讲了在接到一个项目后该怎么做需求规划，下篇则重在评论开发进程中遇到的问题，上线后出的bug及补救措施，依据数据剖析对活动流程进行的调整以及我对做活动产品的一些考虑。上篇阅览量行将破万，感谢咱们对作者的支撑，假如对上篇感兴趣的能够点击：借一个比方，说说我在做活动产品时踩过的坑（上）

说好的下篇由于我忽然感染肺炎一拖再拖，这次总算要写出来了，在此提示各位产品狗们，投身作业的一起也别忘了照顾好自己的身体哦！

四. 开发进程中遇到的问题1. 跟事务以及后台现有流程相结合，争夺以最小的开发难度满意事务需求

把一二等奖的线路产品包装成门票

活动送奖不同于线上购买线路产品，走的应该是后台的兑奖流程，假如你能抽中，拿到你的手机号就能帮你下单。

但实践上咱们的后台是不具备线路下单的功用的。线路的下单需求客服介入，而且活动的奖品无法直接相关线路。可是门票的兑奖能够做到，到时分只需求拿着串码去核销就能够了。

所以在新建价格系统的时分就直接把一二等奖的线路包装成门票，走门票的兑奖流程就能够了。唯一多的一步也便是等名单承认了之后客服需求跟中奖用户联络承认一下团期即可。比较于开宣布一套后台兑线路产品，而且往后底子无可复用的功用来说是省了许多开发本钱的。

用优惠券如假包换兑换券的概念

四等奖事务的要求是指定日景区兑换券，兑换券的意思也便是说我凭兑换码能够在指定app内兑换相应的门票。

可是咱们app没有兑奖流程，假如强行开发，本钱不低不说，可复用性也不强。

可是优惠券，每个app都不得不做吧，假如咱们新建的这些门票的价格系统都选用一个价格，并与优惠券的金额持平，那不就走了一个0元付出的进程吗？而且在下单的时分设定一下这些票种是有必要运用优惠券才干购买的，就能完美的处理这个问题了（尽管有或许失掉点用户体会）。

我一向觉得产品司理除了做好需求规划以外，还有很重要的一点是要学会以最小的本钱去平衡开发和砸过来的需求，争夺利益最大化。当然这是树立在对后台全盘的了解和对开发难度的认知上的。

2. 奖品类型不能更改

其实这种一旦保存不能更改的状况在后台很常见，比方建价格系统的时分对应的景区或许房型无法更改，由于假如改了会构成许多相相关系的紊乱，所以原则上这一类的假如建错只能删去重建。、

3. 关于一些可视化功用的开发（能做成可配的当地绝不要写死）

这么说或许有点肯定，可是规划成可配肯定是利大于弊的。

上图中的“是否需求指定”一开始只说在大年三十18：00—24:00中心进行，即假如这些指定人员的手机号在指定时刻段内玩了咱们这个活动，可直接中奖。所以其时直接加了段代码在老代码里，导致线上测验极不便利，假如出了问题，在那么重要的时刻段内，丢失是显而易见的。

最头疼的是之后事务又提了这种需求，这相当于重复劳动力，假如改欠好还或许呈现其他bug，所以最简略的方法便是做成可配的呗，这样既处理了指定人的问题也处理了假如你想在什么时刻进步或许下降概率也不用到那个时刻死死守着电脑了。

所以在这儿指定中奖概率应该是在指定时刻内除了指定名单以外的人中这一等奖的中奖概率，也便是说在这一时刻段就把原中奖概率掩盖掉了。

4. 为什么一级放概率，二级放库存？

也便是说我是先树立了奖项，而且建立这个奖项的中奖概率，然后去相关产品，而且设定这个产品的库存。

假如是一二等奖还好说，由于相关的产品只要一个，相关产品的库存实践上也便是一二等奖奖项的库存，也便是这个时分产品，是和奖项直接画等的。但假如像三等奖相同需求相关多个产品，那么假如你在一级里建立了库存，那这个库存其实便是一个同享库存的概念。分到每一个产品上的实践库存是不一定的。假如该产品是新建的价格系统还好，还能经过这儿的库存操控本钱，但假如相关的是原票种的价格系统，那很简单本钱就超了（尽管同为三等奖，每个景区的本钱也不相同），所以库存放在二级里更为适宜。概率的话我觉得对每个相关的产品都设置概率其实没必要，三等奖要相关一二十个产品，假如从本钱的视点来考虑用库存去操控就够了。

5. 数据埋点

依据流程我首要计算了抵达活动页面的pv（page view）， “一键收取”点击量，中奖人数。由此算出了活动参加率跟活动中奖率。

一段时刻后对数据进行剖析（数据量一定要够大，排出偶尔要素构成的搅扰），活动参加率在54%左右，活动中奖率在72%左右，进一步剖析，影响活动参加的状况有三：输入手机号引起用户恶感，页面规划，串码不明晰。咱们的活动中奖率是百分百的，也便是最不济也能抽中四等奖，所以影响中奖率的原因只或许是串码过错（很少一部分人会把手机号位数输错。。。）。

针对这些原因咱们对活动的流程稍作了更改，第一步先对串码做校验，校验成功再输入手机号和验证码，下降用户由于输入手机号却一向报串码过错而对活动发生的疑问。假如串码校验成功，而且输入的手机号和验证码无误，是百分百中奖的。

除此之外，关于还没交给出产的串码采取了躲避附近字母数字的方法从头生成，如0&o，8&B，1&I……进步串码输入的正确率。

流程更改后毫无疑问要再埋一些点来验证你的更改是否正确，关于曾经埋的或许不需求的数据原则上是只能增加不删去不更改的，所以假如真实不需求，屏蔽也比删去好得多。

五. 线上事端1. 报表没计算上致使一二三等奖额定出了许多库存

相关产品的库存已耗费完，可是奖品报表里没显现。其时发现这个问题没介意以为是谁登后台把库存改了，然后又补了许多库存，依然是这个问题。顺手翻订单的时分发现补的两次库存悉数生成订单了！！！也便是说仅仅报表里没计算上，其实是悉数出去了，本钱超了大几千！！！其时我就溃散了~~~

但由于前端流程也有问题，中奖用户并没有得到中奖反应（也便是除非登咱们app订单里检查否则底子不知道自己中奖^_^）,所以最终经过多方尽力最终把这个丢失挽回了，可是，我也被记了大大的一笔￥%#&………

这次问题首要原因有三：

流程优化是新的人接手，新老并未做好交代导致部分代码被掩盖只在测验环境测验，并未在线上测验第一次库存无故削减并未追查原因，而是直接补库存。假如第一次出问题能查清原因，就能很好的防止这次事端。

望各位产品狗们汲取我血泪经验！

2. 服务器挂了半响才发现

其时有用户给我反应扫码进不去活动页面了，我天性的拿活动链接生成了个二维码测验了下发现没问题，就跟人家反应说是网的问题或许二维码没印好（掩面），但实践用户扫码后并不是直接跳转到活动页面而是经过服务器做了二次跳转，所以服务器挂了半响我才发现……假如不是写这篇文章这些为难的坑我几乎不愿意回想啊！

总结