![]()
我是統計科班出身，對數據較爲親近，畢業後便在互聯網開始從事機器學習與數據分析工作。幾年觀察下來，發現許多業務雖然都會引入算法工程與分析師等這些數據職能，但是大部分的決策還是基於直覺來拍。當然，有些時候直覺是唯一的選擇，例如產品從零到一的設計或者算法早期預測和排序目標的選擇會更多參考行業內的成熟做法。但是當數據積累到一定規模，業務也已經過了早期高速增長的階段的時候，如果業務還在保留「直覺驅動」的慣性，就會浪費掉許多增長機會點：你們身邊的業務是否不經過 AB 實驗就去判斷一個策略是否應該上線？是否有算法團隊半年以上一直在圍繞有限幾個指標來預測和排序，但是未曾用數據證明過這些指標對業務和用戶體驗的實際價值？又是否發現每個項目的數據看起來都不錯，但是公司全局卻沒有增長？—— 當身邊的業務出現以上現象，就很可能沒有利用好分析的資源來催化自身業務的增長。
無論對錯，當下許多互聯網企業是採用 OKR 體系做自上而下的目標拆解的。一個業務線的 OKR 裏面的的「O」通常就是業務的 KPI，在這個體系下，不論是算法、運營、產品、還是分析，日常的項目都可以概括成「通過策略來提升 KPI」的過程。同時，策略的制定來源於直覺與客觀事實（數據）兩個方面，只有輕重多寡之分，「直覺驅動」更依賴經驗判斷，「數據驅動」更多基於客觀事實反推決策。因此，一個業務當下的策略應該更多依賴直覺還是數據就需要看清過往一段時間「直覺驅動」與「數據驅動」策略哪個提升 KPI 的成功率是最高的。業務開展早期，「直覺驅動」成功率更高，可能也是僅有的方案。但是隨着業務發展，好的直覺會被逐漸窮盡，業務增長進入瓶頸期的時候，「數據驅動」的價值就會越來越大。
分析師是誰？做什麼？產出的價值？
「宋世君：我們談談“DS 是誰”. 用心理學的術語, 這個其實是 DS 的“本我”。我們是一羣在相關量化領域受過專業的訓練, 並且希望應用自己的量化能力, 在數據中挖掘對業務有用的信息, 並且通過這些信息爲業務發展提供助力但是同時又保持數據的中立性的人。......，從個體的角度, 這也意味着我們看待 DS 並不是看這個人的學術專業, 而是看這個人的動機和意願。公司裏跟數據有關的職能是多樣的, 有些是把數據作爲拿到業務結果的抓手, 要對業務結果負責, 這些是數據運營. 有些是把數據作爲研發的對象, 對跟數據相關的這些產品負責, 這些是工程研發. 有些是基於數據做實時地在線實現, 這些是算法工程師的工作. 這些都是我們的合作伙伴, 但是我們又有我們自己的定位, 跟這些都不同. 我們應該爲我們工作的中立性和科學性負責. 我們需要有業務的思想, 但是我們並不是要做業務本身, 我們希望做業務發展的催化劑。」
我非常認同世君老師上面這段話對分析師的定義。分析師需要兼備定量能力和業務思維，在保證科學性與中立性的前提下，通過定量手段（數據驅動）來補足直覺驅動的短板。「直覺驅動」的短板可以分爲以下四類：
-
看不清自己的用戶是誰、有什麼行爲，體驗如何「= 拿不準用戶」；
-
將頂層 KPI 拆解成若干抓手和子目標的時候，並不明確這些抓手和目標事實上是否可以提升 KPI，或者哪些抓手與目標更加有效「= 打法不清晰」；
-
難以評估策略對用戶與 KPI 的影響「= 算不準影響」；
-
不知道業務健康度如何以及當下要採取的行動「= 看不清現狀」。
補足短板的具體解決過程體現了分析師日常在做的事情以及數據分析的價值：
「拿不準用戶」：當直覺不能很好契合用戶訴求的時候，對用戶畫像細分、行爲軌跡分析、流程轉化等分析可以幫助業務更瞭解用戶：他們是誰，喜歡什麼，什麼環節體驗不好，什麼訴求尚未滿足；
「打法不清晰」：通常業務完成某個 KPI 可以用到的抓手非常多，比如，內容平臺的終極目標之一是用戶留存，同時提升留存的抓手有很多，例如 CTR、贊讀比、訪問時長、公域私域相互導流等。直覺並沒有辦法有效判斷這些抓手哪個在當下最可能把留存提升上去，這時候，基於數據的觀測性研究可以估算抓手與 KPI 之間的關係強弱，輔助業務排布各個項目優先級。
「算不準影響」：直覺無法策略一個策略對用戶的影響，實驗分析是高效評估策略影響的解決方案，AB 測試可以幫助業務看清每個策略對各個細分人羣體驗的影響並持續小步向前迭代；
「看不清現狀」：當大盤指標異常波動的時候，異動歸因分析相比直覺是更加科學高效的方法來定位指標波動原因並提出解決方案。
良性的業務發展通常要經歷從直覺驅動到數據驅動的過程，本節進一步展開這個過程並討論不同發展階段的業務特點與痛點，以及這個階段數據驅動業務的打法。這裏採用 Noriaki Kano 的 KANO 需求模型將數據分析需求分成三類：
-
基本型需求：分析師必須具備的能力與交付，是分析師做事情的行爲底線。基本型需求完成不好的時候，再多的錦上添花也是徒勞，也會直接失去業務方的信任；
-
期望型需求：一般業務與分析師正式拉會所討論的項目與預期就在期望型需求的範圍，這部分需求完成的越及時或者越多，業務方對數據分析的評價也會越高；
-
驚喜型需求：主動分析，跳出業務的思考框架，數據分析產生的洞見幫助業務解決困惑，發現戰略機遇，或者數據所提供的策略幫助業務完成難以達成的目標，就是驚喜性需求。驚喜性需求沒有被滿足業務不會不滿，一旦被滿足的時候業務的滿意度是非常高的；
業務開展早期通常可以通過學習頭部競品的成功經驗快速獲得大規模的業務增長，同時，產品運營同學也很容易在業務早期的雛形中憑直覺找到增長抓手。雖然從 0 到 1 的開展業務是非常辛苦的，但是單從獲得業務增長而言，這卻是最輕鬆的第一階段，第一階段的典型特點就是：從零到一，直覺以較高的成功率驅動業務早期的野蠻生長。數據分析在這個階段會跑在後面緊跟，業務在第一階段對數據的需求就是 T+1 準確反映業務 OKR 指標表現，分析師及時做好 BI 角色支持，不要在業務需要臨時看數據的時候連現成的 sql 都沒有備好：
基本型需求：埋點、OKR 指標口徑與常用 sql、數倉明細表；期望型需求：業務日報（OSM），每天早上盯住關鍵指標並及時報備異常波動；用戶生命旅程數據刻畫（UJM） 驚喜型需求：通過描述性統計幫助產品找到發力點：用戶屬性、行爲研究幫助產品看清各個模塊與內容上面的用戶密度；產品漏斗轉化率分析幫助業務看清產品各環節表現，找到轉化瓶頸並重點改善體驗。比對分析競品該業務早期的關鍵指標數據，大致判斷目前的增長速度是否足夠快，空間還有多大。
第一階段臨界終點的時候，直覺依然可以找到大量改進措施，但是從大盤指標上可以看出業務增長放緩甚至橫盤。這時業務就進入了第二階段，這個時期顯著影響大盤指標的策略會越來越少，很難通過上線前後大盤數據對比來判定業務動作的好壞：投石問路的過程中業務最怕的是聽不清石頭落地的聲音，因此分析師在這個階段爲業務提供的關鍵價值就是引入實驗機制，以 AB 測試爲典型的統計方法可以精確、科學的度量每個實驗的微弱效應，幫助業務在投石問路過程中「聽到」方向。實驗機制是業務第二階段的高效解決方案的另外一個原因是，實驗可以對線上同時運行的多個策略帶來的影響分別進行準確估算，因此實驗機制在速度和精度上都全面超越原始的事前事後對比法。在這個階段，分析師需要充分發揮統計專業能力，做好實驗方法諮詢的角色並積極推進技術、業務部門之間協作打通實驗平臺：
基本型需求：實驗分析支持 爲業務方提供統計專業諮詢，e.g. 實驗設計，AB 數據含義，統計指標的計算口徑 期望型需求：聯動業務、後端、前端開發、BI 協同搭建實驗平臺 平臺可以並行線上實驗同時可以自動化處理實驗分流不均、檢驗指標顯著性 向業務普及 AB 方法與對業務的價值，出具實驗分析白皮書強化業務對實驗的信任 驚喜型需求：將實驗分析報告模板化，賦能業務在脫離分析師資源的情況下自主完成實驗設計與分析報告 維護業務上下線的實驗明細日誌，包含實驗 ID、業務策略、影響、上下線時間、上下線理由，季度性提供給業務去覆盤總結
第三階段：增長遇到瓶頸，數據驅動業務找到新目標體系與增長髮力點
與第二階段不同，在第三階段開始的時候，策略的成功率與影響程度都大幅降低。這個階段，產品和運營側好的直覺基本被窮盡，算法側已經把特徵體系和技術選型迭代到了相對完備複雜的水平，再想提升預測精度是非常困難的，便開始頻繁出現實驗結果不顯著或者負向的業務策略，業務增長正式進入橫盤階段。在業務缺少方向感的時候，數據驅動業務方向的選擇就越來越被重視。分析師的話語權也開始變大，畢竟到了第三個階段產品運營與算法團隊初步具備了一定規模，不增長的後果是很難想象的。
因此，分析師一定在這個階段有業務主人翁的意識，開始深度思考業務問題並主動提出需要數據分析的問題。有必要強調的是，分析師在這個階段要主動思考和分析，不能被動響應業務需求；不要妄想去證實業務這個階段的直覺是不是對的，而要站在更加全局的層面去思考業務發展的關鍵問題是什麼；不要再沉浸在實驗方法的優化上面，而要開始頻繁旁聽業務討論會，重點體會業務高層在會上提出來的問題以及流露出來的困惑點。這些對於分析師找到需要分析的關鍵問題是非常重要的，也是分析師在這個階段產生影響的第一步。
對於增長而言，第三階段也許最爲重要的指標就是用戶留存率。用戶增量 = 新用戶+沉默召回用戶+活躍用戶*留存率，業務早期的增長可以通過業務之間導流與拉新來完成，當業務成熟後，提升存量活躍用戶的留存是最爲經濟的手段。不過實際上，每個業務策略、項目、或者算法模型的目標與留存提升之間通常是靠直覺強行連接起來的，不夠，目標是否有可能錯了？能夠有效提升留存的目標應該是什麼？這就是分析師要在第三階段試圖用數據來回答的關鍵問題。當初筆者剛接觸一個做社區內容平臺的業務時，該業務快半年內的所有算法和業務策略都沒有任何提升用戶留存的跡象，分析團隊在梳理這塊業務時候發現業務和算法都在用 CTR、贊讀比、收藏讀比等有限幾個指標來衡量用戶的閱讀體驗並做排序。分析師基於 DID 建模分析發現當時大盤用戶裏面留存提升的羣體通常伴隨着上一期深度閱讀量與 CTR 的顯著提升，而贊讀比、收藏讀比與留存的相關性並不高。問題是，業務過高估計了贊讀比、收藏讀比的價值，並在排序的時候沒有考慮內容被深度閱讀的概率高低。團隊後續推進了一系列的策略建議：我們首先大幅提高了 CTR 的排序權重，這個簡單的策略就打破了長達半年來業務留存率無法提升的困境；團隊進一步在排序目標裏面引入深度閱讀概率、平均閱讀速度等與留存關聯性最強的指標，並設計了多目標融合的公式，這個新目標（公式）成爲了算法、產品運營的新業務目標，並帶來了新一輪的留存增長，業務順利走過了第三個階段的增長瓶頸期。
平臺的終極目標是流量、利潤，這個頂層目標會在 OKR 體系下被拆解成二級指標，三級指標等子目標。無論是業務策略還是具體算法，它們都在直接影響一個子目標（e.g. 價格，CTR，時效性），無論他們在完成這個子目標的時候多麼數據驅動，通常都在基於直覺假設他們的子目標與公司的終極目標是直接掛鉤的。問題是，直覺是會犯錯的，因此才存在業務第三階段的瓶頸期，這時也就體現了數據驅動的價值。
基本型需求：通過歷史策略和數據開展觀測性研究，通過數據估算策略當下每個子目標對公司頂層指標的影響，聯動業務制定並落地新的目標和增長方案；期望型需求：積極主動創新，尋找更具增長潛力的新指標，納入當前業務的子目標體系，提供子目標整合成統一一個目標的方案；驚喜型需求：觀測性研究方法工具化，賦能業務在脫離分析師資源的情況下自主完成目標優化。
![]()
數據在第三階段驅動業務增長的同時，業務也因此在每次評估策略影響的時候要兼顧更多的用戶體驗指標。在此基礎上，業務增長到一定規模之後就要開始承擔更多全局責任，開始承擔孵化新業務的角色，這會進一步擴展業務的指標體系。走到這個階段的業務通常是寸步難行的，因爲每走一步都要經過互斥、此消彼長的層層指標關卡。在第四個階段，通常是每個策略迭代都伴隨留存不顯著波動但是二級指標互有漲跌的現象。糟糕的是，當留存等頂層指標不變但二級指標互有漲跌的時候，數據不能給出明確策略上下線的建議，業務便又退回到了基於直覺來決策的原始形態。在這個階段，不夠剋制、盲目上新的產品會變得臃腫，給用戶帶來產品功能複雜冗餘的不良體驗。
在這個階段，數據評估層面需要做系統改善來保障決策的科學性。實際上很大概率成立的一個事實是：把所有用戶當做一個大盤整體來評估用戶體驗是低效且失真的，策略在大盤層面的「表象影響」是細分用戶羣體層面的「實際影響」的累加，而「實際影響」在不同用戶羣體之間可能存在顯著差異。下圖內容平臺的實驗數據就是一個典型：大盤（左）數據表現出來的留存不顯著+二級指標互漲跌實際上是細分用戶羣體後指標普漲、普跌、互漲跌。
分析師在這個階段需要在細分用戶羣體粒度整合階段二的實驗能力和階段三的觀測性研究能力，打通數據驅動細分策略迭代的流程：
Step1：基於細分實驗分析，策略在指標普漲用戶羣體上線，普跌羣體下線；Step2：產品運營與分析師聯動展開用戶調研與觀測性研究，針對體驗不良的用戶羣體探索新的增長髮力點；Step3：循環 在此基礎上，分析師需要在這個階段打磨到細分用戶羣體的異動歸因分析能力，幫助業務及時發現問題和增長點。異動歸因分析方法建設是另外一個比較大的話題，有興趣的讀者可以參考《解構平臺，一套數據驅動平臺增長與異動歸因的理論與工具》，這篇文章針對異動歸因一個點有更多細節上的展開討論。
好的分析就是一個「數據比較 -> 洞見 -> 業務優化」的過程。洞見離不開「比較」：無論是我們看指標走勢，AB 差異，同比環比，或是迴歸分析模型中的參數，這些都是我們「比較」的不同形式。具體來說，數據比較來源於三種分析場景：
-
-
-
觀測研究：增長抓手分析，未經實驗全量上線的策略評估，長期戰略規劃。
AB 實驗是在 AB 兩組之間進行比較，異動分析是兩個時間段之間的比較，觀測研究實際上是在分析一個指標變化相比不變化對業務的潛在影響。
比較有兩個要素：1. 研究羣體和參照羣體（Benchmark），2. 評估指標。
比較時所選擇的 Benchmark 好壞直接影響分析結論的可信度。舉個例子：「產品轉化率是 5%，還有提升的空間」就是一種很常見的分析結論，但是這個結論本身毫無邏輯，爲什麼 5% 是較低的水平？提升轉化率的抓手又是什麼？這類分析的問題就是沒有找到好的 benchmark。相比而言，「產品轉化率是 5%，我們競品的轉化率是 8%，我們和競品的主要差異是 xx，所以轉化率還有提升空間，建議優化 xx」的可信度就更強，因爲分析找到了參照，並且用 xx 作爲輔助評估的指標。
比較背後的思考體系 和 AB 實驗很類似，新業務策略的思考也是個比較的過程，只不過前者基於數據，後者則是在直覺中比較。工作中我們最頻繁的基於直覺比較是在制定 OKR（Objective ~ Key results）的時候，對於每個 KR，我們都在比較：有相比沒有這個 KR 對於 O 而言是好是壞。依照這個邏輯來講，分析的價值在於分析可以提供直覺所欠缺的 O 與 KR 之間的「定量關係」。
我自己的經驗是，把業務的訴求翻譯成 OKR 的框架裏面可以幫助我快速找到分析思路。一方面業務一般都是在面向一個具體的目標談有待數據驗證的策略思路，帶入 OKR 框架成功率較高，另一方面解 O 與 KR 之間的「定量關係」的統計方法已經有一套完整的體系，這個後面我會再提及。
總結下，在對接一個業務需求的時候，分析師一定要搞清楚：1. 這個需求圍繞的業務目標（O）是什麼，什麼指標去量化 O？2. 業務聊的核心用戶羣體是誰，什麼維度可以量化這些細分用戶羣體？3. 潛在的抓手（KR）有什麼，業務提到了哪些，我們又可以舉一反三出來哪些？在這些問題搞清楚之前，先不要動 SQL 或者建模方法。
不難看出，分析的一個核心基礎能力就是一套健全的畫像、指標體系。
基礎：維度、指標體系 無論是哪種場景，「比較」都要具象化到實際業務場景才能提出可落地的業務洞見，而具象化的分析依賴一個關鍵工具：畫像體系與業務指標體系。這個體系對業務的還原度越高，分析質量也越高，因此分析師團隊要不斷去「養」自己業務的畫像指標體系。最直接「養」畫像與指標體系的機制就是不斷去用，每次應用所發現的問題持續小步迭代解決。指標、畫像體系建設的責任要落實到個人，整合團隊業務分析師的畫像與指標口徑，持續優化體系的完備性可用性，並推動工作成果在業務分析、實驗平臺、業務運營平臺上落地應用。
互聯網業務通常屬於多邊平臺模式，完備的多邊平臺畫像需要包含供需+場景的刻畫：
需求畫像：用戶 demographic，訴求歸類（產品 = 訴求），用戶行爲、興趣分類；供給畫像：供給形態、來源、品類、時效；場景畫像：時空，供求關係，競爭，大盤等外生因素刻畫。多邊平臺的業務指標體系在描述業務健康度，平臺增長要麼是拉動供需規模要麼是增加匹配效率，因此業務指標體系包含以下三類：
供需結構指標：按照需求 + 供給畫像細分後的用戶數、供給分發規模；
匹配效率指標：供給分發轉化率 e.g. CTR、ETA、成交率、交互率...；
體驗結果指標：用戶留存，人均消費與瀏覽時長；
畫像與業務指標設計最考驗分析師的業務理解程度，平時多留意資深一些的業務如何討論用戶和供給，會啓發分析師優化口徑的設計。在知乎遇見過一些糟糕的畫像，例如一個刻畫用戶頻次的維度竟然聚類出來六層，然而每一層都沒有明確的業務含義；另一個維度直接按照高頻、中低頻、新、沉默召回來切割用戶，簡單、業務意義清晰，業務方自然會去用後者來看數據。或許在知乎見識過的最棒的用戶畫像，先將用戶需求抽象成「看熱鬧」「長見識」「找解答」「來創作」四個大類，然後基於用戶的行爲鏈條來往這四類裏面歸，理解業務先於制定口徑與技術選型，畫像的應用價值與空間自然更加寬廣，統計方法產生的價值也越大。
幾年前我還是一名算法工程師，跳到阿里剛開始的時候很不習慣，因爲許多日常人肉要做的工作都被數據和算法平臺解決了，不誇張的講，那時許多產品運營同學訓練部署機器學習模型的速度都比我要快。AI + 數據的平臺在逐漸釋放那些高度重複的數據工作，那時候我意識到，如果一個 RD 脫離業務，時間精力花在調包換模型調參數這類事情上的話，ta 早晚被淘汰掉。
對於分析師來說，我們不得不思考的問題是自己每天的「分析」工作中有多大比例並沒有在分析？目前來看，數據查詢平臺還沒智能到通過拖拽形式來完成多數的取數需求，一些公司內不健全的埋點平臺還有數倉還需要大量分析師花精力排坑填坑。也正是因爲平臺能力尚未成熟，產品運營自己分析一次數據的成本過高，就會有大量取數的需求提到了分析師團隊，導致每個業務下都有一些分析師做了「數據的揉麪工，業務的按摩師」。
最近還留意到兩款明星數據產品，Chartio 和 SQLFlow，前者是拖拽式 SQL 與可視化的一站式平臺，後者是在模型解釋上做了一些增量工作的機器學習訓練與部署平臺。雖然還沒有大規模商用，但是已經能看出趨勢：SQL、數據可視化、訓練與部署模型、模型解釋相關工作的門檻會越來越低，數據感覺不錯的業務同學可以直接通過這些工具來快速完成取數分析師大量的「分析」工作，還省去了不少溝通成本。所以未來一定會淘汰掉一些分析師，留下有業務思辨能力和定量專業能力的精英。
未來分析的工作還是離不開畫像指標體系、實驗評估、異動歸因和觀測研究，但是會更加關注這套體系的科學性與落地上面，也因此可能會分化出來兩撥分析師：業務導向的分析師優化業務與數據的連接，挖掘業務表象的跟因與戰略機遇，並將洞見以畫像與業務指標的形式做落地，指標與畫像的工作直接優化了業務的分析質量和運營效率；模型導向的分析師優化基於數據做評估、歸因、推斷的科學性，並落地易用的數據產品，在此基礎上，發現業務決策過程中不科學的環節，推動數據分析工具在這些環節的應用。因此我建議分析師在懂 SQL，基本的統計方法基礎之上，增強自己的業務屬性和數據科學屬性：學習商業、經濟學原理，理解基本的因果推斷與計量方法，強化構建模型內核的 scripting 能力。
後臺回覆暗號「進羣」，即刻加入讀者交流羣~
![]()
本文分享自微信公衆號 - 凹凸數據（alltodata）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。
