獨(dú)家 | 為什么大多數(shù)分析工作都以失敗告終

作者：Crystal Widjaja

翻譯：殷之涵

校對：王可汗

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

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

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

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

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

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

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

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

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

1. 數(shù)據(jù)癥狀：面對數(shù)據(jù)問題，團(tuán)隊(duì)會經(jīng)歷的一系列常見“癥狀”

2. 數(shù)據(jù)問題的根本原因：產(chǎn)生這些癥狀的實(shí)際根源

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

"我們的數(shù)據(jù)一團(tuán)糟！"

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

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

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

2. 知識轉(zhuǎn)移緩慢

3. 缺少信任

4. 無法迅速對數(shù)據(jù)采取行動

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

在一個APP中，有大量的不同方法來描述相同的體驗(yàn)。如果你問你的團(tuán)隊(duì)"用戶是如何結(jié)賬的"，在很多情況下，沒有人會給出同樣的步驟、使用同樣的術(shù)語。

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

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

知識轉(zhuǎn)移緩慢

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

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

站在內(nèi)部員工的角度看待培訓(xùn)，這一點(diǎn)更加真實(shí)——員工更希望把他們的時間花在工作上，而不是在無休止的培訓(xùn)里浪費(fèi)時間。

缺少信任

當(dāng)你查看或展示數(shù)據(jù)時，有多少次會在心里懷疑："這數(shù)據(jù)真的是對的嗎？"大多數(shù)數(shù)據(jù)的一個常見癥狀是，組織中的人就是不信任它。有時候這是因?yàn)閿?shù)據(jù)質(zhì)量確實(shí)糟糕，但也可能是因?yàn)槿藗儗δ硞€事件或特性的含義本來就存在誤解。

無法迅速對數(shù)據(jù)采取行動

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

根本原因

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

新的工具

更好/更多的培訓(xùn)

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

但通常這些方法可能只是浪費(fèi)時間和金錢，因?yàn)槟銢]有找到根本原因和真正的問題所在。根本原因通常源于以下一個或多個方面：

以追蹤指標(biāo)為目標(biāo)vs分析指標(biāo)

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

錯誤的抽象水平

書面交流 vs 視覺交流

數(shù)據(jù)僅作為一個項(xiàng)目 vs 持續(xù)倡議

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

以追蹤指標(biāo)為目標(biāo)vs分析指標(biāo)

許多團(tuán)隊(duì)認(rèn)為數(shù)據(jù)計(jì)劃的目標(biāo)是追蹤指標(biāo)，但真正的目標(biāo)是分析這些指標(biāo)——這兩件事是非常不同的，后者指的是我們?nèi)绾问剐畔⒕哂小翱刹僮餍浴薄Ｊ剐畔⒕哂锌刹僮餍圆⒉皇菆蟾嫱瓿闪四臣虑榈娜藬?shù)，而是我們?nèi)绾螀^(qū)分在某個事件（例如完成訂單）上“成功”的用戶和“失敗”的用戶在我們的產(chǎn)品中分別做了什么，以便我們能夠采取步驟進(jìn)行改進(jìn)。這一細(xì)微差別通常被忽略，但正如你將看到的那樣，它從根本上改變了我們?nèi)绾螌Υ覀兯粉櫟臇|西以及追蹤它的方式。

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

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

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

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

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

錯誤的抽象水平

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

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

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

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

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

讓情況變得更加復(fù)雜的是，我經(jīng)常發(fā)現(xiàn)團(tuán)隊(duì)將不同的抽象水平混在一起?；蛘撸捎谟脩袈贸毯彤a(chǎn)品重新設(shè)計(jì)不可避免地導(dǎo)致了新的產(chǎn)品流，不同的實(shí)現(xiàn)“時代”使得抽象水平更加混亂。這使得系統(tǒng)變得更加混亂和難以理解。我們會在下文中如何達(dá)到正確的抽象水平這一步驟中談及更多。

書面交流 vs 視覺交流

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

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

數(shù)據(jù)僅作為一個項(xiàng)目 vs 持續(xù)倡議

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

循序漸進(jìn)的過程

工具——事件追蹤詞典

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

我們提供了一個模板和一個例子，點(diǎn)擊下方鏈接獲取：

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

事件追蹤字典中的字段

字典中的基本字段如下：

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

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

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

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

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

Data/Property Type-數(shù)據(jù)/屬性類型 - 每個屬性應(yīng)該限制為一種數(shù)據(jù)類型，如布爾值、字符串、數(shù)字、經(jīng)緯度或浮點(diǎn)數(shù)

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

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

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

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

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

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

原文標(biāo)題：

Why Most Analytics Efforts Fail

原文鏈接：

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