編輯導語：一場營銷活動從策劃到落地，往往需要經(jīng)過很多的環(huán)節(jié)，需要一定的人力物力。本文作者通過復盤自己經(jīng)歷的一場營銷活動，為我們分享了活動的過程，以及在過程中踩到了哪些坑，希望能夠幫助到大家，在以后的營銷活動中，少走彎路。

PV20w，最高并發(fā)2w，活動流水420萬，粉絲互動超百萬條，這是一場營銷活動留下的數(shù)據(jù)。在諸位看來或許已經(jīng)司空見慣，但是對于我來說還是大姑娘坐花轎頭一遭，具體過程不再詳述，其中踩到的一些坑與各位分享作前車之鑒。

一、項目啟動時間趕

活動直接由公司老板提出，給出的時間為1個月，涉及多個原有產(chǎn)品的功能改造，眾多的產(chǎn)品規(guī)則校驗，新增的b/c端需求，第一步就導致了我這個產(chǎn)品狗的加班。

從當時的角度看來，實在是江郎才盡，能想到的方面文檔中都寫完了，結果進入開發(fā)及上線后才不斷發(fā)現(xiàn)自己當初漏掉的問題，實屬不該，最終由測試給我提了一堆產(chǎn)品上的問題，提出一些問題。

1. 在規(guī)劃新功能的時候，應該在文檔中細致的描述出每一個新增字段的來源、狀態(tài)，及不同狀態(tài)之間的切換規(guī)則（非常重要的步驟，一定要仔細思考清楚）；
2. 功能層面的交互，需要和開發(fā)確認完整，每一個按鈕，用戶操作的效果（因為比較忙，文檔丟過去就沒管了，結果開發(fā)在交互理解上產(chǎn)生歧義浪費了大量時間，即使不夠時間做完善的交互原型，也需要和和開發(fā)溝通好交互的細節(jié)）。

總結下來就是在寫營銷活動的需求文檔時，要做到大而全，涉及多個產(chǎn)品線多個系統(tǒng)之間的對接，細節(jié)粒度要考慮到每一個字段、按鈕和交互。

二、業(yè)務變化多

由于時間的緊迫就導致了一個很搞笑的現(xiàn)象：我一邊搞完善需求，開發(fā)一邊擼代碼，業(yè)務還在一邊更新業(yè)務規(guī)則，于是我的需求文檔也隨之2天一小改3天一大改，開發(fā)最多的一句話就是“又改了？”，達到了真正意義上的摸著石頭過河，非常朋克！

當然這并不是什么好事情，也并不推薦大家模仿，除了業(yè)務規(guī)則上的反復橫跳，在產(chǎn)品設計的層面，依然是非?！坝押谩钡奶岢隽巳思业目捶ㄅc意見，（一天改2版界面那種）。

所以這個坑夠大了吧，也提出一些解決方式。

1. 業(yè)務/市場部門在出具活動的規(guī)劃文檔時，作為技術方面的產(chǎn)品，需要逐字逐句的去讀，調出問題來，對于含糊不清的日期、數(shù)量，一定要有清晰的數(shù)值衡量，日期需要從天準確到秒，數(shù)量要準確到最大、最小值。
2. 如果需要在業(yè)務規(guī)則不確定的情況下進行開發(fā)，則讓業(yè)務先確定好整體的規(guī)則，從大的規(guī)則，再到小的細節(jié)，一步一步的規(guī)范，確定下來，開發(fā)也可以按照由大框架至細節(jié)的方式來實行。
3. “用心聽，但不要照做，深挖背后的需求”，這一點大家或許都聽過，但是做起來很難，要求自身權限夠硬+對產(chǎn)品足夠負責，我自問目前還沒達到這一點，

三、上線后的問題暴露

忙了快2個月產(chǎn)品終于在準備上線了，沒想到接下來才是焦頭爛額，活動“很成功”各種數(shù)據(jù)表明活動熱度都遠超預期，但是這遠超預期的活動，我們并沒有做好如此量級的準備。

1. 上線后第一個嚴重的問題就是活動商品超售

簡單的描述下之前的訂單交易設計，用戶端點擊支付了后，系統(tǒng)就生成一個訂單，占用一個商品名額。如果10分鐘內用戶沒有進行支付，則該訂單交易關閉，名額釋放，不知道各位老爺看出來這里的問題沒有。

由于巨大的并發(fā)量，導致了一個問題，數(shù)據(jù)庫處理訂單的時間超過了10分鐘，即（用戶支付了訂單，但是用戶的支付回調處理，在系統(tǒng)的排隊時間超過了10分鐘）用戶給錢了。

但是我們沒收到給錢的消息（消息排隊中），于是又將商品賣了出去，如此往復導致了嚴重的超售行為，本應該賣2000套的商品 賣出了5000套（商品基本上是虧本賣名聲的）。

如此的算是重大生產(chǎn)事故了吧，報告給老板后，老板表示問題不大頂?shù)淖。谑呛髞砉P部門微博發(fā)文“由于大家購買意愿強烈，業(yè)務部門多次加售”，如此處理也是妙哉。

2. 第二個問題是由于新來了大量用戶，導致了賬號體系的問題顯現(xiàn)

在我們原有的賬號體系中 一條用戶數(shù)據(jù)對應的是一個手機號/郵箱+實名用戶身份信息? 當用戶用了新手機號后，系統(tǒng)就會注冊為新用戶。

并且該用戶無法進行實名，因為身份信息已經(jīng)綁定在舊的賬號上，但是舊的賬號手機號又沒用了，如此便是一個死結，以及之前郵箱注冊的用戶，用了手機號后被判斷為新用戶等等一系列問題。

核心點就是 原來的賬號體系設計就有一堆問題，但是在面對老用戶時問題不大，在接受大量新用戶考驗時，原有的設計缺陷纖毫畢露。

總結：在設計交易系統(tǒng)時，應該考慮完善，除了常見的一手交錢一手收錢賣貨的邏輯外，還需要考慮到高并發(fā)情況下的系統(tǒng)數(shù)據(jù)量過大導致的一系列問題，回調請求量過大、處理速度過慢、等異常情況下的交易邏輯。

解決方式：

1. 在交易系統(tǒng)的設計中，訂單支付的結果應該以支付回調為準，而不是系統(tǒng)時間做判斷，即你下單了，我判斷交易成功/失效，應該根據(jù)交易的回調來判斷交易結果。關于高并發(fā)情況下的交易系統(tǒng)我就不關公面前耍大刀了，這里只是介紹一種方式；
2. 前端根據(jù)系統(tǒng)運行情況做限制，當服務器占用滿，或者數(shù)據(jù)庫的隊列超過一定數(shù)量時，就從前端限制新的訪問數(shù)量；
3. 賬號體系的設計，賬號體系的核心還是應該以人為單位，但是肯定會出現(xiàn)一個人多個賬號的情況，對于普通電商來說或許是好事，但是對于用戶數(shù)據(jù)要求嚴格的公司來說未必如此，對于會員賬號體系的建設與異常的處理，后續(xù)有機會在分享一下自己的看法。

總結下來作為產(chǎn)品存在的問題：

1. 項目前期需求不明確不夠細致；
2. 產(chǎn)品開發(fā)階段，產(chǎn)品節(jié)奏把控失調，應該嚴格控制產(chǎn)品的階段性時間。

凡事都有個第一次，相信下次遇到這種大型營銷活動時，自己能做到游刃有余，信手掂來，初級產(chǎn)品狗的第一篇文章，希望對諸位老爺有用。

本文由 @沈萬三 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議