電商會員等級制度總結

    在電商平臺中加入會員等級機制，從而使不一樣等級的會員擁有不一樣的會員權益，如免運費、折扣率、贈送優惠券等內容。其中會員權益須要獨立維護制定，並與會員等級創建關係。

    下面總結一下在創建會員等級時的一些比較標準的模式。

    在創建會員等級時，不管名稱使用簡單的lv一、lv2或是黃金會員、鑽石會員等，本質是不變的，對於數據自己只是簡單的層級關係，咱們須要關注的無非是它的等級排序、等級達成和「租賃」日期。

    等級排序：正常且符合邏輯的會員等級制度首先應該是擁有良好等級標準的，如1之上是二、再往上是3同樣，階層清晰讓用戶一目瞭然，同時對各階層的會員劃分好能夠享受的權利和義務，這裏講的權利即達成該等級的會員能夠享受的特權或者優惠條件，所謂義務又意味着如何達到這個階層，好比積分制度的引進？或者直接花錢購買會員等級。

    等級達成：對於會員如何升級到某一等級，一般狀況下有兩個簡單的處理辦法：

    1：積分系統，即引進積分功能，當會員我的帳戶中積分累計到某個閾值便可以達成該等級，這意味着會員等級管理中必須引入積分閾值的設定。而積分累計則取決於各類因素，好比電商能夠爲商品設定消費金額轉積分比，當用戶消費多少錢時能夠轉換爲多少積分存在於帳戶上（京東）。對於論壇，積分則由用戶發言、回帖、回覆量等一系列可配置的內容取決。因此具體如何累計應該根據業務類型綜合考慮。另外還有一點須要注意：積分是否清零？須要根據本身的需求去確認。

    2：會員購買制度，對於一般一些B2B、B2B2C的電商來說，會員購買制度是簡單粗暴且有利可圖的方法。將不一樣的會員等級明碼標價，告知商戶或者客戶花多少錢享受什麼權利，這個不用多說，只要創建一個購買渠道便可，須要維護的內容比積分制度更少。

    這裏有一個須要注意的地方：高等級的會員是否能夠購買低等級？須要根據實際狀況考慮，相信沒有人會與錢過不去，若不容許購買天然簡單，但若容許了則須要考慮有效日期的覆蓋問題。

    租賃日期：之因此起這個名字是爲例經過「租賃」二字來反應會員等級的時效性，一般咱們不會讓某客戶一直處於某一個等級。除非這個等級對於咱們來講可有可無，或者與咱們的利益並不衝突，對於商家爲用戶等級提供一次性買斷的類型，咱們不作討論。

    對於能夠購買的會員，一般須要維護會員的開通日期和截止日期，一般狀況下在給予用戶的購買渠道中能夠選擇開通的會員等級和開通日期，1月、3月、半年、一年、自定義等。咱們須要明確知道用戶想要購買的等級和想要購買的日期，以此爲依據來計算用戶須要支付的金額（這其中可能會有某些優惠活動須要額外維護，可是咱們不討論這一塊）。

    例如：一個新註冊用戶，在咱們的系統中設定的會員等級爲lv0 （此時他沒有任何權益），當該客戶去購買一個月會員時，咱們只須要在他支付成功之後對其會員等級進行修改，並記錄好該會員的到期時間，對於新用戶來講，開通會員時一個從無到有的過程，那麼開通時間便是開通當日，截止時間只須要在日期上直接累加。   

    另外一個場景：當白銀會員升級黃金會員的時候，這裏因爲須要考慮用戶心理，增長了一些額外的複雜性。咱們不可能直接將用戶的會員等級從白銀變成黃金，而直接在截止日期上累加，這樣可能會致使還有一年到期的白銀會員直接變成超過一年的黃金。而咱們也不可能直接由開通日期計算，從而將用戶還有一年纔到期的白銀會員覆蓋掉，由於這樣未免有點粗暴，正常的用戶也不可能接受。因此這裏須要綜合考慮。

    對於以上場景的問題一般的咱們再次將其分解爲多個場景。而這些場景中，最重要的一個問題是——當前會員等級的截止日期距如今還有多久？

   場景1：今天是06月29日，用戶的白銀會員於07月05到期。當用戶今日開通黃金會員，咱們能夠粗暴的將截止日期設定爲07月30，由於咱們判斷該會員的原身份即將到期，直接採用購買日做爲計算截止日期的條件，這一點客戶從心理上能夠接受。

    場景2：可是若是該白銀會員的是12月30到期，此時用戶選擇開通黃金會員則須要作更多判斷，再進一步將條件分解，由於這種狀況是不可能同上一種同樣粗暴的將購買日當所計算條件。例如用戶在此時只購買了一個月黃金會員，如果同上面同樣計算的話，那麼用戶會損失半年的白銀會員，這一點是沒法接受的。

    對於這種狀況，最簡單無腦的解決方式——禁止用戶在會員到期前的或者到期前的必定日期購買或者提高會員等級。但這樣無疑是商戶在與本身的錢包過不去，非特定條件通常不作考慮。

    場景2的分解：

       2.1：若用戶原等級剩餘日期遠小於本次開通後的日期（場景1因爲用戶可接受因此忽略），能夠引進「補差價」的機制，很簡單，即：當前須要支付的金額減去 自今日起到原等級到截止日換算成的金額（固然，真正是否須要補差價機制，須要綜合考慮）。

       2.2 ： 若原等級剩餘日期大於本次開通後的日期，此時最好的解決辦法是創建起用戶一對多的等級記錄，將高等級的優先級提早，當高等級過時後低等級的繼續運行直至結束。