用資料驅動運營：構建團隊的資料思維和增長基因

前文：
從設計到歸因 - AB Test 實戰心得
從思路到工具 - 增長實驗資料歸因分析

前言

大家好，我是大Fei，九日論道的常駐筆者，又給論主獻花了。前兩次給大家分享了一些AB Test實戰方面的心得，收到不少的反饋，筆者會不斷吸收大家的建議並繼續改善，歡迎各位道友前來指教。

在決定分享這個話題之前，筆者思考了很久，“資料思維”是筆者在團隊不斷去努力建設的一個目標，也是筆者不斷在學習和探索的一個思維模式，這對於團隊的增長文化，是個即基礎又核心的關鍵因素，因此抱著學習的心態想要丟擲來與大家一起探討。

同時，也希望藉此機會，分享筆者對資料思維的理解，以及在這方面的經歷和看法，希望能讓更多的人重視資料思維的培養，讓更多團隊充分利用資料創造價值，關注資料到商業的價值，這個是筆者所理解的資料思維的核心。

適合閱讀物件：思考資料驅動增長的團隊Leader，產品，運營人員

正文

一、團隊資料驅動可能存在什麼問題？

可能我們都曾面臨過這類情況：

資料搭建好了，但業務方（產品/運營等）沒有充分利用，沒有看資料的習慣

資料利用起來了，但看不懂，不會分析

資料分析了，但不知如何驅動業務增長，創造價值

等等..

在與很多朋友交流過程當中，確實能夠感受到很多負責業務的朋友僅對業務/商業敏感，但對資料的敏感程度還不夠，而做資料的朋友大多數只對資料比較關注，缺少真正能驅動業務的能力。

我們曾在公司團隊內部給業務的同事做過一些分析/實戰方面的培訓，負責業務的同事雖說掌握了一些分析能力和技巧，可以取數和觀察資料，但確實少了點什麼，最直觀的感受就是沒有多少人是對資料敏感的，主要體現在無法就業務深入討論資料問題，進而，就很難深入到資料驅動業務的層面，更對資料創造商業價值無從入手。

而對於負責業務的同事，一個現實就是大部分人本身就是對資料不敏感，而想要對資料敏感，需首要解決的是讓個人具備相關的資料思維，這也是團隊要實現資料驅動增長所必須具備的團隊基因。

筆者認為資料思維應當包括：

• 關注自己業務資料，對資料變化異常敏感
• 能夠利用資料思考和決策，驅動業務增長
• 能夠利用資料發現業務問題
• 經常能基於資料做出假設和預測
• 能夠將業務問題，定義成資料可分析問題
  

業務人員天生具備的優勢就是熟悉業務問題，但將業務問題變成一個資料可分析問題，進而用於指導自己或其他資料人員分析問題，是比較困難的，但如果具備了一定的資料思維，這個將不再是問題。

二、團隊具備資料驅動增長的基因嗎？

1、重新審視我們對業務資料的認知

無論你在團隊擔任什麼角色，我想建議大家分別用5~10秒鐘的時間回答下面每個問題

你團隊的核心產品/業務（如App/網站）：

• 日活（DAU） /月活（MAU）分別是多少？
• 啟用（install）到註冊（sign up）轉化率是多少？
• 啟用到付費頁面的觸達率是多少？
• 付費頁面付費轉化率是多少？
• 啟用的次日留存率是多少？
• 啟用使用者的ARPU是多少？
• 啟用使用者有%幾在啟用當天付費？?
  

也許你看出來了，上面幾個問題基本都是AARRR 指標體系裡面的相關資料，對於做增長的每個人來說都不陌生，但在這些看似簡單基礎的資料問題，你是否能熟悉並回答出一個大概的資料範圍呢？

假如問題不符合你的場景，你可以舉一反三，例如你的部門僅負責某個功能或業務線，那麼啟用就等同於功能的首次訪問，次日留存就是首次訪問該業務或功能且次日留存的比例，每個細分的業務也會有自己的AARRR模型，相信大家都懂，不再重複贅述。

大家可以自己評估一下，自己對業務資料的熟悉程度到底如何，同時也可以放在團隊內部，去調查一下團隊對相關業務指標的熟悉程度。

你可以直接使用上面的幾個問題，也可以結合自己的業務設定不同的問題，主要目的在於瞭解自己團隊的現狀，如果答對的比例整體偏低，建議團隊leader要好好反思，為何團隊對自己負責業務的基礎資料認知會怎麼差？

當然，個人也應該反思，假如連基礎的業務資料你都無法準確掌握，資料驅動增長，從何而來，給你再多的增長技巧，你確定能正常運轉嗎？

2、團隊的資料思維如何體現

如果大家有印象就會留意到，我們招聘時經常提到一個對資料敏感，雖然比較抽象，但這就已經表明我們很清楚知道，對資料敏感的重要性，筆者認為資料敏感度是資料思維的其中一種比較直觀體現。

關於資料敏感，筆者合作過程中接觸過很多資料敏感的大佬，我們公司的老大就是一個資料敏感的人，筆者發現這類人都有這些個特點：

- 能提出清晰的資料需求，且對自己每提到的資料指標都有深入的理解

能明確知道自己需要觀察什麼資料，且能夠結合業務尋找到非常關鍵的分析維度，用於觀察和解讀資料，筆者也經常從這些人口中掌握到很多關鍵的業務資料洞察資訊，受益匪淺；

筆者雖說能具備一定的業務能力，但自認無法與做業務的人相提並論，而對負責業務且對資料敏感的人，往往其對業務資料的洞察要更深入，這點筆者深有體會；

- 沒有一天不認真觀察資料

每天都認真看資料，且總能提出報表的調整建議，因為資料敏感的人總有自己觀察資料的方法和基於業務的解讀方式，且反過來會經常指導報表的調整和輸出，以提高他們對資料觀察的效率；

- 經常能夠發現資料異常

資料敏感的人，在對自己業務資料充分理解的情況下，更能夠及時察覺到資料的異常，舉個簡單的例子就是，當你們上線某個活動時，這個時候，有資料思維的人就有形成對資料走勢的預判，但資料過高或過低都會引起他們的警惕，進而分析和找到問題所在。

如果團隊對資料不敏感，往往會造成總讓資料部門的人滯後發現異常，因為資料部門有時候相對於一線業務人員活動資訊是滯後的，收集資訊和響應就會更慢，而影響已經造成了。

筆者建議大家對比自己，能否做到這樣？假如團隊的每個人（尤其是業務方），都能這樣來關注業務資料，你覺得團隊的資料思維會差嗎？筆者覺得答案是肯定的，當我們都具備這樣的資料思維和相關意識，實際上我們就掌握了對業務資料分析的基礎，而恰恰是這種基礎的思維方式才是最重要的，比任何技巧都重要。

3、個人資料思維到團隊資料思維仍然艱難

即使我們團隊有了資料敏感的人，有資料人員做支撐，或者資料平臺、培訓、報表都有了；但在筆者看來，想要達到一個合格的資料驅動團隊，還需從個人到整個團隊，一步一步去轉變，突顯資料的作用，並影響到團隊的每個人，這需要不斷的去宣傳資料驅動的文化，訓練團隊成員的資料思維；

但筆者相信，當更多資料驅動的成功案例出現，這一步並非那麼遙遠，資料思維，也將成為每個從業者必備的思維能力。

三、我們的協作流程能夠支援資料驅動嗎？

這裡列了兩個流程對比，大家可以看一下自己的團隊更符合那種協作流程

流程1：產品/運營需求協作流程


流程2：產品/運營+資料需求協作流程


筆者的團隊更多的是【流程2】所示的協作流程，我們經常在內部強調業務方的需求要加上資料需求，但實際上，我們仍然會出現【流程1】的情況，還是會存在運營和產品在出需求或上線的時候，沒有充分考慮過資料需求。

例如，已經上線了某個活動，最後跑來問資料團隊，有沒有資料評估一下效果，這個就是問題所在，但大家還真不能把這個當做個例來看，這反而是一個團隊可能面臨的問題，一個缺少資料思維的體現。

另外還有一個親身經歷，且讓筆者印象深刻的就是，有個朋友改動了他們產品的付費頁面，詢問了筆者一些資料上的建議，當時建議要上AB Test，但最後對方並沒有採納AB Test 的建議，而是堅信了自己的新方案會比舊方案好，之後事實證明了，資料並非一直增長下去，且導致資料增長的因素非常的多、也時間的波動性等等，當資料不是長期保持提升的時候，就會容易受到他人對方案的質疑，甚至，你連方案是好是壞都區分不了，提升多少也不知道。

所以當我們的流程存在問題的時候，即沒有充分考慮資料在整個過程的角色定位時，資料運用起來就會非常的不順暢，容易會出現遺漏，從而導致資料缺失或專案效果無法評估的狀況。

四、打造團隊的資料思維

1、業務方基本資料素養

1.1 學會提資料需求

很多基礎的資料基本由開發或資料人員提前收集到了，但這個過程還遠遠達不到應用層面，就如前面第一節提到的，大部分資料採集上來後，基本沒有用到，這個實際上也在浪費企業資源；

從筆者接觸到的幾個專案來看，確認這類問題頻頻出現，有了資料但不知道如何使用起來，所以這也是筆者本次希望探討這個問題的主要原因。

作為業務方，就應當清晰定義你所需要的資料，從寫需求的角度來說，不要單純提一個資料，而建議把目前和用途寫清楚，這樣有助於資料人員理解你的需求和商業價值，而對於沒有的資料，交由開發埋點即可。

並且，業務方更需要掌握如何運用資料，不要過於期望資料人員告訴你怎麼使用資料，而是通過學習行業內的用法，例如如何做精準運營、如何分析使用者畫像、使用者標籤運用等等，這些只有當業務方找到運用場景，資料人員才能更好的發揮其專業的作用，否則讓資料人員幫你找應用場景，這個本身就不是他們特別擅長的事，有可能直接搞錯了方向，例如使用者標籤就極有可能給你整出一大堆用不上的標籤。

在出產品或運營需求的時候，有意識的加上資料分析需求，讓資料人員評估當前的埋點是否符合最終的分析需求，若不則需要重新設計埋點。

1.2 資料自助分析工具投入

資料分析工具是必要的投入，當分析需求越來越多（隨著業務增長，這個需求量只會增不會減），你不能等分析人員老半天才出一個資料結果，甚至在初期沒有資料人員時，你就得依賴開發資源，自助分析工具可以讓業務人員快速上手，自行獲取關鍵資料和展開基礎分析，有利於整體效率的提高；

對於期初團隊人員少，專案使用者規模不大的情況下建議考慮免費的分析工具，如Firebase + BigQuery，這樣可以減少初期的投入，同時能保證一些資料的採集和分析工作，BigQuery建議開啟付費，不貴，避免早期資料丟失（保留60天的資料）。


而對於稍微有一點使用者規模和收入的團隊，則比較建議付費的資料分析工具，分析的效率較高，功能則要豐富很多，例如神策這類工具，國內可以多家對比；

重要提示：無論接入了啥分析工具，作為業務方，都要熟讀一下官方的操作教學文件或視訊，瞭解每個工具和指標的具體含義和用途，這是非常的關鍵，決定著你是否能正確使用這些分析工具和正確解讀資料；筆者見過很多接入工具但沒有充分利用的案例，白白浪費有效資源。

1.3 每日觀察資料

建議團隊內部，尤其是作為業務方，需要天天盯住自己業務相關的資料，無論是團隊的日報，還是在分析工具中，每日看資料的習慣是培養資料思維的重要過程；

每個你所關心的業務指標，都可以反應出一個真實的使用者使用場景，同樣的場景下，這個指標的表現如何，相比業界做的更好嗎？哪些維度不夠好，你需要在每天都思考這樣的問題。

神策有個功能，可以觀察每個後臺賬號的活躍天數，通過每個賬號的活躍程度，就可以看出每個人對資料的應用深度，這個是一個比較有效衡量團隊資料運用表現的方式；當然，筆者不建議這個指標用於評估個人表現，而是作為對團隊每個人資料意識和資料應用層面的觀察和把握，從而思考應該如何提升團隊每個人的資料思維，結合每個人實際工作情況，做進一步調研和溝通，解決問題。

1.4 資料素養和技能培訓

為團隊內部業務人員提供相關基礎資料分析能力的培訓，也是進一步提高團隊整體資料思維和重要措施。

2、資料增長文化的植入

2.1 有一次顯著成功的實驗

熟悉增長黑客的朋友會知道，增長的文化是需要對內部宣講的，但更為重要的就是實打實完成一場資料有明顯增長的實驗，用資料的勝利結果對內部做宣講。

具體如何開展，這個部分其實沒有太多可以說的，方法論網上有很多內容可以直接參考，但筆者比較建議尋求同領域內有增長經驗的專家幫忙，或者找到增長負責人，如果沒有把握的情況下，多認真研究資料，尋找增長突破點，再做相關實驗，筆者最早接觸增長黑客時，我們的增長小組有幾次失敗的實驗，就是因為前期各方面均沒有經驗，導致實驗很少有成功的，從而打擊了團隊士氣，第一次啟航失敗。

設計和評估方法也可以參考筆者前兩篇文章：

從設計到歸因 - AB Test 實戰心得
從思路到工具 - 增長實驗資料歸因分析

2.2、無處不在的 AB Test

這是筆者很喜歡的一個概念，當我們要開展任何工作時，多用AB Test 的思維方式來思考，例如傳送一條訊息、營銷頁面時，多準備幾個備選文案，傳送時用AB Test分發；可以測試發與不發的區別，測試發什麼內容的區別，你可以一次性做到幾種驗證，高效而便捷；運營工具可以選擇支援AB Test的，如Firebase的 in app message功能；

另外就是當大家在有些方案意見出現分歧時，那就可以直接分兩個方案上去測試，用資料結果說話；若沒有分歧，筆者仍然建議在資源允許的情況下，多測試一些小改動，如文案、UI配色等，這樣可能提高實驗效率，高效獲取更多經驗，沉澱下來。

3 讓資料參與到各個協作的環節中

3.1 邀請資料人員參加需求評審

資料人員被邀請參與到所有的需求評審過程，已經成為筆者團隊裡面的常規工作了，這個是資料和業務深入溝通和參與的過程，整個評審的過程中，可以有助於讓資料人員深入理解業務目標，從而更好的支撐專案的需要；

試想一下，有的團隊可能還沒有接入增長的文化，甚至都還存在部門壁壘，這樣時候，一個需求溝通不到位的可能性非常大，因此，把所有可能的干係人拉在一塊，是比較高效的做法；

同時筆者想說，這些收穫都是我們團隊實際在踐行【流程2】過程中能夠感受的改變。

3.2 任何需求用資料說話

無論是產品還是運營的需求，筆者始終堅持，無論你要做任何事，只要有資料的，就得先拿出來，而不是幹講需求，並且要對方案的預期資料提升有一個預測，最後驗證這個預測。

這個時候，你的需求靠譜程度會提升，大家也能基於資料討論方案和給出針對性優化建議，假如你的方案牽扯到很多開發資源，但功能的受眾非常有限，且明顯感知到資料提升有限，這樣的方案，往往也能在評審中及時被發現，從而減少沒有必要的資源浪費，即使團隊沒有資料人員也建議這麼做，參會人員可以基於資料審視整個方案。（這個方法筆者只能說，屢試不爽，經常可以由其他成員提出更多建設性建議）

3.3 資料覆盤

無論方案的最終結果如何，你都要有一個明確的結論告訴參與專案的人，這個方案是成功還是失敗，成功是提升了多少，專案質量如何；這些資料都是對團隊成員一段時間的努力的反饋；

在我們團隊，有幾個地方筆者覺得是有利用了資料來複盤：

• 我們每個版本都會有單獨的資料儀表盤追蹤版本的資料表現，團隊的每個人都可以看到
• 例如版本開發中，我們會記錄需求量和bug量，beta版本包個數等
• 每個版本都會及時追蹤質量指標，如崩潰率，網路質量，ANR等
• 相關負責人會總結資料和同步所有人，結果衡量方案的效果
  

3.4 讓資料人員為業務方案設計提供資料支援

經常在方案思考時，多與資料人員探討實際業務問題，從而獲得資料人員在資料角度提出優化建議，這是讓資料人員深度參與業務的好處，筆者經過多次這類團隊合作，在團隊內得到業務部門的充分信任，因此導致後來不少業務方直接想筆者詢問方案的建議，當然，協作過程中，筆者或團隊資料人員一般會基於該業務所涉及到的每個關鍵資料進行分析，給到相關建議。

3.5 多定義資料可分析問題

筆者最開始經常接到一些取數需求，如想要一個註冊轉化率資料，但筆者經常會要求寫清楚目的和用途，理由就是避免需求溝通偏差，並且能夠基於需求的目的給到合適的資料和建議，從而主動參與到業務中去，假如業務方的目的是希望提高註冊轉化率而做一些產品改動，這個時候你還能主動發掘每個步驟的流失，分析流失原因，主動提供建議。

而這個例子反過來對於業務方的意義呢？還記得我們前面提到的將業務問題定義為資料可分析問題嗎？你同樣可以在要求獲取資料的時候，提出分析需求，如希望分析每個註冊步驟的流失原因，並提供你的假設，如哪些原因可能造成流失，讓資料人員用資料來分析和驗證。

資料可分析問題定義公式：Y 希望分析的資料結果 + X 多個可能的影響因素

例如：

業務問題描述：

1、希望分析使用者註冊失敗的原因

2、看到註冊失敗的使用者註冊過程遇到網路錯誤、遇到某個操作無法執行、遇到無法註冊、遇到賬號已註冊等多個情況，需幫忙驗證這些因素是否有影響

資料可分析問題：分析和預測X對Y的影響

【 希望分析的資料結果 Y 】：使用者是否註冊失敗

【 多個可能的影響因素 X 】：註冊過程遇到網路錯誤次數 / 遇到某個操作無法執行的次數 / 遇到無法註冊次數 / 提示賬號已註冊 / …

當我們把問題定義清楚，剩下就是交給專業的資料人員分析即可，分析人員即可基於業務人員的假設而分析出每個因素對最終結果是否有影響。

當你掌握不了如何定義資料可分析問題時，建議把業務問題和假設描述清楚，與資料人員充分溝通。

最後，再次重點推薦業務人員或資料人員多基於業務嘗試做資料假設，並仔細用資料做驗證，這個是培養業務洞察和資料思維的有效手段。

Next

本篇文章比較多是根據筆者大飛自己的觀察和自身經歷，免不了一些主觀上的理解和判斷，每個人對於資料思維的理解可能不太一樣，歡迎有興趣的朋友一同交流探討。

九日論道的主筆人（論主）正式從老東家掃描全能王（17年-20年），見證收入的歷史級變化，功成身退，如今一頭扎進了新的浪潮。論主現在正式開啟增長諮詢業務，從短期問題諮詢到長期伴隨式的增長服務都是avaliable的。論主我甚至不止一次幫助個人開發者從打工者變成了百萬年收入的老闆。

說白了，我覺得產品沒有那麼難賺錢。山寨的產品一點不可恥，只要你的產品有人用，那託管到我這邊，我送你八字：增長在手，江山你有。



作者：大Fei
來源：九日論道