編輯導語：如今隨着互聯網的不斷髮展，電商行業逐漸深入我們的生活中去，優惠券也成了電商們的一種營銷方式，發放優惠券促進消費者消費和轉化；本文作者分享了關於優惠券的發展以及系統設計，我們一起來了解一下。
優惠券，是互聯網重要且常用的營銷手段之一，玩法越來越多元，甚至於發展出了“券”商等盈利模式。
在當今營銷界佔據了重要地位的它，也有着悠久的歷史；從上個世紀，優惠券已經開始流行，至今已經百年。
本篇將從優惠券的起源出發，看企業內部如何設計禮券活動，然後從用户側看禮券目前的一些新玩法，最後來看優惠券系統應該怎麼設計。
一、優惠券的起源優惠券，最初是作為一種憑證出現在法國，然後在19世界美國得以流行。説到它作為一種營銷手段發揮的作用，不可不提的一家公司是coca-cola~。
1894年，為了吸引更多的顧客的注意，可口可樂發放了一批免費試用券和帶有可口可樂標誌的小禮品，依據這些手段可口可樂的廣告覆蓋率已遠超其它產品，知名度迅速提升；由於其顯著的效果，優惠券作為一種營銷工具被商家和廠家開始認識和採用。
發放優惠券這種形式，直到現在也在線下被使用。從報紙夾縫中減優惠券是我沒有經歷過的，不過我現在還能想起肯德基優惠券的手感。現在新開的店消費完也經常會發一些無門檻券吸引下一次繼續吃。
隨着社會的變化，紙質的券越來越不常見；目前從優惠券的發放到使用基本都是電子化，營銷的目的和手段也有了不同的演變。
二、優惠券的流程及作用企業為什麼會使用優惠券，它有什麼作用？企業會怎麼進行一個優惠券的活動？
考慮這個問題，我們可以從各整體營銷活動的決策場景來看。公司在做營銷活動時，會經歷下述流程：
1）營銷活動的目標總結起來有兩點：
- 對於使用者，鼓勵更頻繁的購買或更大的購買量；
- 對於未使用者進行試用或者從那個競爭品牌吸引轉換者。
2）而營銷工具目前多種多樣，券是其中一種。為什麼有些場景是使用券而非促銷呢？
主要有以下兩點：
①禮券能合理的實現價格差異化
在大數據時代，“殺熟”是一件消費者和消費法不允許，但是在電商平台想做或者在做的事情，換個説法可以叫做“用户分層”的應用。
一個常見的用户分層的應用是，我們可以根據RFM模型中的M值推薦價格匹配的商品，而“殺熟”的區別在於是將同樣一件商品給一個不同的價格，這也是引起消費者不滿的事情；而禮券，相比於直接的商品價格波動，能合理的實現價格的分層，又能不引起用户的反感。
除此之外，比直接降價的好處還包括不會引起用户對於原價虛高的懷疑，保持消費者對產品的心理價格；
②禮券能給用户帶來獨佔心理
區別於促銷，禮券其實是用户的一種資產，會給用户帶來專屬心理。為了加深這種心理，還發展出了很多活動；比如現金購券，通過用户購買行為加深這種心理，提高禮券的使用率；比如任務獎券，通過任務獲得優惠券，一方面能刺激用户去做任務，另一方面也能加深用户的付出，把一張普通的優惠券，變成了屬於你的優惠券，就像小王子的那朵玫瑰。
當然，以上是禮券的一些優勢，而促銷也有其直觀，簡潔，玩法更加多樣等區別於禮券的優勢，在此不贅述。
3）而一個營銷活動方案主要包含以下內容：
4）在營銷實施和控制計劃時，必須考慮活動的提前期和銷售延續期。
- 提前期是指實施方案前對其進行準備所需的時間；
- 延續期開始於和活動開始的時候，結束於大約95%的促銷商品已經在消費者手上的時候。注意：不要只考慮正向購買，不考慮逆向退貨；
5）評估結果可以通過銷售數據或者實驗來評估方案。
通過以上流程，企業內部制定出活動方案並展示給用户。但優惠券怎麼能更精準的觸達到用户，而又怎麼在當前優惠券被過度使用的情況下，更好的發揮優惠券的效果？
讓我們來看一下當前一些好的實踐。
三、當今優惠券常用玩法解析優惠券從開始的通過線下發放，到線上領取，到如今的各種活動形式，其實本質並沒有發生改變，大致可分為用户主動領取和系統觸發和平台主動發放三種類型。
只是為了提高優惠券的效果，現如今的主流玩法已經發生了變化：
- 將優惠券進行外部多平台投放，更好的觸達用户，目前主要有兑換券和聯盟兩種形式；
- 結合任務機制去增加領取的難度，提高優惠券的使用率；另外任務多為分享任務，可以通過用户的社交關係去觸達更多的用户。比如分享領券；
- 在用户的瀏覽鏈路中增加觸發送券的機制，引導用户更快的下單；
1）優惠券外部投放
隨着電子商務發展越來越好，競爭也越來越烈。為了引流，漸漸發展出了靠推廣獲取佣金的個人和平台。吃到早期紅利的一些寶媽靠一部手機月入10萬不是傳説；而為了這些平台和個人的推廣效果，一般都會搭配促銷和券進行推廣。
這裏面的以淘寶聯盟為例：
作為一名淘寶商家，可以將品設置相應的佣金和聯盟專屬券，通過聯盟進行推廣，獲取更多的流量。外部平台，可以通過接口獲取在淘寶聯盟的品和活動。一些KOL，可以獲取這些信息，自己的私域流量中。用户看到信息，可以通過鏈接或者口令，訪問到領券頁，領取優惠券並下單。
2）兑換券
兑換券，是通過一券一碼的形式，生成不同的券碼進行分發。用户獲得券碼後可以通過券碼兑換成優惠券，一個券碼只能被兑換一次。為了使券的利用率更高，也可以控制券批次中用户的兑換次數。而券碼，一般是通過短信或者外部廣告主觸達給用户。
現在這種形式逐漸沒落，一方面是流程較長，先找到頁面兑換，在去使用，還可能存在需要用户跨平台兑換；另一方面是現在很多私域流量的崛起，很多羣主在微信羣裏分享優惠信息，而一券一碼的形式並不方便傳播，針對它的替換形式是類似於優惠口令的形式，一個碼可以使用多次，下單時輸入即可。
3）分享領券
分享領券其實也是一種領券活動，但是在領券前，增加了一個分享的任務。一是能提高券的使用率，二是通過分享獲取流量。
此處還是以淘寶的分享領券為例：
商家在後台設置分享領券的活動，用户看到活動信息，進行分享；被分享者查看分享者的內容後幫助分享者助力，並獲得一張子券。當查看鏈接人數達到活動要求後，分享者獲得優惠券。
分享者鏈路：
被分享者鏈路：
來源：淘寶裂變券白皮書
4）彈屏送券
彈屏送券，是現在用的比較多的一種形式了；這是站內觸達+禮券的一種結合。在用户的各個站內環節，通過彈屏為用户送出禮券，促使用户下單。
作為一個發揮了重要作用且非常常用的營銷手段，禮券裏系統應該怎麼設計才能“長治久安”？接下來我將拆解一下禮券系統。
首先上圖：
系統大概分為4大部分功能：
- 優惠券的信息：主要用於在展示、核銷、以及成本管控部分使用，包含創建和流程。
- 活動的創建和審核：活動包含的信息主要決定了在何時，何地，通過何種方式將哪些券發放給哪些用户，而活動類型則由活動的目的決定。
- 核銷：在優惠券在用户賬户中後，用户如何使用，哪種情況下會返還，是核銷部分需要考慮的。
- 效果統計：主要包含數量統計、ROI，以及券關聯用户的情況追蹤。
而在整個電商體系中，優惠券系統是屬於一箇中上游系統，上連接用户端進行用户測的領取綁定，下連接內部系統實現優惠券的創建、管控、通知等功能。
五、優惠券信息優惠券按照不同的維度可以分為不同的類型。按照作用對象分，可以分為運費券和商品券，按照優惠類型分為滿減券，折扣券和商品兑換券等。
此處先放一個京東給商家的頁面：
京東給商家的優惠券工具，分為店鋪券，商品券和裂變券。此處的優惠券對應的活動信息，其實是都為領券活動；所以為了方便商家理解，活動信息和禮券信息都是結合在一起的。
如果是給內部用户使用，我建議券和活動進行分開，原因有：
1）不同活動類型需要的信息不相同，把優惠券和活動分開能更好的模塊化。比如領券活動，我們需要領券的時間，限制等信息，如果是抽獎活動，優惠券系統只提供了一個券的基本信息，而活動信息是在抽獎活動系統進行的控制。
2）為了控制成本，禮券的預算需要進行把控，故在禮券創建的時候需要系統或者人為去判斷“禮券的優惠總額”<=當前可用預算。而活動則是需要根據情況進行調整。比如雙十一要做100-10的券，預算10萬，只能申請1萬張券。而這1萬張券，可以在1號-11號之間靈活發放。券和活動分開則能更好的實現這個場景。
但是，如果在界面上也將禮券和活動分開，也會增加商家理解的成本。如果頁面設計不能讓商家理解，建議犧牲頁面的功能，保證提供的功能被理解。比如目前京東的設計，沒有讓商家創建購券活動，故活動和禮券一起創建，更容易讓商家理解。
那券要包含什麼信息呢？按照字段用途可以分為展示用，核銷用，成本計算幾方面，具體字段看圖，詳細説明以下3點：
- 券名稱：券名稱可以非必填，根據券的核銷用信息進行判斷，按照固定個規則展示。比如京東的，是根據作用對象進行的分類；
- 跳轉鏈接：跳轉鏈接可以固定規則進去到券的湊單頁（此時非必填），也可以進入指定的頁面，例如活動頁等，而券可用列表頁一般由於其搜索功能，是由搜索系統實現的。
- 核銷用信息：核銷用信息也是在展示過程中需要的字段。
而關於券的成本控制，建議在創建時就判斷預算是否充足，進行預扣減，未使用完成部分在券有效期結束後恢復。而對於商家等自己完全承擔的券，則由自己承擔即可。
另外，還有一種特殊的情況，客服補的券。客服給用户的補償一般是無門檻券，但因為不同情況補償的券金額千差萬別，所以客服申請的不是上述的任何類型的券，而是申請的一個總金額，在補償用户的過程中決定補償券的金額，並在總金額中扣除。
六、活動信息優惠券需要通過活動，才能到用户賬户。如前方所説活動與券關聯，決定了決定在何時，何地，通過何種方式將哪些券發放給哪些用户，而方式則由活動目的決定。
活動主要包含的信息主要有：
- 活動時間：主要活動時間和券時間的判斷，不能給用户已經過期的優惠券哦；
- 活動位置：決定活動位置的主要有：①活動類型，如果是領券活動，可以在單品頁、領券中心、購物車頁等進行展示，而抽獎券則是在抽獎中展示此券；②活動的渠道：此時也需要注意券的使用渠道。比如為了往新的app引流，淘寶在主平台發放特價版使用的券。③如果活動可在多個位置展示，活動創建時也可以進行展示位置，比如領券活動；
- 活動方式：主要由活動類型決定，而活動類型主要由活動目的決定。比如，主要為了給商品引流，可做一些領券活動增加用户的列表頁點擊；如果是為了外部投放，可以申請兑換券與外部合作等。
- 發放券：可以發放單張券，也可發放多張券組成的券包；
- 發放用户：活動中設置何種等級用户，何種動作可以領取，或者具體到發放給哪些用户。
- 活動總量：活動總量需要小於等於券數量，也可分多個時段進行券的發放。
- 用户領取限制：在活動中，用户可以領取的總次數限制等。
而一張券是否可以被多種活動類型使用？而一張券是否可以被多個活動使用？
建議可以，靈活方便，但是需要注意券的數量控制；而且有些活動不是在券系統創建，那此時最好不要多種活動類型一起使用，以免出現告知用户有券卻不能給用户發券的情況。
券的活動類型按照用户動作區別，分為領券、購券、兑換券以及送券。好多送券活動不是在券系統進行的設置的。具體的活動類型見藍圖，基本通過名稱即可猜測券活動形式，此處不詳述。
七、優惠券核銷1）優惠券的使用
優惠券通過活動發放到用户賬户後，下一步需要考慮的就是用户使用的問題。
使用判斷主要有3個位置：單品頁，購物車頁，結算頁。（由於目前的營銷方式越來越多元，到手價計算越來越複雜，經歷了用户的吐槽之後，目前在單品頁和購物車頁都會展示相應的到手價，此處的計算需要考慮券的結果。）
三處的計算邏輯都是一致的，大體如下：
注意：
- 目前大多采用平行式優惠，具體講解很多，此處不贅述，不瞭解的可以去查詢“平行式優惠”。
- 促銷和優惠券一般可疊加。但是為了成本控制，在對外推廣的大額券時，一般不疊加促銷，是採用的單獨的頁面，具體操作方式可以見“拉麪説”的99元6盒的推廣。
2）優惠券的分攤
用户下單之後，需要將券的使用金額分攤到其對應的商品上。
分攤金額=商品金額/（參與此券分攤的商品的總金額）*券優惠金額
根據此公式計算，可能會存在不能除盡的方式，將分以後的位數全部捨去（注意不要四捨五入，可能出現分攤總額>優惠金額情況）此處保留到分之後，需要計算券優惠券與（全部商品的分攤金額之和）的差值，將商品金額按照從小到大排序，將此差值按照商品從大到小開始依次分配1分錢，直到分配完成。
舉個栗子：
A：10元；B：3元，C：1元，券優惠金額3元；
A初次分攤：10/（10+3+1）*3=2.14
B初次分攤：3/（10+3+1）*3=0.64
C初次分攤：1/（10+3+1）*3=0.21
此時分攤總額為2.99，券金額為3元，差值為0.01，因為商品金額A>B>C，將0.01分配到A上，分配完成，此時最終分攤金額為
A：2.15元；B：0.64元，C：0.21元
3）優惠券的返還
如果用户發生取消、退貨，需要考慮優惠券的返還情況。一般來説，優惠券的返還需要考慮以下情況：
- 券是否已經過期；
- 分攤同一張券的商品是否全部完成退貨/取消；
- 券的特殊設置。比如新客券一般退貨不返還，比如商家券有些平台也不進行返還；
- 取消和退貨也會存在不同的處理情況。
4）風控
目前，一般平台下單時，都需要經過風控。風控的其中之一就是要對券進行風險控制，此處一般是風控系統的功能。
但如果風控系統不夠完善，此時就需要在券配置的時候增加一些基礎信息配置，並將需要將信息同步給風控；比如標記一些重要需要風控的券，而不重要的券可以不做風控，避免誤殺太多。
而做了平行優惠之後，價格門是尤其需要監控的，避免商家錯誤設置促銷和券，低於成本造成的損失，而又由於損失過大無法發貨造成的客訴。
5）與其它系統交互
優惠券系統與其它系統交互，大致可分為塊內容：
- 優惠券的創建，主要用於商家系統；
- 優惠券的信息查詢，主要用於內部的系統和用户端
- 優惠券的領取、核銷、返還，以及禮券使用計算，主要用於用户端；
- 優惠券的信息推送，主要用於搜索系統構建券可用列表頁。
- 使用企業內部其它系統的接口服務；
具體系統交互不贅述，看圖：
數據統計主要有3方面：
- 各環節數量監控，用於輔助判斷可以優化改進的環節。主要有：發行張數、領取張數、使用張數等；
- 金額監控，用於判斷優惠券的ROI，主要根據優惠金額、成交金額來計算；
- 用户監控，用於針對不同用户進行不同的策略引導。比如針對領取未用的用户，可以增加券的到期提醒等，或者優惠引導等，促使用户使用優惠券。
除了上述説明，券的系統設計需要注意時效性。在實現過程中，梳理清楚和外部系統的交互情況以及各環節的時，避免設置和展示不一致；比如，一般商詳頁都會做緩存，如果緩存機制設計有問題，可能會存在券已生效但未展示；或者信息變更但無法立即生效的情況。
券是基礎常用的系統，已經有許多的案例可參考，但是還需要根據各公司內部情況的不同加以調整；另外，券出現的時間很長，用户感知卻在逐步下降，如何提高券的效果是運營和產品需要一起重點考慮的問題，也是系統在基礎功能上需要拓展的方向。
但需要先保證基礎功能的可用性易用性，才能拿出更多精力發展系統。
以上，希望能和大家更多的交流～
本文由 @舉個栗子 原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議