營銷活動一直在不斷地變化與進步中，本文將分享自己的經驗，告訴大家獎品發放的一系列規則，以及如何建立安全機制。
營銷活動的形式一直在不斷的進化着，從最開始簡單粗暴的搖一搖，到砸金蛋、大轉盤、發紅包，再到後來的砍價（助力）、積分商城、小遊戲。外在形式的豐富了，但內在總是繞不過如何發放獎品。
本文便從發放獎品的規則和安全，和大家分享一下踩過的坑。
在營銷活動中，我們爲了追求更好的活動效果，又或者受限於成本、庫存等原因，會對發放獎品制定一系列規則，這些規則會導致獎品概率不準確。
接下來以表1爲例進行舉例闡述：
一、發放規則
1. 庫存控制規則
庫存控制規則，其實也是獎品的均勻發放機制，目的是使獎品不至於過早發放完畢。
1.1 中獎次數
時間維度：設置每日中獎總次數、每日獎項中獎次數，甚至可精確到時間段。
用戶維度：每人中獎總次數、每人獎項中獎次數。
1.2 獎項互斥
組間互斥，如：中了一等獎，不可中二等獎，但可獲三等獎。
組內互斥，如：一等獎中，中了手機不可中電視。
1.3 獎項優先級
當獎項中獎概率相同，優先發放某獎品。如：二等獎中，話費、流量中獎概率相同，因流量成本更低，庫存更多，優先發放流量。
當庫存不足，從擁有庫存獎品抽取，並設置抽取優先級。如：第2點庫存補足機制的方案2。
1.4 獎品真實庫存不足
除了主動控制庫存，也有真實的庫存不足導致了概率不準確。
當“一等獎：手機”全部發放完畢，庫存爲0。邏輯上程序不再抽取此獎項，在庫存爲0至庫存補充的過程中，如不加控制，抽取另一個“一等獎：電視”的概率，則變成了2.5%÷97.5。
2. 庫存補足機制
那麼這些概率不準確的地方應該如何避免呢？避免概率不準確，其實也是避免庫存不足。
當抽中手機時，手機庫存爲0，不予發放手機，可採取以下兩種方案：
方案1：以“不中獎”選項填補空缺，補足概率。
方案2：以其餘擁有庫存的某項獎品填補空缺，提高其概率重新抽取。重新抽取時以卡券1爲例，中獎概率理論上爲15%+2.5%=17.5%。
二、發放獎品：安全機制的建立
在獎品發放中，除了發放規則，更重要的是安全規則的設置，畢竟有利益的地方，就有衝突。
在獎品發放的安全機制中，主要從運維監測、開發規範兩個方面進行描述。
1. 運維監測機制
運維監測，事實上也是數據監測。
常見的按鈕數據、頁面數據指向的產品優化。而運維監測，則指向了產品的風控。
1.1 庫存監控
1.1.1 監控目的：
a、防止庫存消耗過快，活動無法進行。
b、防止惡意攻擊等作弊行爲，盜刷獎品。
c、防止獎品兌換/抽取失敗場景。
1.1.2 監測手段：
庫存的餘量監控根據庫存限制類型不同，監測手段不同：
a、 庫存受自身限制類獎品：
即庫存數據源來自自身，能根據平臺發放獎品數據監測自身庫存。
監控方式：獎品庫存剩餘50%、30%、10%預警。
b、庫存受第三方限制類獎品：
即庫存數據源來自第三方，常見於積分商城，商城內獎品爲接入第三方接口，庫存數據不主動推送給接入方。
監控方式：
實時獲取庫存：商品列表頁、商品詳情頁及訂單支付（兌換）頁調取庫存接口，獲取庫存狀態。
定時刷新機制：如商品積分兌換價格是根據第三方供應價格變動而自動換算，其監測做法也可採取同樣的方式。但爲了提高性能，較少採用在商品列表頁獲取庫存及價格狀態。
流水賬單記錄：流水賬單記錄主要防止我方產品用戶消耗次數/積分，獎品發放失敗場景，如：積分兌換場景，當存在獎品領取記錄，不存在第三方反饋記錄或第三方反饋失敗記錄也可考慮自動退回積分的操作。
當涉及到虛擬獎品如流量、話費類，獎品發放失敗記錄應在某時間段彙總以郵件或其他方式進行提醒，由運營人員進行補發操作。
1.2 增量監控
1.2.1 監控目的
當數據高於平均值或出現極值，考慮是否出現惡意攻擊等作弊行爲。
1.2.2 監控方式
主要列舉增量例子：
平均每日中獎人數
平均每日中獎次數
平均每日獎項中獎次數
……
1.3 異常行爲監控
1.3.1 監控目的：
主要針對違背正常邏輯的行爲做監控，考慮是否出現惡意攻擊等作弊行爲。
1.3.2 監控方式：
流量異常：主要爲雲服務器監測。
中獎頻次：時間段內頻次異常，事實上也是接口異常相關場景。
區域異常：註冊IP與訪問IP不匹配、手機號歸屬與訪問IP所在地不匹配、境外IP預警。
行爲異常：多個賬戶爲同一手機號充值、中獎概率異常
……
2. 開發規範
此類問題主要去研發、測試、運維人員相關。
2.1 主從服務器
a、實現服務器負載均衡：
在主服務器和從服務器之間實現負載均衡。即可以通過在主服務器和從服務器之間切分處理客戶查詢的負荷，從而得到更好的客戶響應時間。
b、實現數據的異地備份:
定期將數據從主服務器上覆制到從服務器上，提高信息安全。
c、提高數據庫系統的可用性
數據庫複製功能實現了主服務器與從服務器之間數據的同步，當主服務器出現問題時，數據庫管理員可以馬上讓從服務器作爲主服務器，用來數據的更新與查詢服務。
2.2 接口數據校驗
接口傳輸的數據是否符合規範，防止接口攻擊。
2.3 接口調用順序
如：積分兌換失敗時，應先修改兌換狀態，再返還積分。
防止先返還積分再修改狀態，導致接口被攻擊。
2.4 接口調用頻率
設置接口調用時間限制，如:遊戲中30秒限制使用1次道具，調用接口後，30秒內不得重複調用。
2.5 配置文件、寫死代碼自檢
在測試階段爲了測試便利，常常會修改配置文件或寫死某部分代碼，容易造成上線時未替換正確的配置文件和代碼。
上線階段也需要檢測配置文件是否生效等問題。
2.6 壓力測試
對用戶量大的程序，是否可達到期望的併發量，接受的接口錯誤率是多少？當壓力過大，可能會導致數據丟失、接口卡死等情況。
三、總結
獎品發放的相關邏輯非常的多，發放邏輯、監測機制、安全機制每一個都不是簡單能夠完善的，當無法完全考慮詳細時，一定要儘可能有足夠多的運維措施和應急預案。
除此之外，不單是獎品發放，其他產品設計中異常流、非功能性需求的考慮深度亦或者是解決能力，也是產品經理進階不可少的一環，也希望通過這一次簡單的分享，能夠做到拋轉引玉，與大家共同交流