复盘:一场营销活动的跌宕起伏,复盘:一场营销活动的跌宕起伏

全域/全域营销/全域营销学院/unimarketing/营销学院

,PV20w,最高并发2w,活动流水420万,粉丝互动超百万条,这是一场营销活动留下的数据。在诸位看来或许已经司空见惯,但是对于我来说还是大姑娘坐花轿头一遭,具体过程不再详述,其中踩到的一些坑与各位分享作前车之鉴。,,活动直接由公司老板提出,给出的时间为1个月,涉及多个原有产品的功能改造,众多的产品规则校验,新增的b/c端需求,第一步就导致了我这个产品狗的加班。,从当时的角度看来,实在是江郎才尽,能想到的方面文档中都写完了,结果进入开发及上线后才不断发现自己当初漏掉的问题,实属不该,最终由测试给我提了一堆产品上的问题,提出一些问题。,总结下来就是在写营销活动的需求文档时,要做到大而全,涉及多个产品线多个系统之间的对接,细节粒度要考虑到每一个字段、按钮和交互。,由于时间的紧迫就导致了一个很搞笑的现象:我一边搞完善需求,开发一边撸代码,业务还在一边更新业务规则,于是我的需求文档也随之2天一小改3天一大改,开发最多的一句话就是“又改了?”,达到了真正意义上的摸着石头过河,非常朋克!,当然这并不是什么好事情,也并不推荐大家模仿,除了业务规则上的反复横跳,在产品设计的层面,依然是非常“友好”的提出了人家的看法与意见,(一天改2版界面那种)。,所以这个坑够大了吧,也提出一些解决方式。,忙了快2个月产品终于在准备上线了,没想到接下来才是焦头烂额,活动“很成功”各种数据表明活动热度都远超预期,但是这远超预期的活动,我们并没有做好如此量级的准备。,简单的描述下之前的订单交易设计,用户端点击支付了后,系统就生成一个订单,占用一个商品名额。如果10分钟内用户没有进行支付,则该订单交易关闭,名额释放,不知道各位老爷看出来这里的问题没有。,由于巨大的并发量,导致了一个问题,数据库处理订单的时间超过了10分钟,即(用户支付了订单,但是用户的支付回调处理,在系统的排队时间超过了10分钟)用户给钱了。,但是我们没收到给钱的消息(消息排队中),于是又将商品卖了出去,如此往复导致了严重的超售行为,本应该卖2000套的商品 卖出了5000套(商品基本上是亏本卖名声的)。,如此的算是重大生产事故了吧,报告给老板后,老板表示问题不大顶的住,于是后来公关部门微博发文“由于大家购买意愿强烈,业务部门多次加售”,如此处理也是妙哉。,在我们原有的账号体系中 一条用户数据对应的是一个手机号/邮箱+实名用户身份信息  当用户用了新手机号后,系统就会注册为新用户。,并且该用户无法进行实名,因为身份信息已经绑定在旧的账号上,但是旧的账号手机号又没用了,如此便是一个死结,以及之前邮箱注册的用户,用了手机号后被判断为新用户等等一系列问题。,核心点就是 原来的账号体系设计就有一堆问题,但是在面对老用户时问题不大,在接受大量新用户考验时,原有的设计缺陷纤毫毕露。,总结:在设计交易系统时,应该考虑完善,除了常见的一手交钱一手收钱卖货的逻辑外,还需要考虑到高并发情况下的系统数据量过大导致的一系列问题,回调请求量过大、处理速度过慢、等异常情况下的交易逻辑。,解决方式:,总结下来作为产品存在的问题:,凡事都有个第一次,相信下次遇到这种大型营销活动时,自己能做到游刃有余,信手掂来,初级产品狗的第一篇文章,希望对诸位老爷有用。, ,本文由 @沈万三 原创发布于人人都是产品经理,未经许可,禁止转载,题图来自Unsplash,基于CC0协议,

未经允许不得转载:营销圈 » 复盘:一场营销活动的跌宕起伏,复盘:一场营销活动的跌宕起伏

赞 (0) 打赏

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏