編輯導語： 當一個企業(yè)發(fā)展壯大，企業(yè)的產品矩陣會越來越豐富，可能會面臨“效率低”和“體驗一般”的問題，這種時候便需要建設用戶中臺，從而提高效率及體驗感。本文作者分享了建設用戶中臺的經驗和想法，感興趣的小伙伴們一起來看一下吧。

筆者看到網上關于用戶中臺的分享比較少，想著分享一下建設用戶中臺的經驗及想法，和各位同行交流探討。

企業(yè)發(fā)展壯大，企業(yè)的產品矩陣會越來越豐富，擁有更多app、小程序等。在這個過程中，可能會面臨兩個問題：

1. 效率低：比如，各個app團隊分別開發(fā)所在業(yè)務的用戶體系，重復造輪子重復開發(fā)，導致浪費太多沒必要的研發(fā)成本及導致研發(fā)效率低下
2. 體驗一般：比如，用戶使用同一企業(yè)不同的app，需要分別注冊登錄，用戶體驗一般

那么我們就需要建設用戶中臺，統(tǒng)一管理公司里面的不同產品的用戶賬號體系，從而提高企業(yè)效率及用戶體驗。同時，建設用戶中臺及其他業(yè)務中臺，企業(yè)可以搶占市場先機實現(xiàn)戰(zhàn)略價值。

當企業(yè)發(fā)現(xiàn)新的業(yè)務機會，我們可以借助用戶中臺及其他業(yè)務中臺迅速上線新產品，比其他沒有中臺的企業(yè)更快搶占用戶，形成市場門檻獲得市場領先優(yōu)勢。

一、用戶中臺架構

筆者基于自身業(yè)務實踐及學習交流梳理的用戶中臺架構如下圖所示，用戶中臺主要包括賬號、認證、權限、安全風控/審計這四個模塊。

不同企業(yè)基于自身業(yè)務情況，企業(yè)需要搭建的用戶中臺覆蓋的功能范圍及功能顆粒度有所區(qū)別，各位讀者可以根據(jù)自身企業(yè)情況來搭建合適自己所負責業(yè)務的用戶中臺。

筆者建議讀者可以根據(jù)自身企業(yè)業(yè)務復雜度、應用數(shù)量及用戶量級來綜合考慮搭建用戶中臺的功能范圍及顆粒度。一般來說，企業(yè)業(yè)務越復雜、應用數(shù)量越多及用戶量級越大，企業(yè)需要搭建的用戶中臺功能就越多及功能顆粒度就越細。

筆者曾通過建設用戶中臺統(tǒng)一服務公司旗下APP、PC、H5、小程序等前臺應用及應用背后的億級用戶，大大提高了效率及用戶體驗。

二、用戶中臺具體搭建

前文已說明用戶中臺的架構/框架，本章節(jié)則展開說明用戶中臺各個模塊的情況。

1. 賬號

賬號的狀態(tài)主要分正常、凍結、注銷。一個應用里面大部分賬號是正常使用的賬號，若應用監(jiān)測賬號有異常行為則對賬號進行凍結限制賬號使用，若用戶不想繼續(xù)使用應用則可以進行注銷。

而賬號包括用戶畫像/標簽、會員體系等。企業(yè)可以根據(jù)用戶畫像/標簽，對用戶進行更精準的用戶數(shù)據(jù)分析，從而進行產品策劃、運營、營銷等行為以達到提高產品的活躍度、留存、轉化率、營收等目標。

用戶畫像/標簽主要包括人口統(tǒng)計學標簽、商業(yè)標簽及行為標簽，其中，人口統(tǒng)計學標簽主要指用戶姓名、年齡、地域、學歷、收入、婚況等。

商業(yè)標簽一般基于RFM模型：

• 最近一次消費 (Recency)
• 消費頻率 (Frequency)
• 消費金額 (Monetary)

行為標簽主要記錄用戶在應用進行的注冊、登錄、瀏覽、轉發(fā)/分享等行為。

會員體系包括會員等級、會員積分、會員權益。應用可以對用戶的行為劃分成不同的積分，比如登錄獲得5積分，轉發(fā)行為獲得10積分。

用戶通過不同積分或者充值不同金額的錢，獲得不同等級的會員，比如青銅會員、白金會員、黃金會員等。同時不同等級的會員會有不同的會員權益，一般來說，越高等級的會員的會員權益越多/價值越大。

2. 認證

應用通過進行用戶資料認證從而確保是用戶本人進行操作或者提高信息/資料的真實性。

用戶在進行一些敏感操作或者重要操作需要通過實人認證確保是本人在操作，比如在一些政務平臺查看自己社保記錄這些敏感信息。而用戶進行實名認證、學歷認證、房產認證、車輛認證、納稅認證等從而確保用戶姓名、學歷、房產、車輛、納稅/收入的真實性。

一般來說，對于大部分企業(yè)/應用，只需要實人認證、實名認證。而婚戀行業(yè)、金融行業(yè)則需要更多認證，如學歷認證、房產認證、婚況認證等。

3. 權限

權限的設計一般采用RABC模型，RABC指基于角色的訪問控制（Role-Based Access Control）。

RABC模型認為授權實際上是Who、What、How三元組之間的關系，也就是Who對What進行How的操作，也就是“主體”對“客體”的操作。

• Who：是權限的擁有者或主體（如：User，Role）
• What：是操作或對象（operation，object）
• How：具體的權限（Privilege）

同時角色設計包括角色、角色組，多個角色的集合可以成為一個角色組，角色組可以擁有多個角色的權限集合，以及角色之間可以有權限繼承的關系（比如子角色繼承夫角色的權限，同時增加新的/其他的權限）。

對大部分企業(yè)/應用來說，只需要角色，不需要設計比較復雜的角色組模型，只有角色比較多/比較復雜的應用/系統(tǒng)才需要角色組的設計。

而權限類型可以劃分成功能權限及數(shù)據(jù)權限。功能權限是指這個角色可以打開哪些模塊的菜單/頁面，可以進行哪些操作（新增、刪除、修改、查詢、轉發(fā)/分享等）；而數(shù)據(jù)權限則指這個角色打開這個菜單后能對哪些范圍的數(shù)據(jù)進行操作，比如只能查看本人的數(shù)據(jù)，只能查看部門的數(shù)據(jù)，可以查看所有數(shù)據(jù)等。

4. 安全風控/審計

本章節(jié)最后才介紹安全風控/審計模塊，并不是說安全風控/審計模塊是不重要的。恰恰相反，安全風控/審計是非常重要的，是整個企業(yè)/應用生存的基石，出現(xiàn)安全問題可能會涉及法務危機/公關危機，甚至損失掉用戶對企業(yè)/應用的品牌信任感，嚴重情況下還可以導致應用下架/企業(yè)破產。

安全模塊主要包括偏功能層面的安全設計及偏技術層面的安全設計。

在偏功能層面的安全設計中，密碼/密保主要是保護用戶的密碼安全性；賬號綁定主要是方便用戶多種登錄方式，同時幫助用戶通過其他方式找回賬號密碼及驗證本賬號的安全性；異常提醒是非常重要的，通過對用戶異常行為的檢測從而避免用戶被盜號從而損失財物等情況。

在名單管理中:

• 黑名單：可以設置一些惡意賬號為黑名單，從而限制這些賬號登錄使用等
• 風險名單：當一些賬號存在異常使用風險，則設置這些賬號為風險名單，從而限制這些賬號敏感操作（如支付、轉賬等操作）但其他普通操作還是可以使用
• 白名單：白名單的主要應用場景，如應用要測試/灰度一些新功能，則把這些賬號設置為白名單，然后這些賬號可以提前使用這些新功能

在偏技術層面的安全設計中，企業(yè)/應用可以完善訪問控制、入侵防范/防撞庫、數(shù)據(jù)加密、安全監(jiān)控等能力。同時從研發(fā)管理角度，要求工程師在研發(fā)過程中的技術安全規(guī)范，并且進行安全排查盡可能在應用上線前/出現(xiàn)安全問題前排查出安全風險。

三、后記

本文為筆者關于用戶中臺的淺見，若各位同行在實際工作中對建設更高效率，或者更好用戶體驗的用戶中臺有其他建議，歡迎聯(lián)系筆者進行交流探討。

作為一個產品經理，我們都致力于為所在業(yè)務提供更好的產品方案，祝閱讀本文的產品經理們都能追尋內心的產品情懷實現(xiàn)產品價值，感謝大家的閱讀！

本文由 @skyland 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議