鎖定模塊異常2怎么辦(模塊鎖定異常1)

鎖定模塊異常2怎么辦(模塊鎖定異常1)

前沿拓展：

---

積分體系連接用戶與產品，能夠有效引導用戶成長，將新用戶培養成高價值用戶。構建自有積分體系，目前已經成了眾多平臺都要做的工作。本文作者基于自己的實際工作情況，梳理總結了關于積分模塊設計的非常有價值的知識，與大家分享。

前一段時間接到任務，需要重新設計營銷中臺。這段時間空閑下來整理一下，僅供產品小白入門參考。自己趟過一些坑，本文如果可以幫到12個人也是很開心了。

想了一下，還是沒有把整個營銷系統拿出來分享，主要是考慮到各個公司的業務需求不同。我們現在是一家社交電商的公司，而電商營銷活動屈指可數。無非是簽到、抽獎、助力、搶券、紅包雨，紅包雨和搶券類似。

所以就單獨把積分模塊抽出來說一下。

積分：在某個平臺上流通的虛擬貨幣，具有價值的局限性。

現在的積分形式有很多種類，已經不是當年在PCWEB時代的的金幣，整個app就一個金幣。

積分可以輔助平臺提升活動運營效果，提升用戶粘性。主要是由于積分對于用戶來說，積分是一個對用戶行為可感知，可量化的獎勵。

所以jd，taobao每次雙十一、618大促的時候，都會做一個互動游戲，累計“紅包“，當然這里的紅包也是可以用積分的邏輯來實現。

先把積分體系理一理，主要分為積分基本信息（包括積分比例，積分的有效期等）、積分發放、積分消耗，積分風控。

由于我要做的是積分中臺，分為管理端和面向業務提供的功能接口。

一、管理端

要做一個積分，首先會想到積分的名字叫什么？接著就是積分的價值是什么，假如可以兌換成RMB值多少錢，消費1塊錢可以帶來多少積分？

那么這就是如何定義一個平臺積分，需要填寫積分基本信息。

緊接著就是用戶怎么領取積分、消耗積分？整理了一下管理端的內容如下：

可以看到除了用戶積分賬戶是無需管理界面的，那么只剩下積分管理、積分記錄、積分渠道。

1. 積分管理

積分管理按照積分id正序排序，無需分頁。積分管理支持創建新的積分、編輯積分、管理積分渠道、查詢該積分發放記錄。

列表顯示積分的基本信息主要包括積分ID、積分名稱、有效期、狀態、兌換比例。為了方便運營，還支持添加多個積分，適用于不同的活動的場景。

為什么有一個創建積分的按鈕？還要有多個積分？

例如今年雙十一的時候，我們可以看到這仨都是送喵幣，送小魚、送金幣的養成互動游戲。這些喵幣、小魚、金幣和主線積分分別是不同的賬戶體系，但是本質上都是積分。

而且這些積分的都有一個共同點就是統一的有效期，這些積分的有效期只有在大促的時候有效，過了雙十一就失效了。

所以在積分系統設計的是放開創建積分功能， 可以方便運營配合不同的活動形式制作一個獨特的積分，可以叫喵幣，叫金幣，甚至叫小魚…

當然我們也建議長期的積分不要太多，保持12個長期積分，其他短期積分輔助活動營銷。

2. 積分記錄

接下來就是每一個積分的記錄獨立分開，近30天的記錄清晰可查詢。根據時間范圍、記錄類型進行篩選，或者直接根據用戶ID或者手機號進行查找。

積分記錄之所以也做了管理端，主要是提供給客服查詢，方便處理客訴工單。

3. 積分渠道管理

積分渠道管理主要目的是更好的管理好積分，做好積分的風控工作。

積分作為流通在平臺的虛擬貨幣，如果被盜刷，損失是難以被追回的。因此在積分的發放前增加了積分渠道的限制，積分渠道可以由運營同學來申請，生成一個唯一的令牌（Token）。

調用積分發放的每一場活動，都依賴這個Token才能調用成功，正常的發放給用戶

4. 創建積分渠道

每一個渠道還可以單獨設置總計用戶可以領取最大值、單個用戶每天領取的最大值、每天可領取的最大值。

把所有的風險劃分到每一個活動，出現問題的時候，根據Token即可快速定位到問題活動，也不會影響到其他活動進行。

一個支持多積分的管理端就做好了~

二、面向業務積分接口

積分中臺還有一個重要的就是面向業務提供接口，這些接口通常具有通用性和功能性。積分系統在千變萬化的營銷活動面前，通用性是真的很重要的。

梳理了一下如下5個接口：

積分系統對外需要發放積分、消耗積分、回退積分、回收積分、查詢用戶積分記錄，以及鎖定積分這5個接口。

回退積分場景：用戶積分兌換某件商品后，但由于商品缺貨等原因導致兌換失敗，需要將用戶消耗的積分，重新退給用戶。回收積分場景：用戶在參與下單某商品送積分后，對某商品進行退貨操作，需要將贈送用戶的積分收回。

主要就是發放積分、消耗積分和查詢用戶積分記錄，這3個積分接口為核心接口，另外3個回退積分、回收積分、鎖定積分的使用頻率會較低一些。

因為通過發放積分和消耗積分這兩個接口實現對用戶積分賬戶余額的增減就能實現回滾積分和回收積分的效果。

為什么還要把這些接口單獨拎出來呢？其實主要是為了精細化運營，在數據統計的時候可以拆分的每一個細化場景來分析用戶的活躍情況和使用頻次。

通常我們在做積分兌換商品的時候，活動商品庫存是有限的。為了確定兌換某商品，我們通常會先扣減所需積分然后在進行占該商品庫存。當扣減庫存失敗，就會啟用回退積分，將兌換時候扣減的積分，還給用戶。

在這個過程里，用戶的賬戶積分增加減少積分記錄會影響我們統計的時候準確性。

所以可以增加一個鎖定積分積分，單獨將使用積分消耗的行為拆分成先鎖定積分，再將這部分積分消耗掉。業務方總是會背很多KPI，為了KPI也會提出很多千奇百怪的正常需求。

遇到一個這樣的需求場景，某良零食供應商聯合搞活動，使用到了積分，但是供應商希望“我發的積分只能用到我的店鋪”！

這種情況，一般建議再用積分系統的管理端再給供應商新創建一個積分，叫“豬肉條”、“牛肉干”、“辣條”……都行。

當時平臺積分還沒有比較成熟，需要借助供應商的商品來提升平臺積分的價值。綜合衡量了一下，大寶靈機一動，既然積分可以鎖定，那就給這部分鎖定的積分一把唯一的鑰匙（Key）吧～

鎖定積分的時候就變成了2種類型：

指定對象消耗不限對象消耗

指定對象消耗指鎖定積分的時候，會對應生成一個唯一的key，key可以支持代表供應商或者代表活動（這里的可以直接用渠道code作為key也可以），并且進行返回；當實際要消耗積分的時候，時需要傳對應生成的key，才能對這部分積分進行消耗。

而且被“指定對象消耗”類型鎖定的積分，如果過了積分鎖定期，用戶這部分積分就自動作廢了。

不限對象消耗就非常好理解了，就是鎖定了積分之后，大家都可以使用。這種“不限對象消耗”的鎖定類型，鎖定后超過積分的鎖定期，積分會被自動釋放。

但是對于積分消耗的場景就比較混亂，如果單一消耗場景的時候可以使用。

積分鎖定期：積分鎖定的有限時長。

關于積分鎖定期，如果系統由用到積分鎖定這種復雜的功能時候，就需要增加一個鎖定期的機制。因為如果發生未能消耗的情況，積分會一直處于鎖死的狀態，所以增加超過鎖定期可以自動解鎖或者作廢的機制。

“指定對象消耗”類型的鎖定期一般與活動有效期保持一致?！安幌迣ο笙摹暗逆i定期一般較短，可以系統配置默認24小時，可以放在積分基礎信息的管理界面支持修改。

積分系統交互流程圖

大寶沒有WPS的會員，流程圖最多只能添加這么多圖形，以至于就把積分回退和積分回收畫在了一起……大家湊合看一下～

消耗積分原則是優先消耗被鎖定的積分，其次消耗快過期的積分。由于大寶覺得用這種積分快過期方式促進用戶消耗積分，對于平臺營銷能力并沒有提升，沒有使用價值的積分用戶還是會任其作廢。

不過期積分還可以讓用戶一直攢著，留著兌換大獎，提升用戶留存。所以沒有設計積分先領取先過期的機制，我們平臺積分都是統一的有效期，就不存在優先快過期的積分。

三、積分數據統計

積分系統完成后，需要根據每一天積分的發放、消耗的記錄進行統計。

1. 關鍵指標消耗比=積分消耗數/積分發放數；人均持有積分數

消耗比主要是為了分析積分發放和消耗是否合理。積分價值在于不能過發也不能沒有地方消耗，所以積分主要的核心指標就是消耗比。

人均持有積分數主要是初期重要的指標。初期用戶持有積分人數不是很多，主要統計用戶持有積分情況，可以分析平臺積分活動的參與度和用戶活躍。運營同學根據用戶持有的積分數量制定合理的積分發放和兌換規則，降低用戶參與門檻，擴大用戶群。

2. 觀察積分數據

我主要分成3個表格來觀察積分數據情況。

（1）積分概覽表

（2）積分持有情況表

（3）積分渠道情況表

本文由 @戴大寶 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

拓展知識：