文章對優惠券設計的整個體系進行的大方向的分析整理，梳理了優惠券設計的整體框架，希望對你有益。
在上周的時候，我發布了一篇文章 《從紅包看餓了麼、美團外賣的煩惱》，沒想到（自認為）引起比較大的動靜，自己也很意外，只是很多人並不是在探討「煩惱」，也確實不太好聊這個事，筆者本身也是猜測。更多的人來問我，關於優惠券的設計方案，甚至有朋友來找我要關於優惠券設計的資料。
其實文章發表的也蠻巧的，在文章發表後的當周，餓了麼也將原本以異業合作為主的紅包，變成了更有參與感和社交屬性的類美團紅包，也屬於一個蠻巧合的事情。
其實在去年我的一篇文章《作為產品經理，我是如何理解產品的功能邊界?》，為了引出我講到的「邊界」的概念，我借用了設計優惠券的時候的一個例子，在哪個時候，也曾經有朋友給我留言，詢問我關於優惠券的設計。
說真的，當某一個朋友或讀者，問我要相關優惠券或者其他的資料時，我其實蠻怕的，因為任何的產品設計的出發點，都是業務，雖然業務和業務之前有共同性，但脫離業務的設計是沒有任何參考意義的，產品的設計，都是基於對業務的理解和目標的出發點而設計出來的。
為了讓大家更容易理解和可參考，本文的優惠券設計指南，是基於餓了麼的「下單後分享優惠券」這個業務模式而設計的。完全是我對這個業務的理解而出發，並不能代表餓了麼或者美團就是這樣設計的。設計僅供參考，希望大家從中學到的方法，如有雷同，純屬巧合。
本文會將紅包、優惠券，統一成「優惠券」這個叫法。
一、業務介紹
要想設計好產品，首先要理解業務。
1. 業務介紹
餓了麼優惠券的業務模式如下：
（1）當用戶在餓了麼平臺下單成功後，會提示可進行優惠券的分享；
（2）用戶將優惠券社交平臺；
（3）自己或其他人可進行領取優惠券到帳戶；
（4）在下單時，可使用優惠券，享受減免優惠；
關於分享中的設定第幾個人是最大，還有發放異業合作的紅包，由於是業務主線下的特點需求分支，因此不在主線範圍內。
2. 數據指標
理解了業務之後，那還有一個需要了解，也就是目標，該如何監控我的效果好還是不好，是不是需要調整，那就涉及到幾個目標。
（1）分享率。也就是當用戶下單後，有多少訂單比率會產生分享。這是一個源頭，所以需要監控好；
（2）領取率。當我的優惠券分享出去後，假設可以供10個人領，那分享出去的有多少人領取，還有領滿率多少，也就是我這優惠券發出去，有10個用戶全部領取完了，這比率多少；
（3）使用率。用戶領取了優惠券後，有多少的使用率，直接決定了最終的效果，也就是轉化率；
（4）拉新數。這應該是個附帶的，用戶分享，勢必會產生新用戶的註冊和下單，這個數據也可以看一下；
當然除了以上的，由於業務和公司的不同，還會有其他數據的監控，需具體情況具體分析。
二、框架設計
理解了業務模式，也明白了數據指標，假設需求就是實現如當前餓了麼、美團外賣一樣的優惠券獲得。當然這裡是為了簡化才這樣做的，各位需求方，千萬不要如上面所說的：「和XXXXX一樣就好了」這樣的需求，任何一個產品經理都不想聽到這樣的話，這個在產品經理眼裡，不對，不管在誰眼裡，都等於沒說。
本產品設計，會按照「產品的功能邊界」的設計思路，進行對整個系統的設計，也就是通過構建不同的系統，進行對接式的方式，將不同的系統進行串聯，最終形成完整的系統。
1. 優惠券系統
既然是一套發放優惠券的活動，那自然會有一個優惠券系統，可以對優惠券進行規則設定。
本質上，優惠券其實就是一套規則的集合體。規則一般包括：優惠金額、限制、有效期等。
（1）限制
限制裡面一般基於業務不同進行不同的設定，以外賣為例，會有使用時間的限制，比如該優惠券是午餐的，那使用時間就是11點—2點；再比如會有品類的限制，比如該優惠券是下午茶的，那所選商家必須是下午茶品類的，比如奶茶店之類。
（2）優惠金額
對於優惠金額，一般是設置當前優惠券的金額，有的是固定金額，比如滿減券、立減券；有些浮動金額，比如折扣券，隨機券（當前餓了麼、美團外賣就是隨機券，領取時確定金額）。
（3）有效期
由於優惠券一般是基於活動進行發放，大多數是設定一個有效期限，比如3天、10天，起始日期已領取開始計算的模式。
對於異業合作的券，由於如果在領取時調取第三方領取接口，再進行發放，會存在比較大的風險，一般的處理時，是在優惠券系統創建一條異業合作的優惠券，然後通過導入對方券碼的方式進行發放。
對於券碼的導入、生成導出，如果業務需要，也會考慮進去。券碼的導入時在進行發放異業合作優惠券時而設定，而生成導出，是在藉助第三方發放優惠券，而增加的處理操作方式。
2. 活動系統
優惠券是規則的集合體，那活動就是將優惠券包裝成一個活動，然後推給用戶的實體。
一個活動一般包括優惠券、個性化、有效期三部分。
（1）優惠券
也就是該活動準備發放的優惠券，去進行對優惠券的關聯。
這裡對於隨機券的處理上，一般會基於成本的考慮去設定總優惠金額，儘管每張券可能是隨機金額，但一個活動的總的優惠金額其實已經限定了。
（2）個性化
為了吸引用戶，儘管活動模板是固定的，但會提供比較大的個性化設定，可隨著運營的調整進行不同內容的展示。
個性化一般包括分享個性化、內容個性化、規則個性化。
①分享個性化。當前主流的分享都變成了微信為主，微信也提供了可定製分享內容的方式，包括標題、描述、圖片。
②內容個性化。便是基於活動模板進行的設定，比如頭圖、領取成功的彈層、按鈕的跳轉連結、活動說明等等，都是可以進行定製化設定的。
這裡的有效期一般是設定活動的有效期，去限定活動。
一般是設置一個日期區間。
3. 發放系統
有了優惠券，去限制使用和確定優惠規則。有了活動，作為優惠的發放實體，供用戶參與。那接下來就是發放系統了，去設定活動的發放。
發放系統，是通過對不同節點的梳理，進行設置不同節點的發放活動，及對發放的限制。一般包括範圍和個性化。
（1）範圍
範圍是指什麼樣的用戶能夠參與到活動的發放，對於像餓了麼、美團外賣這樣全國性的，勢必會進行差異化的優惠，比如對於北山廣，需求比較旺盛的， 參與度高的， 該設定什麼樣的運營策略，那運營策略的呈現就是活動。
範圍一般會限定節點、地區、業務、用戶。地區和業務相對來講比較好了解，用戶也是需要去篩選和過濾的， 比如對於會員性質的用戶和非會員性質的用戶，那下單後分享的活動是否進行區別對待之類的。對用戶的過濾，是比較考驗平臺對用戶的理解，和運營策略是否執行到位和準確的一個很重要的因素。
節點表示該活動是在什麼樣的狀態下呈現，比如下單成功、註冊成功等等，可以通過設定不同的節點，進行對用戶推送不同活動，讓用戶進行參與。
這裡的個性化，包括兩塊，限制和展示。
限制，是指在當前範圍下的諸如領取限制等。比如一個用戶一天只能領取該範圍下3個活動的優惠券。
展示，是指基於該範圍，設定給用戶端的展示內容，比如彈層文案、圖片等。
這裡要注意的是，發放系統發放的活動是基於活動系統生成之後，發放的子活動，也就是當節點發生時，產生的活動是一個子活動。
4. 數據系統
優惠券系統、活動系統、發放系統，是讓這個業務能夠跑起來，結合下單系統，可以形成一個很好的閉環。而數據系統，是完成第二部分的，也就是對目標和結果監控，獲得數據的數據系統。
數據系統一般需要監控下單數、活動數、優惠券數。
（1）下單數，是指當用戶下單是符合活動發放時條件時，所產生的訂單數；
（2）活動數，是指當用戶進行分享後，產生的活動數；
（3）優惠券數，是指用戶領取的用戶數量，使用可以當做優惠券的一個狀態進行標記；
拉新數量，可以通過在優惠券數的統計中，對手機號或者會員ID進行標記是否為新用戶的方式產生；
那麼在最開頭提到的四個數據：分享率、領取率、使用率、拉新率，變可通過數據系統進行計算和展示。
分享率 = 活動數 / 下單數 * 100%；
領取率 = 優惠券數 / （活動數 * 每個活動參與數）* 100% 每個活動參與數即表示每個活動允許多少用戶領取；
使用率 = 優惠券使用數 / （優惠券數 – 優惠券退券數） 如果優惠券可以退券，一般會把退券數刨除，也有是不刨除，主要看業務需求；
拉新數 = 領取過優惠券的用戶中，標記為新用戶的數量。
對於固定計算規則的數據，可以通過圖表等更友好的方式進行展示，方便查看。
三、 總結
優惠券系統，確定優惠券的規則；活動系統，發放優惠券的實體；發放系統，設定活動的發放規則；數據系統，記錄行為中產生的數據。四個系統相互配合，構成一套完整的優惠券活動發放系統。
當然，這裡的「系統」不代表是個很龐大的內容，只是用「系統」這個詞，來代替相關直接的區隔。
以上前期的思考和梳理的過程，後面的文章， 將深入到每個系統中去，去講述該如何設計和思考，優惠券本身就是一個比較龐大，而且和業務有很強關聯性的產品，藉助一篇文章時很難講完的。
最後，也特別說明一下，由於優惠券本身與業務的關聯度非常強烈，業務的不同，會直接影響到整個系統的設計，特別是越細節的內容，越與業務緊密相連。該文章是以餓了麼下單之後的分享紅包這個業務出發，設計的優惠券整套系統，敬請知悉。
本文由 @藍胖子 原創發布於人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基於CC0協議