實例分享：B2C自營電商APP的優惠券設計方案1.0

基於咱們產品是B2C自營電商的底層架構，因此我設計的優惠券方案至少支持如下使用場景：滿減券、打折券、包郵券、商品券、滿贈券、全場通用券等等。

一直以來接觸的是淘寶店鋪的產品體系，根據本身之前的電商運營經驗和對優惠券的理解，最終抽象得出一套通用性的優惠券設計方案。

優惠券本質

優惠券的本質是經濟學中的價格歧視。形式上給予消費者心理必定的折扣，而後促成訂單。本質上商家向不一樣的接受者提供相同的商品或相同質量的服務，可是在接受者之間實行不一樣的銷售價格。

優惠券的表象

對於顧客來講，優惠券就是買東西的時候用它來省錢。

對於初級PM來講，優惠券可能就是滿減券、打折券、滿贈券這3種類型。那從技術層面來講，RD至少須要構建3個類，而且沒法兼顧優惠碼。而且後續很難去兼顧運營提出的新優惠券類型。

其次淘寶給店鋪提供了3種優惠券：訂單券、商品券、包郵券，這是平臺的策略。咱們是獨立B2C，不須要作得這樣細。京東也相似。

優惠券的類

從面嚮對象的技術角度來講，優惠券能夠抽象成類，本質上是類的實例化。

優惠券的價值

是優惠，不是現金。

請注意電商領域通俗意義上的優惠券是指下單能夠優惠金額的券，使用即做廢。不是那種能夠充值到帳戶的現金券，也不是可使用多張的折扣券。

爲何作優惠券？

簡單來講，就是拉新促活。

怎麼作優惠券？

先說大概步驟：

新建

即你想要什麼樣的優惠券，包含優惠券的面值，有效期，類型，門檻，使用限制，標籤……

新建是指新建了一批優惠券，可能限定了總張數，也可能不限定。本質上就是構建優惠券這個類的屬性，具體以下：

• 優惠券名稱：方便運營標記，能夠顯示給用戶看。
• 有效期：便可以使用該券的起始時間。通常有兩種：①運營人員設定，好比2017-01-05~2017-02-05②從領券之日起x天，好比註冊送券通常有效期7天。延展來說餓了麼滴滴還限定了時段，好比僅早上8:00~10:00可用。
• 應用範圍：指什麼範圍可使用券，通常是全場、某店鋪、某店鋪某品類。甚至還有限定某店鋪某商品，注意這個更應該歸於應用範圍屬性，而不是使用條件，比較容易混淆。
• 使用條件：即該訂單須要知足的條件，好比滿x元、滿x件、無條件。延展來說多是該訂單需知足、該訂單中商品需知足、該訂單的發貨地需知足……請注意最終落在該訂單層面優惠，減免金額。
• 優惠結果：即該訂單用券後享受的優惠。好比減x元、打x折、免運費、贈禮物、免稅費、返優惠券……
• 優惠疊加：好比本來是滿100元減20元，疊加後就是滿100元減20元，滿200減40元，上不封頂。
• 承擔部門：該批次優惠券的費用由哪一個部門承擔。
• 是否顯示到前端：設置了以後，商品詳情&領券中心&購物車都會顯示。通常是第一種券類。本質上應該置於發放層面，不過考慮到總不能運營每設置一批優惠券就得新建一次，發放一次。就把它歸屬於優惠券的屬性。
• 是否限定級別：好比普通用戶沒法領取，高級用戶才能夠領取。
• 排除某類商品：在應用範圍的基礎上排除某些特殊商品、某個商品。

須要單獨說明的是：

• 爲了兼顧優惠碼，因此儘可能不要去限制該批次優惠券的數量。這一點和淘寶店鋪優惠券的區別很大。爲此其實新增了2種優惠券類。最終有3個優惠券類（class）：①限制總張數，限制每人領取張數②不限制總張數，限制每人領取張數③不限制總張數，不限制每人領取張數。
• 第一種類最終生成的實體是X張，第二和第三類是1張，可是可使用屢次。後者比較適合和第三方平臺合做推廣，好比和什麼值得買。像當年uber發放出去的兌換碼應該採用的是第三種券的定義。
• 每張優惠券，只能關聯一條使用條件和一條優惠結果，技術實現層面上來講能夠關聯多條，可是這樣會致使業務太複雜。

審覈

優惠券實際上是讓利提高銷量，因此須要業務部門申請預算並提交財務審覈。不過咱們APP體量還小，這一步暫時省略。後續能夠補充。

發放

審覈經過的優惠券須要向目標用戶進行發放。發放是個泛概念，分爲用戶主動領取&系統自動發放。

新建優惠券的時候，已經提供了一個顯示到前端的屬性，稱之爲領券。

好比給每個批次的優惠券生成連接，發給用戶讓他們去領。

另外：註冊自動返券，下單自動返券，邀請成功自動返券，屬於系統自動發放的類型。

發放這一步是很偏運營的事兒，產品配合好便可。

領取

當用戶領取成功以後，個人優惠券列表新增一條記錄。此時這張券的狀態是未使用，下單的時候若是使用了它，則爲已使用狀態。

使用

優惠券的使用和訂單流程強關聯，一種是先用券後生成訂單，還有一種是先生成訂單再用券。咱們APP採用的是前者，遵循用戶被淘寶京東培養出來的認知習慣。

選擇優惠券以後生成訂單，此時該張優惠券和該訂單進行綁定，同時狀態變成」已使用」。

注意每一個訂單最多使用一張優惠券，一張優惠券只能使用一次。理論上來講一個訂單可使用多張券，一張優惠券可使用屢次好比uber有那種使用x次的晚高峯券，只是這樣會讓業務變得很複雜，產品設計和技術實現都會變得很複雜。除非業務必須，不然不推薦這樣作。

回收

過時未使用的優惠券須要進行回收和做廢。

統計

不管是生成優惠券的記錄、仍是每一張被領取的記錄，以及每張使用的記錄，都須要記錄日誌供查詢。

優惠券是否退還

理論上來講優惠券通常不退，優惠券1.0版本中不支持將未付款而取消的訂單綁定的優惠券進行返還，若是之後有時間可能會優化一下。此時會多一個使用中或者鎖定的中間狀態。

退款的時候優惠的金額怎麼處理

若是不處理，那用戶下單100+50-20優惠，若是所有退款則是退款150，很明顯對商家形成營收上面的損失。

若是處理則按照」哪裏優惠回哪裏」的規則來處理：

• 若是是指定某件商品/某類商品的優惠券，那優惠金額確定由該商品承擔的。當退該商品，需減去優惠券金額。
• 若是是指定某些（分類、商戶、活動等），那優惠金額分攤到符合資格的商品上。
• 若是是全店鋪通用，那優惠金額分攤到每個購買商品上。

分攤金額的算法有兩種：

• 按照符合優惠券的商品金額進行均攤
• 按照訂單剩餘部分是否符合優惠券

舉例：顧客購買了A商品1件90元，B商品1件30元，使用了一張優惠券滿100元減20元。若是顧客想退款A商品：

• 按照算法1，提交退款的最多金額爲90*(90+30-20)/(90+30)=75元。
• 按照算法2，由於商品B＜100元，則提交退款的最多金額爲90-20=70元。

實際狀況中方案A和B的金額，有高有低。若是因爲特殊緣由須要給用戶多退，客服可在後臺修改。

咱們APP採用的是第一種，對用戶比較公平，體驗比較好。

和其餘營銷功能的兼容性

營銷功能我通常分爲3大類：對商品的打折、對訂單的優惠券、對全場的活動。

1. 打折，針對於商品，能夠設置某一商品、能夠是某一品類、也能夠是全店……
2. 優惠券，針對於訂單，能夠設置減x元訂單金額、減運費、減稅費……
3. 活動，針對於全店&訂單，通常設置爲全場滿x元減x元，滿x元打x折，滿x元包郵，滿x元贈禮物……

當確認訂單的時候，知足打折、優惠券、活動規則。誰先誰後，最終致使的付款金額是徹底不同的。

咱們設計的整套營銷功能的計算規則以下，供你們參考。

優惠券和活動的本質

固然說到底，優惠券和活動本質是同樣的。只是促銷的外部表現，可是內部規則是通用的。對於初級PM來講，可能不太可以理解這句話，可是必定要嘗試從產品層面理解，也可從技術層面理解。

總結

本質上對於PM來講，新接手一個從未作過的功能，都是根據本身用其餘產品中的該功能認知以及本身的理解、以及產品經驗來作的。問題是這樣太具象了，須要抽象出核心的模塊。

不少講優惠券的文章太側重運營層面了，問題是這樣實現出來的功能其實只是徒有表象，稍微運營有點新需求就沒法擴展了。這實際上是這個PM對優惠券的技術本質理解還不夠深入。

說道最後，其實本質上就是優惠券的類如何設計，其餘的都是依附於上面的方法，以及其餘類的方法。