實例分享:B2C自營電商APP的優惠券設計方案1.0
整理了一下我們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大類:對商品的打折、對訂單的優惠券、對全場的活動。
- 打折,針對于商品,可以設置某一商品、可以是某一品類、也可以是全店……
- 優惠券,針對于訂單,可以設置減x元訂單金額、減運費、減稅費……
- 活動,針對于全店&訂單,一般設置為全場滿x元減x元,滿x元打x折,滿x元包郵,滿x元贈禮物……
當確認訂單的時候,滿足打折、優惠券、活動規則。誰先誰后,最終導致的付款金額是完全不一樣的。
我們設計的整套營銷功能的計算規則如下,供大家參考。
優惠券和活動的本質
當然說到底,優惠券和活動本質是一樣的。只是促銷的外部表現,但是內部規則是通用的。對于初級PM來說,可能不太能夠理解這句話,但是一定要嘗試從產品層面理解,也可從技術層面理解。
總結
本質上對于PM來說,新接手一個從未做過的功能,都是根據自己用其他產品中的該功能認知以及自己的理解、以及產品經驗來做的。問題是這樣太具象了,需要抽象出核心的模塊。
很多講優惠券的文章太側重運營層面了,問題是這樣實現出來的功能其實只是徒有表象,稍微運營有點新需求就無法擴展了。這其實是這個PM對優惠券的技術本質理解還不夠深刻。
說道最后,其實本質上就是優惠券的類如何設計,其他的都是依附于上面的方法,以及其他類的方法。
作者:吳寶峰,個人公眾號langzisay。業務型產品經理,3年社交+4年電商的工作經驗。
本文由 @吳寶峰 原創發布于人人都是產品經理。未經許可,禁止轉載。
為了兼顧優惠碼,所以盡量不要去限制該批次優惠券的數量。這一點和淘寶店鋪優惠券的區別很大。為此其實新增了2種優惠券類。最終有3個優惠券類(class):①限制總張數,限制每人領取張數②不限制總張數,限制每人領取張數③不限制總張數,不限制每人領取張數。
第一種類最終生成的實體是X張,第二和第三類是1張,但是可以使用多次。
這段話怎么理解,新增了2類優惠券類是指哪兩類,為啥最終又是3類。為什么第一種類實體是N張,第二三類是1張?
想請教一下大神,優惠券的券碼設計一般會區分字母的大小寫么?
分攤金額的算法的第一種,退款75元,那不是虧了。因為B商品未滿100元,為什么要享受滿減???
所以提供2種方案,讓業務方去選擇。本身就沒辦法十全十美。
再者還有一道關卡,這種訂單可以單獨標記出來,讓客服酌情處理。
因為我看文章,您寫的是用的第一種,所以有疑問。我覺得在商品金額分攤上面可用,如果在退單的情況下,還是整單退,會更好做。其中一件商品退的話,還會涉及到運費問題
是的,所以一般是均攤。對雙方公平些。
然后保留二次修改金額權利。
修改金額?
嗯,一般會把該權限給予后臺操作人員,比如運營,比如客服主管。