編輯導語：使用者運營平臺的搭建可以幫助企業做好資料採集，進而提供底層決策和服務給運營或其他人員，進行有效的使用者管理，幫助企業實現精細化運營。本篇文章裡，作者就總結了一份使用者運營平臺設計指南，不妨一起來看一下使用者運營平臺的產品設計邏輯。
“使用者畫像”、“使用者標籤”、“大資料”這些名詞是我們近些年來常聽的詞，可是這些詞卻很難直接的產生價值，我們都知道大資料有用，畫像也有用，但到底怎麼用？又怎樣具象成一個產品卻很少人能夠說清楚。
如何採集資料，形成服務再到供給運營，這也是這篇文章想分享的核心。
在市場上神策、易觀數科會將其稱之為智慧使用者運營平臺。這篇文章會和朋友們闡述使用者運營平臺的產品設計，幫助大家理解其
底層支援和產品表現。
產品設計的講解將分解為3部分，分別是
：選使用者、做運營、看效果。
一、產品建設背景
產品建設的背景如下：
1。 資料不可用
資料不可用原因有很多種，沒有埋點落庫是比較好理解的。
其次則是資料分散，
沒有將分散在不同業務的使用者資料進行關聯
，這會導致使用者畫像不夠立體，甚至無法識別是否是同一使用者。
假設我們無法識別使用者在成交前的關鍵路徑，則很難分析其決策偏好及流失過程，運營的深度也會受限。
而許多資料的使用方式也僅停留於淺層的報表應用，資料分析很重要，但分析後也要將其運用於運營。
2。 運營無法管理
這一點指的是大多數企業運營管理都強依賴人力，缺乏平臺沉澱運營邏輯。當人員變動，依靠人力、程式碼維護的舊邏輯會很容易被忽略，而運營策略的跟蹤、改進就可能不了了之了。
如何讓不同的角色迅速瞭解自身業務對使用者的運營策略和效果，這也是建設的目標之一。
3。 運營成本高
運營成本高，原因是投放、干預類的需求非常高頻，但卻每個需求都需要經過產品、研發、測試及發版的過程，就算再高的上線效率，上線的週期也會滯後。
複用率低，則是由於依賴研發的運營策略很難規模化。
4。 效果追蹤困難
效果追蹤困難主要的原因是較難形成統一的業務標準，評估標準不同則無法對比。我們之前聽過一個段子彙報時每個部門的ROI都是正的，但企業卻在虧損。雖說是段子，但卻很真實。
標準不一，只看正向指標不看負向指標，那當然人人都是喜報。每個業務的形態都不一樣，標準很難制定，那能否儘量的去找到運營的同類項呢？
這4點就是使用者運營平臺想解決的問題了，接下來會進行產品核心架構解讀。
二、產品架構解讀
使用者運營平臺的產品分解為：
選使用者、做運營、看效果。
將其分解為產品術語則是：
在圈選目標使用者並設定運營規則，基於運營渠道傳送指定運營內容，效果追蹤後再進行自助最佳化調整。
對上圖的解讀如下：
使用者圈選：選擇訪問商品頁未成交，且有工作的男性。
運營規則：今天晚上8點對使用者進行風控判定，如風控透過進行A/B實驗，1組由推薦演算法決策推薦商品，另一組由運營設定渠道和商品。
運營渠道：選擇彈窗資源位渠道。
運營內容：設定彈窗落地頁跳轉商詳頁。
效果評估：投放後追蹤漏斗資料及成交資料。
選使用者對應使用者資料平臺，做運營對應規則引擎和使用者互動平臺，看效果是分析中心。
大致理解了所提供的運營服務，我們再逐步理解這核心服務對應的
底層支援和產品表現。
三、使用者運營平臺：選使用者
選使用者對應前文的痛點是資料不可用，我們要讓資料可用，也要解決資料分散的問題，
將分散在不同業務的使用者資料進行關聯
，識別是否是同一使用者。
最終實現
視覺化選取目標使用者。
1。 底層支援：使用者資料平臺
要讓資料可用，需要建設的是使用者資料平臺，它是一切的開始。哪怕不用於實際干預使用者的運營，進行畫像分析、個性化推薦也離不開它。
從使用者運營平臺的角度，我們要去採集全站的資料讓資料多元客觀，然後去過濾掉無效、異常的值，在關聯成為同一使用者，保障畫像更為立體。
最後則是將一條條明細的資料，加工成可用的圈選條件，並將其供給運營。
理解表現層之前先了解其底層支援，知其然也知其所以然。
1）資料採集
運用資料的前提是擁有資料，採集資料則是第一個環節。人工採集就是上傳資料匯入資料庫，自動採集則是埋點上報、第三方資料傳輸相關的工作。
2）資料處理
第二個環節是資料處理，主要包含了
資料落庫後的清洗、合併、去重、加工
4個步驟。
清洗指發現並修正資料中可識別的錯誤，包括檢查資料一致性，處理無效值和缺失值等。
合併和去重概念，關於資料上的理解可以查閱的這篇文章：《Tableau基礎·如何合併你的資料？理解與邏輯（上）》，Tableau已經描述的非常全面了。
合併的目標有2個，一方面是關聯不同業務的核心資料，讓使用者畫像更為立體。
另一方面，在離線查詢大批次的時候查詢速度能夠更快。
不同的資料儲存在不同的表，我們希望在查詢訂單時同時查詢使用者的關注資料，常見的辦法是連表查詢。
但這種方法只適合小量的資料，當資料量達到百萬級開始連表查詢就會非常慢了，而這個時候就會用到
寬表，
它可以理解為一張擁有大量資料欄位的表。
例如在訂單表增加使用者的公眾號關注資料。
加工邏輯，則涉及到條件的組合。
我們的原子資料如：年齡、性別，這是可以直接使用的查詢條件，但如果我們想要的是“中年男性”這個條件，就涉及到加工了，它能讓我們查詢資料時更加敏捷。
3）資料管理
資料採集、處理後下一個環節是資料管理，它是資料服務的基礎，
它負責定義資料標準，管理資料許可權，並保障資料質量。
標準是指，我們怎麼定義一個完整的資料，需要有名稱、值型別、取值的範圍、加工的邏輯等。而許可權則決定這個資料歸屬於誰管控，密級程度又決定了不同角色的操作，包括讀、寫以及使用。
最後的質量部分則是透過對應的監控措施保障資料質量，
資料是否及時更新，更新的進度和速度是否符合預期，生成的資料是否符合規範，量級波動是否達到了告警線
。
假設一切正常，它又
是否正常的被下游消費，消費過程又是否存在阻塞。
4）資料服務
資料服務，這個詞廣義的說資料的採集、處理、管理都是一種服務。在這裡特指的是供給實際運營的服務，例如：人群服務、風控服務、運營服務。
風控服務
具備了資料，就能夠對不同的場景制定不同的風控評分規則，用於識別黑產、金融產品售前評估、金融產品的定價。異常監控則指當號碼、賬戶發生了凍結等情況可能造成使用者的違約，在金融產品層面做預警。
運營服務
智慧推薦實質也依賴於資料平臺，透過使用者的特徵輸出推薦結果。RTA則運用於廣告，基於特徵決定是否參與定價。
人群服務
人群服務會運用於使用者運營平臺的“選使用者”環節，資料的管理能夠提供可選擇的使用者條件，進行前端渲染。
而選完條件後則涉及資料的去重，不同人群包之間的計算，在最後的運用環節又涉及到了加解密。這個部分在下文會詳細描述。
描述完了底層支援，下一個部分就是使用者運營平臺的表現層“使用者圈選”，那資料平臺到底是怎麼為“使用者圈選”提供能力的呢？
2。 產品表現：使用者圈選
在選取使用者時須考量的產品功能為：
圈選方式、圈選頻次、圈選條件及人群服務。
實質上這4個功能的底層支援都來自於使用者資料平臺，使用者運營平臺則負責服務的運用及表現。
1）圈選方式
條件選取
這是在
視覺化、自助化
選擇使用者條件後，透過與其取值範圍進行比較經計算生成人群資料包的一種形式。
一般來說，具備抽象為視覺化條件的資料使用較為高頻，資料準確性較高。
它的底層原理是對條件和計算進行標準化，然後拼接類似SQL的資料查詢語句。
智慧選取 & 自主上傳 & SQL提取
智慧選取、自主上傳、SQL選取，是對“條件選取”的補充。
智慧選取主流分為2類，1類是使用者規模無法滿足要求時
對使用者進行相似度計算，從而擴大使用者的規模。
另類的運用場景則是
運用演算法模型選取使用者，結合運營的效果資料對模型進行調優，不斷尋找最優的高響應人群。
SQL選取與條件選取的原理相近，它主要運用在資料未被標準化，無法視覺化選擇的場景。
另一個場景則是追求更快的查詢速度，因為標準化的查詢語句追求的是通用性，查詢速度對比自主撰寫語句時大多較慢。
2）圈選頻次
單次提取
單次提取，指一次性提取資料，當前時間提取後資料
不再發生變化。
運用的場景多為在做運營實驗，而運營實驗的效果還不夠好，暫時沒有固化為標準的運營方案；另一個場景則是使用者運營的規模資料量大，擔心投放時再取數其時間過長，先提前提取資料。
動態提取
動態提取，指相同的條件在不同的時間提取。這種情況，基於資料的時效性，其資料可能會發生變化。
常見於定期固定的運營計劃，如：使用者成交10日後贈送積分。
自主上傳則沒有動態提取這一說法，都是一次性的操作。
3）圈選條件
下方的互動僅面向於條件選取，而SQL、上傳、智慧的互動都是不同的表現方式。
條件的來源主要有4種，除了介面上報都應來源於使用者資料平臺所管理的資料，然後再
基於其資料標準，渲染前端的頁面。
實時事件：
主要面向時效性要求高的場景，是使用者實時發生的行為，例如使用者訪問某頁面。
介面上報：
實質上是非標準化的實時事件，一般在臨時性的活動會使用，如活動任務完成。
使用者特徵：
對時效性要求低，一般用於定時的運營，且無須查詢使用者的關聯資料。
寬表字段：
概念與使用者特徵相近，但主要用於資料時效性要求低且需查詢使用者關聯資料的場景。
在這裡額外描述一下關於“使用者特徵”和“寬表字段”的區別，詳見下圖：=
關於非實時的查詢條件主要分為寬表字段及使用者特徵。
為了能夠快速地查詢更多使用者資料，會將使用者資料基於userId整合在一張資料表中，由於儲存了大量不同業務欄位，也稱之為寬表
，如：在訂單表基礎上增加使用者年齡、性別等欄位。
寬表字段是明細資料，資料量多意味著查詢的速度會受限，但你也能迅速地提取其關聯資料；當需要
快速進行點查詢且不需要使用者的關聯資料時，則會使用使用者特徵。
例如：需要對前一日關注公眾號的使用者併發放簡訊，會使用具有明細資料屬性的寬表字段，從而獲取其手機號。但如果是在活動的頁面，需要實時判斷使用者是否關注從而引導使用者關注，則會使用使用者特徵。
理解了條件的來源，下一個部分會介紹條件的比較方式，它和資料的值型別有關。前端頁面也應基於值型別渲染比較條件。
時間條件一般不會進行列舉，因為日子一天天的在過，很難將它數清楚。
其對應的條件選擇互動式日曆選擇器或日曆範圍選擇器，而動態時間則一般使用T+N的形式，在這裡T指的當時（一般為天），而N也可以為負數。
例如：關注時間=T-1，意思為1日前關注的使用者。
而數字、字串的比較方式都相對接近，只是數字和時間能夠有“大於”、“小於”這類的比較方式，但字串沒有。
4）人群服務
前面的部分描述的是如何選取使用者，而這一部分則是選了後還要做的事情。其執行流程如下：
透過條件查詢得到了人群包，然後對不同人群包進行交併叉相關的數學計算。在計算後進行資料去重，最後再查詢這批使用者的資料提供於內容話術及介面使用。
接下來詳細介紹下這幾種服務：
交併叉
去重
去重就好理解了，核心原因是防止資料重複，避免因資料重複在查詢資料時浪費資源。
關聯資料查詢
這裡分別在內容話術和介面使用提供2個例子。
對於內容話術，我們推送了一批待續費保單的客戶給予售後部門進行引導續費，但如果需要能夠指導策略，還需要給予售後關於的保單詳細資訊，如：保額、保費、投被保人關係等。
而介面使用，則與呼叫介面要求的入參有關，如風控介面一般會需要使用者的身份證和手機號等。
四、使用者運營平臺：做運營
產品和運營的工作主要為
策劃和執行
，而痛點也由此而生。
策劃的痛點是過往的邏輯難以追溯，很難能體系化地瞭解過往的運營思路，過往面對誰做了什麼事效果如何，當前又是否正在執行？我們的新方案總是從零開始，需要重新地踩過往的一個個坑。
而執行痛點則是要上線一套成體系的運營方案鏈條太多，不同任務完成的方式不一有的需要配置有的又需要研發，不僅介面人不同，上線的週期即慢又零散，非常依賴於專案管理的能力。
有沒有一個方式能夠儘可能地讓多變的運營規則實現配置化，讓運營能夠實現線上管理呢？
這裡的解法是
規則引擎負責運營規則的組合，而互動平臺則提供組合的內容，再提供不同運營視角的管理檢視以及自助化的配置工具。
這2者如果能夠做到極致，那就是no-code。
1。 底層支援：規則引擎與使用者互動
1）規則引擎
規則引擎業界也稱自動化營銷平臺，規則引擎這個名詞有點抽象，不妨理解為但運作一件事的規則或邏輯。
這裡又來到了耳熟能詳的的5W2H法環節，規則引擎是什麼時間對什麼人在什麼地方以什麼方式做什麼事（5押）。
什麼時間做和對誰做是觸發條件，對誰做在實時事件觸發的場景，例如使用者簽到立即下發獎品，這種情況事件即是觸發條件又是判斷條件的一部分。
判斷條件的本質是過濾，例如過濾昨日簽到使用者中的黑產使用者，除了使用者本身的特徵，我們還會接入風控、推薦等介面。
流程控制從計算機運算角度是改變流程執行順序的指令，淺層的理解為判斷條件和執行條件的銜接器。
在實際運營中不一定每次判斷生效都會立即執行，會加以時間等待或者分組執行。例如：當用戶訪問頁面後等待15分鐘觸發運營邏輯，等待指令就是流程控制。
執行條件就相對簡單了，但在思考的時候不要被束縛。
一切對使用者的運營幹預手段都可以是我們的覆蓋範圍，無論是觸達還是彈窗，無論是非人工、人工還是智慧，做B端重要的是連線和共贏。
理解了規則引擎核心的4要素，下一個問題就是如何能夠讓研發、產品、運營不同的角色都可以使用，適用的角色每向前一步，易用性就更高一層。
如果連研發敏捷提升都無法做到，那這套引擎就沒有存在的意義了。
關於敏捷，我理解的是低程式碼或者無程式碼實現運營需求，並且能夠自主測試無須發版，所以對應的解決方案是
視覺化的拖拉拽
，上圖是易觀數科的智慧運營Work Flow，是一個很好的案例。
但對比no code我個人還是傾向於low code，no code基本是通用的模型和標準化的模版，無需研發、人力投入，即可快速上線應用。
它可以參考網頁、活動等標準化服務的提供商，這種方式的缺陷是，強依賴於模版。如果不具備適合的模版，其實用性會大打折扣，而且很難相容複雜邏輯，
最簡單實際上也最不靈活。
low code，則是透過建設一些基礎設施，實現部分邏輯配置、部分編碼，實現部分邏輯可配置，測試可自助。適用於有一定研發理解能力的產品、運營等同學。
2）使用者互動
互動，顧名思義是交流與互動。
規則引擎負責規則組合，而互動內容負責規則最後的一個節點：執行。
我們希望做使用者運營便需要與使用者產生聯絡，這則依賴於能夠觸及使用者的渠道，不同的渠道又有各自特點互動內容。
這一章節沒有太多複雜的底層支援邏輯，基本就是渠道能力的建設，渠道內容的維護和管理，更多要關注的反而是視野。
這幅圖枚舉了大致可能與使用者互動的渠道以及渠道支援承載的內容方式，
渠道不僅推送，還有企微這類私域的聊天訊息，其次還有電話對應的人工服務以及站內的資源位。
下發的內容也不僅是文字、圖片，也可以下發任務或者獎品。任務可以理解為你希望使用者完成的事情，獎品則是完成什麼事情後你所要提供的激勵。
在這裡大家可能會有的疑問是，落地頁不就一般承載了任務和獎品麼，這一點來說是的。但就是有的場景會沒有落地頁，例如智慧外呼、簡訊。這時候則會運用到通用化的使用者任務體系和獎品了。
至於說內容的產品支援工具，還包含二維碼、海報、短鏈、落地頁生成等，這些產品怎麼實現並不是這篇文章的重點，這裡也不做描述了。
2。 產品表現：方案管理及方案配置
做運營的痛點是：管理困難、成本高及上線週期長。
線上的列表檢視只是最淺層的管理，我們還應該還應提供不同型別的檢視幫助運營同學瞭解運營方案的執行狀況和業務邏輯。
而成本、週期的問題，則應透過自助化、一站式、視覺化的配置來解決，這個部分則依賴則是4-1的底層支援。
1）方案管理
方案管理，首先定義何為運營方案，它包含三部分：
目標使用者、運營策略、效果評估。
對方案的管理，常見的是列表檢視，包含基礎的列表及列表篩選。這一點就不描述了，而當我們要了解業務執行狀況時就會使用到：執行檢視、邏輯檢視等。
執行檢視
從運營的角度，任何的投放類的運營基本都涉及到KPI，
先無論效果如何，每個運營策略要先關注執行是否按時、按量執行。這是運營效果的基礎。
時間部分，主要分為開始時間、持續時間，部分的業務是對任務完成時效有強訴求的。
而量級部分首要的是任務的成功率，在產品設計時再往前做一步還可以基於對應方案的總量級、成功量級做同比或者做趨勢，方便我們定位問題。
邏輯檢視
邏輯檢視，承載了運營方案的邏輯。其次想幫助運營同學建立運營的全域性視角。
這一部分對於不同的產品形態、業務目標，其差異就很大了，下圖舉一個基於商品的邏輯檢視。
商品檢視是單一商品在不同的運營場景，在什麼時間節點、使用了什麼渠道進行運營。
每一個渠道都可能擁有自己的細分目標，點選“目標：引導加購”，則能夠進入詳細的運營方案，從而檢視運營邏輯。第二幅圖則是從品類的角度，來檢視場景運營是否缺失，這個檢視不關注渠道、時間等具體的細節。
這只是2個示例，大家可以基於自己的業務形態去設計自己的管理檢視。
2）方案配置
上文的商品檢視，只承載了邏輯的一部分，更詳細的邏輯則會進入運營方案頁面。它包含了運營方案的面向使用者、運營策略、評估指標。
接下來為大家講解的部分是，一個方案配置的表現層是怎樣的。配置的方式，
業界主要有2類，一類是流程檢視，另一類是表單檢視。
流程檢視可以參考釘釘宜搭、易觀數科，在這裡只做簡單的圖片展示。
釘釘宜搭：
易觀數科：
表單檢視，也是比較主流的方式。個人的設計將運營方案拆分為了4個部分：運營頻率、面向使用者、運營策略、效果評估。這一小節，先闡述前3小點。
運營頻率
一個運營方案，首先要處理的是在什麼時間範圍內運營，其次是以什麼樣的頻率在什麼時間運營。
事件觸發則不依賴時間，基於事件發生實時觸發，這一型別沒有運營時間的概念。而迴圈觸發、單次觸發則會有時間的概念。
迴圈觸發，是指多次的觸發任務，觸發事件僅適用於每日定時任務，間隔日定時任務。對間隔日定時任務舉一個例子輔助理解：每週一都要上班。
單次觸發，則是一次性的任務了，可以是方案建立後立即傳送或者定一個建立方案完畢後的時間進行傳送。互動示意如下：
面向使用者
這個部分，在講解使用者資料平臺的表現層時是有詳細介紹的，在這裡只做互動示意。
運營策略
上圖是一個簡單的模式，能夠服務大多數的場景。但在實際的過程中還是會涉及到判斷、執行條件的組合。
複雜的模式，會在上圖額外增加運營規則欄位，規則由研發視覺化托拉拽配置而成，然後規則再渲染執行相關的渠道、內容提供運營填寫。
但規則多了，也就難以維護和理解。除了流程檢視，怎麼樣做能夠更易用、更易懂，我目前也沒有很好的答案。
靈活和通用，真的沒那麼容易做取捨。
五、使用者運營平臺：看效果
終於到了主流程的最後一個部分：看效果。
回顧一下看效果的痛點：評估標準不一，無法對比，並且缺乏負向評估。
這一部分從個人的角度主要是需求方，而非實現方，所以沒有太多的底層實現可以分享，而表現層則是基於運營方案的執行結果，對干預成功的使用者進行漏斗統計、ROI計算，以及下鑽的畫像分析。
這裡主要描述漏斗統計和ROI計算的一些思考：
1。 漏斗統計
漏斗的統計主要看端到端的轉化，指標的定義如下：
目標使用者總數：使用者圈選組合後的使用者總數；
干預成功使用者數：經過防騷擾遮蔽、紅黑名單或運營策略等判斷條件過濾後下發成功數量；
點選人數：下發使用者後，使用者進入落地頁的人數；
轉化人數：點選使用者實際完成轉化目標的數量。
轉化人數的概念非常的廣，取決於你希望這個使用者完成的行為指標。這個指標每個運營方案都可能不太相同，包括成交、續費、訪問、關注等。
如果你不是資料產品關注的核心應該是梳理不同業務的轉化指標，並交付資料部門實現統計再整合進你的平臺。
2。 ROI統計
ROI統計這是一個比較難設計的模組，在這裡可能也只是拋磚引玉。
之所以說難，難在不同的業務指標不相同，統計的方式也不同，如果強行輸出，可能得不到大家的認可。
這裡個人的思路是
分業務計算，抓小局放棄大局。
理解梳理不同業務的計算方式，併為其提供通用的配置計算能力。幫助不同部門的
內部能夠比較，能夠衡量。
ROI的計算公式，相比傳統的計算方法額外多了一個引數：
“負向指標經濟價值”。
道理也很簡單，每發一篇公眾號文章，有人關注也會有人取關，有正向也當然會有負向。但這並不是說不需要繼續運營了，而是要讓分子大於0，並且儘可能地靠近、超出分母。
以上圖的第二個例子進行解讀，假設是某東Plus會員年卡，臨近過期使用者仍未進行續費，這時平臺運營會將這部分使用者推送至外呼專席，由外呼同學引導使用者進行續費。
過程指標體現了結果指標的完成方式，要提升結果指標的經濟價值，要麼減少完成過程的損耗，要麼提升完成結果的單價。
而負向指標，即這種運營行為可能導致的損失，這是這個運營舉措帶來的負向影響，如第一個例子中的取消關注。
負向指標同樣需要換算為經濟價值，如：1個公眾號粉絲的費用，1個小程式UV的費用。正負向的結合，才能使計算更為客觀。
六、寫在最後
這篇文章，寫的很艱難也很暢快。艱難是我從未想過我最熟悉的B端產品，沉下來寫會多了這麼多的產品方向。暢快則是終於我不用管那該死的邊界、價值、實現難度，能夠設計理想中應該包含的東西，應該呈現的互動樣式。
完整的使用者運營平臺非常複雜、成本也很高，它要求你的業務是強依賴於召回，並具備足夠大的業務量級與收益。
否則，我還是建議從這裡去汲取靈感，自己做自己的MVP。
思維可以更開闊一些，有了使用者資料平臺，基於特徵做拖拉拽的BI報表也可以，畫像分析也可以。有了規則引擎解決審批流配置、調研問卷的問題也不錯。做了渠道能力，為外呼團隊、客服團隊提供支援也是很好的路徑。
其實能設計這樣一個產品真的運氣挺好的，它把我過往的產品經驗進行了連線。在第二份工作的時候，我做的B端產品非常多，包括：頁面配置、任務、獎品、使用者特徵等等，但它們的連線都非常的疏離。
這一次才有點點所謂生態的感覺了，而不是假大空的一個名詞。
最後呢，還想要建議B端產品在設計時儘可能的遮蔽底層邏輯，減少配置項。這麼多的視覺化、自助化配置，確實減少了研發的成本，但只是轉換成了是產品和運營在負重前行。
回到C端也快3個月了，寫一篇B端產品的畢業論文，還還2個月不更的債。
非常感謝你看到這裡，謝謝寧。
本文原創釋出於人人都是產品經理 ，未經許可，禁止轉載
題圖來自Unsplash，基於 CC0 協議