獨家 | 為什么大多數分析工作都以失敗告終

作者：Crystal Widjaja

翻譯：殷之涵

校對：王可汗

日均訂單量從兩萬提高到五百萬；商業(yè)智能部門從無到有，如今已有100位員工；增長部門完成從8人到85人的發(fā)展。所有這些都在4年半內完成。這是一次瘋狂的旅程，但并不是美國創(chuàng)業(yè)界許多人所熟悉的那樣。這不是Uber或Lyft，而是Gojek，東南亞最大的超級APP。

對于那些不熟悉Gojek或“超級APP”概念的人來說，簡而言之，這個產品可以滿足你所有的需求：訂餐、交通、數字支付、社區(qū)送貨，以及其他十幾種服務。從服務規(guī)模上看，Gojek每天完成的訂餐量比Grubhub、Uber Eats和DoorDash的總和還要多，每天的出行訂單數也比Lyft多。

我很幸運有機會在Gojek只有30位員工的時候就加入，并在4年半的時間里領導了公司的商業(yè)智能和增長部門的發(fā)展，幫助它成為東南亞最大的消費交易技術集團。Gojek成功的關鍵之一是通過健全而簡單的數據系統(tǒng)為其賦能，以快速做出基于數據的決策。

但一開始的時候并非如此。在我剛加入公司的時候，"IT "人員正在運行SQL查詢。僅僅一周的時間，我就意識到這些查詢中的大多數都是非常不準確的，而且大多數人壓根就不明白數據到底是什么。有人給了我一張便利貼，上面寫著已完成訂單的確認方法（flag_booking=2，booking_status=4）。沒有數據基礎設施，所有的查詢結果都被復制粘貼到excel報告中，并通過電子郵件手動發(fā)送給領導。

于是我招了3個數據倉庫團隊成員，我們把所有的數據都放到了一個帶有Pentaho ETL功能的Postgres數據倉庫中。但由于我們的規(guī)模迅速增長，這個方法在8個月內就變得毫無用處了。之后我們就遷移到了谷歌云平臺，并開始使用BigQuery、BigTable、Data Flow、Airflow等。

我們也經歷了對各種可視化工具的應用探索。從Tableau開始，接著是Metabase，第3年開始使用公司的內部工具。我們的實驗平臺從手動上傳CSV到BigQuery表格，再到類似Airbnb的ERF那樣的內部系統(tǒng)。

毋庸置疑，我在Gojek開始了我的數據之路，并且一直在幫助像Carousell、Cashdrop、CRED、Celo、紅杉資本投資的一系列公司以及其他的初創(chuàng)公司走過這個迷宮。除了所有的工具之外，有一個基礎性的前提決定了公司內任何數據計劃的成敗——你得考慮好到底要追蹤什么、如何追蹤，以及如何隨著時間的推移管理追蹤到的結果。

如果把這些事情都搞錯了，即使是世界上最好的工具也救不了你。

這篇文章可以被拆解為如下3個主題：

1. 數據癥狀：面對數據問題，團隊會經歷的一系列常見“癥狀”

2. 數據問題的根本原因：產生這些癥狀的實際根源

3. 循序漸進的解決方案：我的循序漸進的過程，我認為什么要跟蹤，如何跟蹤它。隨著時間的推移來管理它，并使用Event Tracker模板來幫助指導這個過程。

"我們的數據一團糟！"

我?guī)椭^的一個團隊認為他們對入職流程進行了6個多月的追蹤，但從未"使用"和分析過這些數據，最初做這項工作的人決定離開公司。對團隊進行了調研后，我就發(fā)現基本沒有任何數據是被正確記錄的。例如，數據顯示，在入職培訓中做了某個動作的人比點擊"注冊"的人多，這壓根是不可能的。這些數據最后都是沒有用的。

這個故事和我的便利貼故事都很常見，大多數公司可能都會自述他們的數據一團糟。當他們這樣說的時候，情況通常指向以下幾個常見癥狀之一：

1. 缺乏統(tǒng)一語言/雞同鴨講

2. 知識轉移緩慢

3. 缺少信任

4. 無法迅速對數據采取行動

缺乏統(tǒng)一語言/雞同鴨講

在一個APP中，有大量的不同方法來描述相同的體驗。如果你問你的團隊"用戶是如何結賬的"，在很多情況下，沒有人會給出同樣的步驟、使用同樣的術語。

這主要因為在一個APP中有多種方法做同樣的事情，或者導航標簽（Navigation Tabs）里面有未命名的圖標。比如，“價格頁面”既可以指價格概覽頁面，也可以指價格詳情頁面；又比如，某個頁面到底叫做“個人資料”還是“賬戶設置”？這些可能聽起來是同一個東西，但在很多產品中又是不同的。

統(tǒng)一語言的缺乏讓數據變得無用。我們需要花更多的時間和其他團隊就數據進行深入的討論，或者對數據的實際含義達成共識。更糟糕的是，團隊可能認為他們有一個共同的理解，但實際上并沒有。這種阻力通常會導致人們的挫敗感，以及從根本上避免對數據的使用。

知識轉移緩慢

當新人加入團隊、員工轉換團隊或者有人離開公司時，在接替者"完全有生產力"之前，都需要進行知識轉移。特別是在當下每個人平均每隔18個月就換一次工作、甚至以更頻繁的節(jié)奏轉換團隊的就業(yè)環(huán)境下，知識轉移尤為關鍵。

許多團隊通過大量的入職培訓來彌補他們糟糕的數據產品所造成的問題，但這最終只起到“創(chuàng)可貼”的作用。這就跟試圖用大量的新用戶指導、規(guī)則解釋和培訓來彌補一個非常糟糕的產品是一樣的。隨著時間的推移，這些東西變得昂貴而無效。

站在內部員工的角度看待培訓，這一點更加真實——員工更希望把他們的時間花在工作上，而不是在無休止的培訓里浪費時間。

缺少信任

當你查看或展示數據時，有多少次會在心里懷疑："這數據真的是對的嗎？"大多數數據的一個常見癥狀是，組織中的人就是不信任它。有時候這是因為數據質量確實糟糕，但也可能是因為人們對某個事件或特性的含義本來就存在誤解。

無法迅速對數據采取行動

上述所有問題其實都指向一個宏觀的癥狀——無法迅速對數據采取行動。在一個充滿季度OKR和市場高速競爭的世界里，團隊永遠受到時間和資源的限制。當面臨以下權衡時：A.花費大量時間來獲取他們信任和理解的數據、B.跳過這一步直接推進工作，很多團隊都會選擇后者。

根本原因

解決上述問題的挑戰(zhàn)在于它們只是“癥狀”。許多團隊試圖用一些方法來解決這些癥狀，例如：

新的工具

更好/更多的培訓

提高招聘中對候選人技術能力、分析能力的要求

但通常這些方法可能只是浪費時間和金錢，因為你沒有找到根本原因和真正的問題所在。根本原因通常源于以下一個或多個方面：

以追蹤指標為目標vs分析指標

開發(fā)者思維/數據思維 vs 商業(yè)用戶思維

錯誤的抽象水平

書面交流 vs 視覺交流

數據僅作為一個項目 vs 持續(xù)倡議

理解它們對于區(qū)分成功和失敗的團隊非常重要，我們將逐一展開解釋。

以追蹤指標為目標vs分析指標

許多團隊認為數據計劃的目標是追蹤指標，但真正的目標是分析這些指標——這兩件事是非常不同的，后者指的是我們如何使信息具有“可操作性”。使信息具有可操作性并不是報告完成了某件事情的人數，而是我們如何區(qū)分在某個事件（例如完成訂單）上“成功”的用戶和“失敗”的用戶在我們的產品中分別做了什么，以便我們能夠采取步驟進行改進。這一細微差別通常被忽略，但正如你將看到的那樣，它從根本上改變了我們如何對待我們所追蹤的東西以及追蹤它的方式。

開發(fā)者思維/數據思維 vs 商業(yè)用戶思維

構建任何優(yōu)秀產品都有一個核心原則——深入了解你的目標用戶/客戶、體會他們的感受。在建立數據系統(tǒng)時，許多團隊都忽略了他們的客戶是誰，或者根本就沒有考慮到他們的客戶是“商業(yè)用戶（business user）”這一事實。

構建優(yōu)秀的分析系統(tǒng)，首先要深刻理解業(yè)務用戶的問題和能力，就像你對產品的目標客戶那樣。以Gojek為例，我們的大多數商業(yè)用戶并非SQL分析員，而是非技術崗位的產品經理、營銷人員或運營經理。

他們是我們的最終用戶，我們專門為他們構建，目標是使數據和分析過程人性化。這影響了我們思考所有事情的方式，從使用什么工具，跟蹤什么事件，如何給事件命名，到需要什么屬性。

對我們來說，真正的考驗是——我們的運營/客戶服務團隊成員能否在沒有完整的入職培訓的情況下訪問事件追蹤工具和用戶界面平臺并獨立使用它嗎？運營/客服團隊對市場的了解最少，與產品開發(fā)過程的距離也最遠。如果他們都能夠使用我們搭建的分析系統(tǒng)去分析問題，那么團隊的其他成員就更可能做到這一點。

錯誤的抽象水平

追蹤工作中最難做好的事情之一是對追蹤內容的正確抽象程度。壞（Bad）的追蹤是指我們的事件過于廣泛，一般（OK）的追蹤是指我們的事件過于具體，而很好（Great）的追蹤是指我們平衡了這兩者。讓我們來看一個例子。

以“注冊”這個常見的事件為例。

壞的追蹤："Facebook注冊 "或 "Google注冊"。在這種情況下，我們將事件命名為 "Facebook注冊 "和 "Google注冊"，取決于"來源"，然而這也太寬泛了。這是否意味著用戶已經選擇了一種注冊方式？注冊成功了嗎？如果嘗試了注冊失敗了呢？只看事件的名稱，我們無法得知上述問題的答案。此外，如果我們想知道有多少這樣的注冊發(fā)生，則需要單獨添加所有這些獨特的事件，這就使得任何潛在的分析都很繁瑣，而且對任何產品經理來說都是不可能的。

一般的追蹤："點擊注冊"。在這種情況下，我們已經對事件進行了非常具體的分析。在這里，我們至少知道當事件發(fā)生時它意味著什么。但是挑戰(zhàn)在于，當想查看所有被選中的注冊來源的時候，我們并不知道有哪些來源存在，而且很難做出實際的決策。雖然我們通過事件掌握了行為的 "癥狀"，但我們沒有能力通過參數值進行 "診斷"。

很好的追蹤："選擇了注冊"。在這個例子中，我們有正確的抽象層次。事件是明確的——一個注冊方法被選中了，而且它擁有“事件來源”這一屬性，這樣我們就可以在需要時通過注冊來源來劃分用戶進行分析。

讓情況變得更加復雜的是，我經常發(fā)現團隊將不同的抽象水平混在一起?；蛘?，由于用戶旅程和產品重新設計不可避免地導致了新的產品流，不同的實現“時代”使得抽象水平更加混亂。這使得系統(tǒng)變得更加混亂和難以理解。我們會在下文中如何達到正確的抽象水平這一步驟中談及更多。

書面交流 vs 視覺交流

對于分析事件是什么和意味著什么，有一個共同的"真相"來源是至關重要的。糟糕的數據團隊不會有任何類型的事件字典或書面文件來說明被追蹤的內容，而是讓團隊有自己的定義和解釋；好的團隊至少會有一個共享且持續(xù)更新的字典；而更好的團隊則會把視覺交流與書面交流相結合。

無論我們如何命名或定義事件和屬性，沒有什么比與事件相對應的視覺更清楚了。當你在討論一個事件、用戶旅程或其他數據時，人們會在腦海中想象出與之對應的屏幕和產品的各個部分。通過使分析事件變得清晰和顯而易見，這一過程可以被大大縮短。正如我將在下文所展示的那樣，我會從兩個方面來考慮這個問題：第一，事件觸發(fā)時產品中正在發(fā)生的事情的屏幕截圖；第二，將事件映射到客戶旅程的可視化表示。

數據僅作為一個項目 vs 持續(xù)倡議

最后，我們來談談是將數據僅視為一個項目還是一個持續(xù)進行的核心計劃。你必須把數據系統(tǒng)當作一個不斷迭代的產品。隨著時間的推移，產品會改變，目標會改變，業(yè)務也會改變。因此，如果你沒有不斷地迭代數據系統(tǒng)，就會面臨Brian Balfour所說的 "數據死亡之輪"。

循序漸進的過程

工具——事件追蹤詞典

在我們深入到流程的各個步驟之前，關鍵是要有一個 "工具 "來幫助組織、協調和溝通決策。為此，我使用了一個事件追蹤字典，它定義了我們正在追蹤的數據和它的一些重要方面。在共同創(chuàng)建這些規(guī)范的過程中，關于產品內各個部分的跨團隊共享語言被創(chuàng)造了出來。

我們提供了一個模板和一個例子，點擊下方鏈接獲?。?/p>

https://docs.google.com/spreadsheets/d/1UmAU9aNvGOPNY0vG-LKE5Ka2VEbbNtTSgVlob2irb-4/edit?usp=sharing

事件追蹤字典中的字段

字典中的基本字段如下：

Event Name-事件名：行動的名稱。最好使用一個成熟用戶可能用來描述其行為的特定短語來命名

Triggers when...-觸發(fā)機制：一個特定的API響應、用戶操作或事件，這個事件的快照和它的屬性被發(fā)送到我們的日志里去

Screen-屏幕：用戶在行動被觸發(fā)時所處位置的屏幕截圖或圖像

Properties-屬性：和此事件一起被追蹤的屬性名稱的列表（例如來源、是否登錄等）

Example Property Value-屬性值示例：最好是詳盡、無遺漏地列出上述每個屬性下的潛在值。在潛在值有限的情況下（例如潛在的注冊來源有Facebook、Email、Google等），最好全部列出它們。

Data/Property Type-數據/屬性類型 - 每個屬性應該限制為一種數據類型，如布爾值、字符串、數字、經緯度或浮點數

Description-描述：你將如何向從未使用過該產品的人描述這個被捕獲的事件？使用這個字段來消除未來接手的業(yè)務團隊和實施這些規(guī)范的工程團隊之間產生誤解的可能性。

Technical Comments-技術評論：OAuth、API和內部服務可能有自己的特殊習慣，因此要在這里詳細說明，例如像將多個響應結果聚合成一個單一的 "success"值的規(guī)范等。

Testing Comments-測試注釋：這是一個活生生的文檔。當新功能發(fā)布時，最好是通過QA，確保必要的事件發(fā)生。在這里溝通更改和問題將有助于快速解決問題。

 “那么，一個好的事件跟蹤字典是什么樣的？

請見下文：獨家 | 一個好的事件跟蹤字典是什么樣的？”

本文作者Crystal Widjaja是東南亞最大的超級應用之一Gojek的前增長和商業(yè)智能高級副總裁。Crystal幫助Gojek從每天2萬份訂單擴大到500萬份。

原文標題：

Why Most Analytics Efforts Fail

原文鏈接：

https://www.reforge.com/blog/why-most-analytics-efforts-fail