為什麼大多數分析工作都以失敗告終

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

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

我很幸運有機會在Gojek只有30位員工的時候就加入，並在4年半的時間裡領導了公司的商業智慧和增長部門的發展，幫助它成為東南亞最大的消費交易技術集團。Gojek成功的關鍵之一是透過健全而簡單的資料系統為其賦能，以快速做出基於資料的決策。

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

於是我招了3個資料倉儲團隊成員，我們把所有的資料都放到了一個帶有Pentaho ETL功能的Postgres資料倉儲中。但由於我們的規模迅速增長，這個方法在8個月內就變得毫無用處了。之後我們就遷移到了谷歌雲平臺，並開始使用BigQuery、BigTable、Data Flow、Airflow等。

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

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

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

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

1. 資料症狀：面對資料問題，團隊會經歷的一系列常見“症狀”

2. 資料問題的根本原因：產生這些症狀的實際根源

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

"我們的資料一團糟!"

我幫助過的一個團隊認為他們對入職流程進行了6個多月的追蹤，但從未"使用"和分析過這些資料，最初做這項工作的人決定離開公司。對團隊進行了調研後，我就發現基本沒有任何資料是被正確記錄的。例如，資料顯示，在入職培訓中做了某個動作的人比點選"註冊"的人多，這壓根是不可能的。這些資料最後都是沒有用的。

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

1. 缺乏統一語言/雞同鴨講

2. 知識轉移緩慢

3. 缺少信任

4. 無法迅速對資料採取行動

缺乏統一語言/雞同鴨講

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

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

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

知識轉移緩慢

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

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

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

缺少信任

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

無法迅速對資料採取行動

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

根本原因

解決上述問題的挑戰在於它們只是“症狀”。許多團隊試圖用一些方法來解決這些症狀，例如：

·新的工具

·更好/更多的培訓

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

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

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

·開發者思維/資料思維 vs 商業使用者思維

·錯誤的抽象水平

·書面交流 vs 視覺交流

·資料僅作為一個專案 vs 持續倡議

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

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

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

開發者思維/資料思維 vs 商業使用者思維

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

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

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

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

錯誤的抽象水平

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

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

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

一般的追蹤："點選註冊"。在這種情況下，我們已經對事件進行了非常具體的分析。在這裡，我們至少知道當事件發生時它意味著什麼。但是挑戰在於，當想檢視所有被選中的註冊來源的時候，我們並不知道有哪些來源存在，而且很難做出實際的決策。雖然我們透過事件掌握了行為的 "症狀"，但我們沒有能力透過引數值進行 "診斷"。

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

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

書面交流 vs 視覺交流

對於分析事件是什麼和意味著什麼，有一個共同的"真相"來源是至關重要的。糟糕的資料團隊不會有任何型別的事件字典或書面檔案來說明被追蹤的內容，而是讓團隊有自己的定義和解釋;好的團隊至少會有一個共享且持續更新的字典;而更好的團隊則會把視覺交流與書面交流相結合。

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

資料僅作為一個專案 vs 持續倡議

最後，我們來談談是將資料僅視為一個專案還是一個持續進行的核心計劃。你必須把資料系統當作一個不斷迭代的產品。隨著時間的推移，產品會改變，目標會改變，業務也會改變。因此，如果你沒有不斷地迭代資料系統，就會面臨Brian Balfour所說的 "資料死亡之輪"。

循序漸進的過程

工具——事件追蹤詞典

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

我們提供了一個模板和一個例子，點選下方連結獲取：

事件追蹤字典中的欄位

字典中的基本欄位如下：

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

·Triggers when...-觸發機制：一個特定的API響應、使用者操作或事件，這個事件的快照和它的屬性被髮送到我們的日誌裡去

·Screen-螢幕：使用者在行動被觸發時所處位置的螢幕截圖或影像

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

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

·Data/Property Type-資料/屬性型別 - 每個屬性應該限制為一種資料型別，如布林值、字串、數字、經緯度或浮點數

·Description-描述：你將如何向從未使用過該產品的人描述這個被捕獲的事件?使用這個欄位來消除未來接手的業務團隊和實施這些規範的工程團隊之間產生誤解的可能性。

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

·Testing Comments-測試註釋：這是一個活生生的文件。當新功能釋出時，最好是透過QA，確保必要的事件發生。在這裡溝通更改和問題將有助於快速解決問題。

本文作者Crystal Widjaja是東南亞最大的超級應用之一Gojek的前增長和商業智慧高階副總裁。

譯者簡介： 殷之涵 （Jane） ，康奈爾大學生物統計與資料科學專業，A La Lune London戰略總監。