上篇，我主要講了在接到一個項目後該如何做需求規劃，下篇則重在讨論開發過程中遇到的問題，上線後出的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訂單裡查看不然根本不知道自己中獎^_^）,所以最後經過多方努力最後把這個損失挽回了，但是，我也被記了大大的一筆￥%#&………

這次問題主要原因有三：

1. 流程優化是新的人接手，新老并未做好交接導緻部分代碼被覆蓋
2. 隻在測試環境測試，并未在線上測試
3. 第一次庫存無故減少并未追究原因，而是直接補庫存。如果第一次出問題能查清原因，就能很好的避免這次事故。

望各位産品狗們吸取我血淚教訓！

2. 服務器挂了半天才發現

當時有用戶給我反饋掃碼進不去活動頁面了，我本能的拿活動鍊接生成了個二維碼測試了下發現沒問題，就跟人家反饋說是網的問題或者二維碼沒印好（掩面），但實際用戶掃碼後并不是直接跳轉到活動頁面而是通過服務器做了二次跳轉，所以服務器挂了半天我才發現……如果不是寫這篇文章這些尴尬的坑我簡直不願意回憶啊！

總結

相較于做app版塊的開發，後台系統的開發，活動産品明顯有其自己的特色，大到一個跨時很長的合作項目，小到一個營銷活動或者h5遊戲，都需要考慮到很多東西。所以，多踩坑，多總結，慢慢就能形成自己的活動體系，做起活動來也會更加得心應手~~

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部