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

小提示：您能找到这篇{复盘：一场营销活动的跌宕起伏}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的复盘：一场营销活动的跌宕起伏内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

编辑导语：一场营销活动从策划到落地，往往需要经过很多的环节，需要一定的人力物力。本文作者通过复盘自己经历的一场营销活动，为我们分享了活动的过程，以及在过程中踩到了哪些坑，希望能够帮助到大家，在以后的营销活动中，少走弯路。

PV20w，最高并发2w，活动流水420万，粉丝互动超百万条，这是一场营销活动留下的数据。在诸位看来或许已经司空见惯，但是对于我来说还是大姑娘坐花轿头一遭，具体过程不再详述，其中踩到的一些坑与各位分享作前车之鉴。

一、项目启动时间小红书推广点赞赶

活动直接由公司老板提出，给出的时间为1个月，涉及多个原有产品的功能改造，众多的产品规则校验，新增的b/c端需求，第一步就导致了我这个产品狗的加班。

1. 在规划新功能的时候，应该在文档中细致的描述出每一个新增字段的来源、状态，及不同状态之间的切换规则（非常重要的步骤，一定要仔细思考清楚）；
2. 功能层面的交互，需要和开发确认完整，每一个按钮，用户操作的效全网营销推广平台果（因为比较忙，文档丢过去就没管了，结果开发在交互理解上产生歧义浪费了大量时间，即使不够时间做完善的交互原型，也需要和和开发沟通好交互的细节）。

总结下来就是在写营销活动的需求文档时，要做到大而全，涉及多个产品线多个系统之间的对接，细节粒度要考虑到每一个字段、按钮和交互。

二、业务变化多

由于时间的紧迫就导致了一个很搞笑的现象：我一边搞完善需求，开发一边撸代码，业务还在一边更新业务规则，于是我的需求文档也随之2天一小改3天一大改，开发最多的一句话就是“又改了？”，达到了真正意义上的摸着石头过河，非常朋克！

当然这并不是什么好事情，也并不推荐大家模仿，除了业务规则上的反复横跳，在产品设计的层面，依然是非常“友好”的提出了人家的看法与意见，（一天改2版界面那种）。

所以这个坑够大了吧，也提出一些解决方式。

1. 业务/市场部门在出具活动的规划文档时，作为技术方面的产品，需要逐字逐句的去读，调出问题来，对于含糊不清的日期、数量，一定要有清晰的数值衡量，日期需要从天准确到秒，数量要准确到最大、最小值。
2. 如果需要在业务规则不确定的情况下进行开发，则让业务先确定好整体的规则，从大的规则，再到小的细节，一步一步的规范，确定下来，开发也可以按照由大框架至细节的方式来实行。
3. “用心听，但不要照做，深挖背后的需求”，这一点大家或许都听过，但是做起来很难，要求自身权限够硬+对产品足够负责，我自问目前还没达到这一点，

三、上线后的问题暴露

忙了快2个月产品终于在准备上线了，没想到接下来才是焦头烂额，活动“很成功”各种数据表明活动热度都远超预期，但是这远超预期的活动，我们并没有做好如此量级的准备。

1. 上线后第一个严重的问题就是活动商品超售

简单的描述下之前的订单交易设计，用户端点击支付了后，系统就生成一个订单，占用一个商品名额。如果10分钟内用户没有进行支付，则该订单交易关闭，名额释放，不知道各位老爷看出来这里的问题没有。

由于巨大的并发量，导致了一个问题，数据库处理订单的时间超过了10分钟，即（用户支付了订单，但是用户的支付回调处理，在系统的排队时间超过了10分钟）用户给钱了。

但是我们没收到给钱的消息（消息排队中），于是又将商品卖了出去，如此往复导致了严重的超售行为，本应该卖2000套的商品 卖出了5000套（商品基本上是亏本卖名声的）。

如此的算是重大生产事故了吧，报告给老板后，老板表示问题不大顶的住，于是后来公关部门微博发文“由于大家购买意愿强烈，业务部门多次加售”，如此处理也是妙哉。

2. 第二个问题是由于新来了大量用户，导致了账号体系的问题显现

在我们原有的账号体系中 一条用户数据对应的是一个手机号/邮箱+实名用户身份信息 当用户用了新手机号后，系统就会注册为新用户。

并且该用户无法进行实名，因为身份信息已经绑定在旧的账号上，但是旧的账号手机号又没用了，如此便是一个死结，以及之前邮箱注册的用户，用了手机号后被判断为新用户等等一系列问题。

核心点就是 原来的账号体系设计就有一堆问题，但是在面对老用户时问题不大，在接受大量新用户考验时，原有的设计缺陷纤毫毕露。

总结：在设计交易系统深圳小红书种草的人叫什么时，应该考虑完善，除了常见的一手交钱一手收钱卖货的逻辑外，还需要考虑到高并发情况下的系统数据量过大导致的一系列问题，回调请求量过大、处理速度过慢、等异常情况下的交易逻辑。

解决方式：

1. 在交易系统的设计中，订单支付的结果应该以支付回调为准，而不是系统时间做判断，即你下单了，我判断交易成功/失效，应该根据交易的回调来判断交易结果。关于高并发情况下的交易系统我就不关公面前耍大刀了，这里只是介绍一种方式；
2. 前端根据系统运行情况做限制，当服务器占用满，或者数据库的队列超过一定数量时，就从前端限制新的访问数量；
3. 账号体系的设计，账号体系的核心还是应该以人为单位，但是肯定会出现一个人多个账号的情况，对于普通电商来说或许是好事，但是对于用户数据要求严格的公司来说未必如此，对于会员账号体系的建设与异常的处理，后续有机会在分享一下自己的看法。

总结下来作为产品存在的问题：

1. 项目前期需求不明确不够细致；
2. 产品开发阶段，产品节奏把控失调，应该严格控制产品的阶段性时间。

凡事都有个第一次，相信下次遇到这种大型营销活动时，自己能做到游刃有余，信手掂来，初级产品狗的第一篇文章，希望对诸位老爷有用。

本文由 @沈万三 于，，

，基于CC0协议