大數(shù)據(jù)文摘授權(quán)轉(zhuǎn)載自數(shù)據(jù)派THU

作者：Crystal Widjaja

翻譯：殷之涵

校對(duì)：王可汗

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 缺少信任

4. 無法迅速對(duì)數(shù)據(jù)采取行動(dòng)

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

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

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

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

知識(shí)轉(zhuǎn)移緩慢

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

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

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

缺少信任

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

無法迅速對(duì)數(shù)據(jù)采取行動(dòng)

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

根本原因

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

新的工具
更好/更多的培訓(xùn)
提高招聘中對(duì)候選人技術(shù)能力、分析能力的要求
但通常這些方法可能只是浪費(fèi)時(shí)間和金錢，因?yàn)槟銢]有找到根本原因和真正的問題所在。根本原因通常源于以下一個(gè)或多個(gè)方面：
以追蹤指標(biāo)為目標(biāo)vs分析指標(biāo)
開發(fā)者思維/數(shù)據(jù)思維 vs 商業(yè)用戶思維
錯(cuò)誤的抽象水平
書面交流 vs 視覺交流
數(shù)據(jù)僅作為一個(gè)項(xiàng)目 vs 持續(xù)倡議

理解它們對(duì)于區(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)绾问剐畔⒕哂小翱刹僮餍浴薄Ｊ剐畔⒕哂锌刹僮餍圆⒉皇菆?bào)告完成了某件事情的人數(shù)，而是我們?nèi)绾螀^(qū)分在某個(gè)事件（例如完成訂單）上“成功”的用戶和“失敗”的用戶在我們的產(chǎn)品中分別做了什么，以便我們能夠采取步驟進(jìn)行改進(jìn)。這一細(xì)微差別通常被忽略，但正如你將看到的那樣，它從根本上改變了我們?nèi)绾螌?duì)待我們所追蹤的東西以及追蹤它的方式。

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

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

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

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

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

錯(cuò)誤的抽象水平

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

以“注冊(cè)”這個(gè)常見的事件為例。

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

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

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

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

書面交流 vs 視覺交流

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

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

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

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

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

工具——事件追蹤詞典

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

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

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

事件追蹤字典中的字段

字典中的基本字段如下：

Event Name-事件名：行動(dòng)的名稱。最好使用一個(gè)成熟用戶可能用來描述其行為的特定短語(yǔ)來命名
Triggers when...-觸發(fā)機(jī)制：一個(gè)特定的API響應(yīng)、用戶操作或事件，這個(gè)事件的快照和它的屬性被發(fā)送到我們的日志里去
Screen-屏幕：用戶在行動(dòng)被觸發(fā)時(shí)所處位置的屏幕截圖或圖像
Properties-屬性：和此事件一起被追蹤的屬性名稱的列表（例如來源、是否登錄等）
Example Property Value-屬性值示例：最好是詳盡、無遺漏地列出上述每個(gè)屬性下的潛在值。在潛在值有限的情況下（例如潛在的注冊(cè)來源有Facebook、Email、Google等），最好全部列出它們。
Data/Property Type-數(shù)據(jù)/屬性類型 - 每個(gè)屬性應(yīng)該限制為一種數(shù)據(jù)類型，如布爾值、字符串、數(shù)字、經(jīng)緯度或浮點(diǎn)數(shù)
Description-描述：你將如何向從未使用過該產(chǎn)品的人描述這個(gè)被捕獲的事件？使用這個(gè)字段來消除未來接手的業(yè)務(wù)團(tuán)隊(duì)和實(shí)施這些規(guī)范的工程團(tuán)隊(duì)之間產(chǎn)生誤解的可能性。
Technical Comments-技術(shù)評(píng)論：OAuth、API和內(nèi)部服務(wù)可能有自己的特殊習(xí)慣，因此要在這里詳細(xì)說明，例如像將多個(gè)響應(yīng)結(jié)果聚合成一個(gè)單一的 "success"值的規(guī)范等。
Testing Comments-測(cè)試注釋：這是一個(gè)活生生的文檔。當(dāng)新功能發(fā)布時(shí)，最好是通過QA，確保必要的事件發(fā)生。在這里溝通更改和問題將有助于快速解決問題。

原文標(biāo)題：

Why Most Analytics Efforts Fail

原文鏈接：

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

點(diǎn)「在看」的人都變好看了哦！

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

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

根本原因

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

Why Most Analytics Efforts Fail