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

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

一、項目啟動時間趕

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

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

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

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

二、業務變化多

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

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

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

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

三、上線后的問題暴露

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

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

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

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

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

如此的算是重大生產事故了吧，報告給老板后，老板表示問題不大頂的住，于是后來公關部門微博發文“由于大家購買意愿強烈，業務部門多次加售”，如此處理也是妙哉。

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

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

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

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

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

解決方式：

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

總結下來作為產品存在的問題：

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

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

本文由 @沈萬三 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議