電商系統:優惠券原型設計說明(二)
編輯導讀:在整個產品發展的整個周期中,運營活動必不可少,而發放優惠券已成為運營活動的一種基本形式,而關于優惠券設計就尤為重要。本文作者分享了優惠券后臺頁面的相關設計步驟,推薦給對優惠券感興趣的童鞋閱讀。
在上一篇文章《電商系統-優惠券介紹》中,我們講解了 優惠券的獲取方式,優惠券的分類,優惠券的分類。本文繼續介紹優惠券相關的內容 — 優惠券后臺頁面是如何設計出來的。
先簡單回顧一下上一篇文章的內容,如下圖所示:
平臺運營和商家都可以在后臺創建優惠券,平臺創建的通常稱為平臺券,而店鋪則稱為店鋪券,不管是誰創建,其創建的優惠券的邏輯和規則基本上是保持一致的。在講解如何創券之前,我們來看看各大知名app上優惠券在前端展示的樣式。
由上圖可以看出常見的優惠券基本上包含了名稱、優惠面額、使用條件、有效期、使用說明、類型等信息構成。接下來我們從基本信息、使用有效期、領取限制、使用限制,這四個方面設計優惠券。
一、添加優惠券
1. 基本信息
(1)名稱:創建優惠券名稱
這里分兩種展現形式:一種是要展示在app前端樣式的名稱,是為了區分不同類型的優惠券,也可以展示營銷文案,如上圖 “NA粉絲見面禮-關注立減10″;還有一種是名稱根據一定規則自動生成的,如上圖 “滿300可用”,該名稱將不對買家展示,僅商家后臺可見。
(2)類型:常見的優惠券類型有滿減券、折扣券、免郵券、無門檻券等
滿減券是電商平臺運用最多優惠券,需要設置訂單滿足多少金額的條件。
(滿減券)
折扣券支持不設置使用條件(無門檻),也可增設最多優惠券的金額。假如訂單金額過大時,商家又擔心讓利太多,那么可以提前設置好最多優惠金額。
例子:當設置最多優惠設置50元,打折后訂單實際要優惠65元,那么這時候給用戶最多優惠是50元,而不是65元。
(折扣券)
無門檻券不限制訂單金額,可以直接使用,優惠金額不會很大,獲取難度比較大。
(無門檻券)
免郵券不是抵扣訂單的金額,而是抵扣訂單的運費。比如發往比較偏遠地區(新疆、西藏等等),店鋪考慮到郵費偏貴,會把郵費附加上去;還有海淘、直郵基本都需要用戶承擔費用,不過現在好多商家都是全國包郵。
(3)發行量:設置可允許用戶領取的總數量,有些情況可設置 “0”,代表不限制數量,不過也會設置一個很大數量代表“不限量”;例如:新人注冊成功后,送的優惠券,一般都會設置非常大的數量。
(4)使用說明:告知用戶優惠券適用人群、使用限制等信息,如上圖所示。
(5)是否公開:屬于布爾值,這里指是否在詳情頁展示優惠券,供用戶主動領取,不公開的優惠券可用來設置活動所需。
2. 使用有效期
優惠券的有效期一般有三種形式:固定時間、領券當日起x天內有效、領券次日起x天內有效。
(1)固定時間
固定時間將優惠券有效期精確到時分秒,有固定的開始和結束時間。例如:國慶大促券有效期:10月1日 00:00:01 ~ 10月7日 23:59:59,無論平臺何時發放或用戶何時領取,用戶收到的券的有效時間即為固定,只是晚領取券的剩余有效期短一點。
此類券配合大促類活動場景比較多。
(2)領券當日起x天內有效
該形式取決于用戶何時領到券,有效期為相對的天數,領取后x天內有效,包含了主動領券和被動領券。主動領券多見于日?;顒?,被動領取就比如新用戶注冊就送7天有效的券。
用戶領取的時間點不同,有效期也動態變化,開始時間是用戶領券的那一刻開始算起,截止時間則是“x * 24h”的形式,精確到秒,不過也可以采用截止時間點在最后一天23:59:59。
舉個例子:用戶某種場景下領取7天內有效的滿50減5元券,領取時間為2020.08.27 10:23:40,那么有效期一般是2020.08.27 10:23:40~2020.09.03 10:23:40。(“x *24h”的形式)
再舉個例子:用戶在上述時間領取優惠券7天內有效的滿50減5元券,那么有效是2020.08.27 10:23:40~2020.09.03 23:59:59。(非以7*24模式計算截止時間)
(3)領券次日起x天內有效
這種形式有效跟領券當日起x天內有效模式差不多,區別在于用戶領取優惠券,開始時間是“次日 00:00:01”,截止時間是“第x天結束時間 23:59:59”。
3. 領取限制
(1)單人限領:限制每個用戶的領取量,默認為1張,也可以根據實際場景設置多張領取。
(2)用戶限制:可以設置所有人領取、或按照用戶等級領取;用戶等級通常指的是普通用戶、初級會員、中級會員等會員制度的用戶。(沒有用戶等級可不設置此字段)
(3)分享設置:自己可以把獲得優惠券,通過社交軟件送給好友,這涉及到社交層面,這里不做展開。
4. 使用限制
(1)渠道:可以設置優惠券專享渠道,比如指定某些優惠券只能在微信渠道或者app渠道獨享優惠等等。
(2)商品范圍:全部商品、指定商品、 品類商品、品牌商品。
1) 全部商品:如果是店鋪創建的券,那么全店鋪商品都可以使用。
2) 指定商品:部分商品可以優惠券,也可設置單品券。
3) 品類商品:通常都由平臺進行設置,用戶完成訂單后,優惠券分攤部分將由平臺補貼回商家。點擊“添加品類”,支持多選葉子類目,同時也可以剔除不參加優惠的商品。
4) 品牌商品:通常都由平臺進行設置,用戶完成訂單后,優惠券分攤部分將由平臺補貼回商家。點擊“添加品牌”,支持多選品牌,同時也可以剔除不參加優惠的商品。
excel模板下載說明:通常平臺運營會提前將所需的商品選好,然后按照excel模板提供的格式輸入,一鍵導入即可。
二、優惠券管理
管理者可以在此頁面對優惠券進行常規的操作。
1. 優惠券狀態:已生效、 已作廢、已過期,狀態僅供參考
已生效:優惠券成功創建后,該優惠券可以正常發放,就是已生效;
已作廢:手工點擊 “結束” 按鈕,優惠券狀態由生效中變為已作廢;
已過期:表示優惠券過了有效期到了截止日期。
2. “結束” 操作說明
當發生優惠券配置錯誤或者其他突發情況的時候,允許手動的提前結束優惠券,原則上優惠券一旦設置成功后,是不允許再修改關鍵字段信息的。優惠券設置錯了,就是運營事故了,要小心哦!
點擊確認按鈕,結束發放優惠券,狀態由已生效變為已作廢,之前被用戶領取的優惠券不受影響。如果app端未更新,用戶點擊領取,提示:優惠券已領取完。
3.? “增發” 操作說明
后臺可以考慮設置優惠券數量預警值,當低于某個值的時候,提醒運營人員前去補充優惠券數量。如果沒有預警值功能的話,那列表數據可以按余量從小到大進行排列。
4. “數據”說明
優惠券發放完了,肯定是要回收使用結果的。這里列舉了幾個優惠券使用數據:優惠券領取量、使用量、有效使用量等,僅供大家參考。當然這些數據需要提前埋點操作,后臺才能統計到。通過這些數據,我們可以分析出本張優惠券所帶來的效益和轉化。
- 領取量:用戶成功領取的券數;
- 領取率:(領取量 / 總發行量) * 100%;
- 使用量:用戶待付款訂單使用的優惠券數量 + 已付款訂單使用的優惠券數量;
- 有效使用量:用戶結算的時候,成功使用優惠券進行抵扣金額的優惠券數量(已付款訂單);
- 有效使用率:(有效使用量 / 使用量) * 100%;
- 支付金額:成功使用優惠券訂單的累計支付金額;
三、優惠券明細
優惠券明細記錄著優惠券使用情況和領取情況:領取會員信息、領取方式、領取時間、是否使用、優惠金額、使用時間、訂單編號。
領取方式分為主動領取和后臺贈送,后臺分發涉及到用戶分層等內容。在上一篇文章《電商系統-優惠券介紹》也介紹過,這里不再繼續展開 ,后續會寫用戶分層、用戶標簽相關的文章,然后會具體講解優惠券精確分發。
最后,優惠券設計到這里算是介紹完了,大家哪里覺得有問題,或者哪里設計不正確,或者有什么遺漏,都可以在留言交流。
后續,還會繼續寫關于優惠券疊加問題、優惠分攤及核銷的文章,感謝關注。
#相關閱讀#
作者:道三,電商PM;公眾號: PM大秘籍
本文由 @道三 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
請問優惠券是平臺運營添加,還是商家?商家新增后需要平臺審核?
看是平臺券還是店鋪券,平臺券的話是平臺運營添加,店鋪券的話就是由商家添加,店鋪券應該是不用平臺運營審核的
博主可以分享下原型嗎
在設置優惠券的時候,京東什么的都會有優惠券有效期和可領取時間,比如商品券、店鋪券這些,有效期和可領取時間的關系是什么,什么時候才會在商品詳情頁自動露出展示呢,是不是根據有效期來還是根據可領取時間來
可領取時間影響的是發(領)券,有效期影響的是用券??梢砸没顒拥母拍顏碓O置可領取時間,活動下可設置一類或者多類優惠券,強綁定關系,有效期作為券的屬性供運營人員配置。
如果訂單提交時未正常支付,系統拆成了多筆子訂單,優惠券明細列表里 一張優惠券是不是就該有多條行記錄,對應的記錄多筆子訂單呢
運費
感謝分享,最近在設計平臺券,想問下平臺券創建的時候需要精確到具體哪些sku嗎,還是只設置品類或品牌就可以了。平臺券需要店鋪應征參與并且設置哪些sku可用嗎?
看需求吧,平臺券如果全部平臺補貼,大促階段,可能就所有都能用,或者某些類目可用,當然也會有專門針對某一個類目或者品牌的活動,然后招商,商家拿一些sku來參加。
我們做的O2O業務,平臺券是支持配置優惠金額承擔方式,支持全場、某一個類目、品牌
很棒,哈哈
公號:產品大秘籍,歡迎交流
感謝巨佬分享,請問如果繼續按照巨佬的這個后臺設計思路,添加一個發放方式需求。比如:手動領取和系統派發。那么創建一張優惠券既能夠用戶手動領取也能夠滿足后臺人員人工派發,這樣設計合不合理呢?我感覺這樣有點多余,但是目前公司的需求想要這樣,請問巨佬有沒有更好的解決辦法,跪謝….嚶嚶嚶
創建一張優惠券既能夠用戶手動領取也能夠滿足后臺人員人工派發,這樣設計合理的;人工派發更加靈活,適應于不同場景,可以的話,可以先建個用戶標簽體系,然后再根據標簽去發,效果會更好。
如果這樣設計的話,當優惠券被刪了或者修改了字段參數后復用了,對已有的優惠券活動數據會不會造成影響呢。
優惠券創建好了后,其他業務節點調用發券的接口就可以了。
優惠券前端界面UI模版,能做成配置化么
可以的。有種場景就能做成配置話,活動頁H5頁面自定義模板;
關于優惠券明細,后臺是記錄每個領取用戶的使用明細嗎?用戶數量太多的話查看也不方便啊??梢灾苯硬榭疵糠N優惠券的使用情況,以優惠券為主體不是以用戶為主體
嗯嗯,畢竟券都是幾萬幾萬的發
感謝巨佬分享,請問如果繼續按照巨佬的這個后臺設計思路,添加一個發放方式需求。比如:手動領取和系統派發。那么創建一張優惠券既能夠用戶手動領取也能夠滿足后臺人員人工派發,這樣設計合不合理呢?我感覺這樣有點多余,但是目前公司的需求想要這樣,請問巨佬有沒有更好的解決辦法,跪謝….嚶嚶嚶
巧了 我也碰到了,也是說手動和系統派發后臺可配置,但我個人也覺得有點多余,因為被動領取的優惠券,核銷概率會小很多,因為用戶自己領取之后他會大概有那么個印象:我有一張優惠券呢,試試下單會不會便宜些,如果是系統派發,即使短信提醒用戶,大概率也很難喚起用戶的購買需求;