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