寫這篇文章的目的是分享下本身在規劃SDK代金券系統時候一個大概的思路，同時讓本身知道做了什么如何去做，也在各位大牛們身上收獲不少，自然希望能夠幫手到其他人。

ps：此代金券系統的規劃是建立在SDK的產品上

一、代金券需求

近期，公司的游戲產品需要做折扣系統，目的提高付費率。簡單來說就是玩家購買游戲商品獲得必然的折扣。

二、關于折扣形式

這里折扣形式可以有：

直接在產品進行打折；發放活動券；提供充值返利；代幣等。1.直接在產品進行折扣處理

這種方法最為簡單，無論是技術實現還是產品角度都是最便利的，但是用戶體驗感也是最欠好的。用戶很直不雅觀看到有打折，打折僅僅打折并沒有拿到實際的東西，用戶得不到真實的感知質量，這就是用戶感知性；

2.發放活動券形式

這種是我們目前采用的一種方法。考慮到滿足用戶的感知性別的活動券還能夠完善游戲產品的折扣體系，為以后其他的游戲產品打算做折扣活動的時候埋下基礎。

3.充值返利

我們對于這種返利通常會面向大R用戶做的線下返利。簡單來說就是買贈活動，金錢上并沒有少，反而贈送一些有價值的產品。但是并不是每一個用戶都會需要，同樣這種形式無法滿足遍及大眾用戶的需求。

4.代幣

所謂代幣就是和QB同一個道理。這種情況比較復雜，針對公司目前支付體系以及游戲產品的充值體系，同樣排除這種做法。如果條件允許，還要考慮代幣和游戲幣之間的權重。

三、代金券需求1.代金券需求分析

在上面折扣形式中，我們經過一輪分析后決定采用活動券作為折扣活動的一種形式。我們將采用代金券這種券類進行設計。（折扣券分優惠券，代金券，滿減券。大同小異，效果都一樣）

所以有如下代金券的需求分析：

角色：玩家場景：游戲內購買商品路徑：玩家購買商品后選擇相應的代金券進行支付

（代金券屬性分析）

代金券名稱：按照差別的活動或者產品名稱自定義，或者僅作為后臺生成代金券的一種記錄手段來源：代金券是通過何種手段發放到玩家手里。線上線下？兌換碼？后臺領取？價值：代金券的抵扣金額數使用范圍：即代金券只能在特定的產品或者渠道上使用有效時間：顧名思義發放規則：這里指玩家能夠自動分配或者手動領取。而狀態體現代金券的領取狀態。使用規則：指的是滿足必然的條件才能夠生效。而狀態體現代金券的使用情況，這里說明下可用：指的代金券可用已綁定：指的是代金券與訂單號綁定（已綁定狀態還可分訂單的狀態進行再區分：玩家未付款，玩家超時未付款）已使用：代金券已經使用，訂單號已完成已失效：指時間過期

8.權重：每個代金券只能綁定一個交易訂單號；每個代金券只能使用一次

（代金券功能需求規劃）

在畫腦圖之前先YY下代金券該有的功能需求，包羅前后端。這里不考慮數據庫之間的交互模塊。將所有滿足代金券功能需求的模塊畫進去后，再進一步分析出哪些是須要的，不須要的，哪些是MVP的功能。

當然，你會遇到以下的問題。然后需要解決。

玩家點擊代金券，無法領取玩家使用代金券后超時未付款，下一步如何處理玩家在哪里領取代金券玩家在哪個地方選擇代金券代金券重復領取了咋整代金券數量不夠代金券怎么設置生效時間，上架時間，發布時間

……

TIP：所有有可能出現的問題，都必需進行窮舉。不停窮舉會不停發現新問題，產品功能的完善也就更進一步。這里的窮舉不分前后端，是整體的窮舉。包孕差別的角色在使用該功能時會產生什么樣的問題，會遇到什么困難，需要如何解決。

2.代金券后臺功能規劃

代金券系統后臺功能主要4大功能模塊：創建模塊，搜索模塊，狀態透視表以及數據分析。

1.創建模塊是第一步，這里需要考慮到前端展示。

讓用戶能夠更直不雅觀的領取和使用代金券。創建模塊等于賦予代金券屬性，上面提及的代金券屬性分析中都必需從這里創建。別的這里還需要考慮代金券的上架時間，明確發行代金券的操作人員，以及設立一個數量預警功能。

2.搜索模塊：按照差別維度在代金券系統中搜索想要獲取的信息

3.狀態透視表：后臺操作者想要看到目前代金券的一個使用情況就通過數據表進行表達。

數據表應該包羅的最基本的是該代金券目前的使用情況，期限，數量以及可操作的功能

4.數據分析：數據分析是作為運營的重要指標，該批代金券是否對產品帶來收益或者該代金券在本次活動是否有效果。

都可以通過分析代金券的使用情況，分析代金券過期未使用或者綁定未使用等用戶行為，對后期做進一步的用戶指導。

（創建代金券模塊，相關字段原型圖）

?四、前端規劃代金券前端規劃

標簽：鹽城 九江 林芝 東營 烏魯木齊