本帖由東南亞最大的超級應用程式之一Gojek的商業智慧BI前高階副總裁Crystal撰寫。以下是摘要，原文點選標題：
Gojek成為東南亞最大的消費交易技術集團，其超級app應用包括訂購食品、交通、數字支付、超本地送貨和十幾項其他服務。Gojek每天完成的食物訂單比Grubhub、Uber Eats和DoorDash的總和還要多，每天的旅行次數也比Lyft多。
Crystal幫助Gojek將訂單從每天2萬份增加到500萬份。商業智慧團隊從0到100人，全部在4.5年內實現增長。
當我第一次加入時，有個“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的內部系統。
從那以後，我一直在幫助Carousell、Cashdrop、CRED、Celo、紅杉投資組合公司和其他公司等初創企業在迷宮中導航。
除了所有工具外，還有一個基礎的事情可以促成或破壞公司內部的任何資料倡議：您如何思考跟蹤什麼，如何跟蹤它，以及如何隨著時間的推移對其進行管理。
如果你把這些原則方法弄錯了，世界上最好的工具不會拯救你。
在本帖中，我分析了：
- 資料症狀 - 團隊在資料問題方面最常見的症狀。
- 資料問題的根本原因 - 這些症狀的實際根本原因。
- 分步流程-我逐步瞭解如何思考要跟蹤的內容，如何跟蹤它，以及如何隨著時間的推移對其進行管理，並配有事件跟蹤器模板，以幫助指導流程。
大多數公司可能會將自己的資料描述為“混亂”。當他們這麼說時，他們通常指的是少數常見症狀之一：
- 缺乏共享語言
- 知識轉讓緩慢
- 缺乏信任
- 無法快速處理資料
缺乏領域共享通用統一語言：
在應用程式中描述相同體驗的方法有很多。如果您問您的團隊“使用者如何結賬？”——在許多情況下，沒有人會使用相同的術語說出相同的步驟集。
當應用程式中有多種方法做同樣的事情時，或者當導航選項卡是未命名的圖示時，這主要是個問題。例如定價頁面可以是定價概覽或詳細定價。是描述檔案還是帳戶設定？這些聽起來可能相同，但在許多產品中有所不同。
缺乏共享語言開始使資料變得無用。與其他團隊就資料進行深思熟慮的討論或對資料的實際含義達成共識需要花費更多時間。更糟糕的是，當團隊真的不理解時，他們可能會認為他們有一個共同的理解。這種摩擦通常會導致沮喪和完全避免使用資料。
上述挑戰在於它們只是症狀。許多團隊試圖透過以下方法解決症狀：
- 新工具
- 更好的/更多的培訓
- 要求更高的技術/分析標準來招聘
但通常，這些事情可能會浪費時間和金錢，因為你沒有解決根本原因和實際問題。相反，根本原因通常源於以下一個或多個：
- 分析指標，而不是如何跟蹤指標。
- 開發者/資料思維與業務使用者思維。
- 抽象程度錯誤。
- 僅書面與視覺溝通
- 資料作為一個專案與正在進行的倡議
瞭解它們對於成功團隊和失敗團隊分開很重要，所以讓我們單獨檢查每個團隊。
許多團隊認為，資料分析的目標是跟蹤指標。然而，真正的資料分析目標是分析這些指標。
這兩件事非常不同。
後者是我們如何使資訊可操作。使資訊可操作性不是報告做某事的人數，而是我們如何區分成功人士和失敗者在我們的產品中做什麼，以便我們能夠採取措施進行改進。這種細微差別通常會消失，但正如您將看到的那樣，我們如何處理跟蹤的內容和跟蹤它的方式發生了根本變化。
跟蹤最難做的事情之一是正確地抽象了跟蹤的內容。糟糕的跟蹤是指當我們的領域或介面事件過於抽象寬泛具有普遍性，良好的跟蹤是指當我們的領域或介面事件比較具體，出色的領域或介面事件設計是指當我們平衡這兩者。
讓我們考慮一個常見的使用者註冊事件。
- （壞）“Facebook註冊”或“谷歌註冊”-在這種情況下，我們根據“來源”將事件命名為來自“Facebook註冊”和“谷歌註冊”。然而，它太寬泛了。這是否意味著只是在介面選擇selected註冊按鈕但是沒有點選？或已經是註冊成功完成？如果註冊嘗試卻失敗了怎麼辦？僅僅透過檢視事件名稱，我不知道這些問題的答案。此外，如果我想知道這些註冊中有多少次，我需要單獨新增所有這些獨特的事件，使任何潛在的分析對任何PM來說都乏味和令人望而卻步。
- （好的）“註冊已點選”-在這種情況下，我們對事件非常具體。在這裡，我至少確切地知道事件發生時意味著什麼。挑戰在於，如果我想檢視所有選定的註冊來源。我不知道存在哪些來源，也很難做出實際決定。雖然我們有透過事件行為行為的“症狀”，但我們沒有能力透過引數值“診斷”。
- （很棒）“註冊已選中”-在本例中，我們有正確的抽象水平。事件是明確的，已經選擇了註冊方法，我對源事件需要設立有一個專門來源屬性，以便在需要時可以追溯。
透過設計事件字典統一領域語言：
事件跟蹤詞典中的欄位屬性有專門規定，像一部字典一樣，字典中的基礎欄位是：
- 事件名稱 - 操作的名稱。最佳使用特定短語命名，這些短語可能由資深使用者用來描述他們的行為
- 當...觸發時-作為此事件及其屬性發送到我們日誌的快照的特定API響應、使用者操作或事件。
- 螢幕 - 顯示觸發操作時使用者位置的截圖或影象
- 屬性-將隨此事件一起跟蹤的屬性名稱列表（例如源，isLoggedIn）
- 屬性值示例-最好詳盡無遺地完成，上面每個屬性下的潛在值列表。在潛在價值集有限的情況下（例如Facebook、電子郵件、Google等潛在的註冊來源），最好在這裡列出它們。
- 資料/屬性型別-每個屬性都應限制為一種資料型別，如布林值、字串、數字、緯度和經度或浮點。
- 描述 - 您如何描述此事件被記錄給以前從未使用過該產品的人？使用此欄位消除未來使用該欄位的業務團隊和執行這些規範的工程團隊之間任何錯位的可能性。
- 技術評論-OAuth、API和內部服務可以有自己的怪癖，你想在這裡詳述。像將2XX個響應聚合到單個“成功”值這樣的規範可以在這裡進行。
- 測試評論-這是一個活生生的、令人呼吸的文件。當新功能釋出時，最好透過QA並確保事件在必要時引發。在這裡傳達更改和問題可以快速解決問題。
團隊拓撲與產品管理：
大多數分析系統的終端使用者都是業務使用者。我們需要構建一些與該終端使用者產生共鳴的東西。這意味著使資料和分析過程人性化。這會影響我們如何選擇要使用的工具、要跟蹤的事件、如何命名事件以及需要什麼屬性。在這裡花費有意義的時間是值得的，就像我們在新產品的客戶研究中一樣。
為了進入業務使用者的心態，我經歷了四個層次的問題。對於每個問題，我都提供了我最近合作過的一個名為Honeydu的產品中的一些示例，Honeydu是公司線上免費傳送和接收發票的一種方式。
- 業務目標和目的是什麼？業務和執行團隊正在最佳化哪些關鍵結果和指標？這些資訊的來源將是當前和歷史的OKR、季度和年度規劃檔案以及董事會甲板。示例一：X個新使用者在2020年第四季度末之前收到/傳送發票示例二：傳送給新使用者的發票的X%會導致新使用者註冊示例三：2020年第四季度末活躍的X張經常性發票
- 每個團隊的目標和目的是什麼？公司的高水平目標是不夠的。每個團隊通常都有一套目標和目的，這些目標和目的可以提升到公司級別的指標。要了解這些目標和目的，您可以找出每個團隊的 OKR，與團隊領導交談等。在這裡，您想了解他們在歷史上的幾個時間段時間段，以及團隊領導在將來的幾個時間段時間裡的想法。示例一：（新使用者增長）前7天內傳送2張發票示例二：（付款整合）85%的新付款方式已成功驗證示例三：（NUX）以發票模板開頭的新使用者百分比
- 圍繞這些目標和目的，產品體驗有哪些？接下來，對於每個目標/目標，我確定與推動這些目標/目標對應的產品體驗。重要的是，不僅要識別產品或漏斗的特定螢幕，還要識別可能影響目標或行動的體驗背景。例如，在優步這樣的拼車產品中，如果產品體驗是預訂拼車，除了預訂拼車的漏斗外，我可能還想知道地圖上有多少司機？或者，預計時間是多少？第1步：在Honeydu中，許多不同的因素可能導致使用者傳送他們的第一張發票，這是我們的核心行動。我們會問自己：
- 當用戶選擇要向其傳送發票的聯絡人時，當用戶的歷史業務列表中有聯絡人時，或者當他們需要搜尋時，他們更有可能成功嗎？
- 哪些支援操作可以幫助使用者建立和傳送他們的第一張發票？發票模板是加快傳送時間的好方法嗎？還是更重要的是，他們的聯絡人首先匯入？
第2步：下一步是思考可能阻止使用者實現我們的目標和目的的經驗。在Honeydu的案例中，我會問：為什麼新使用者沒有成功建立他們的第一張發票？他們是否查看了不同的模板，但沒有找到與他們相關的模板？他們是否嘗試從頭開始建立發票，發現回到我們的模板目錄太難了？我們已啟用的使用者執行了哪些操作，而未啟用的使用者沒有執行？
第3步：最後，想象一下，任何事件都可能是我們在產品中從使用者那裡跟蹤的最後一個事件。關於這次經歷，我們想知道什麼？我們需要知道他們在聯絡搜尋後是否獲得了“未找到結果”頁面，或者在新增新付款方式時出錯，並利用這些活動的受歡迎程度開始對我們使用者體驗中的問題進行分類診斷。
- 我/他們可能想圍繞這些目標和產品體驗回答哪些問題/假設？接下來，我想一想他們（或我）在這些目標或目的周圍可能有什麼問題或假設。同樣，在這裡，與團隊領導或團隊中的個人貢獻者討論他們面臨的問題。但也請自己思考，提出問題的假設，並與該團隊驗證這些問題的重要性水平。示例一：Honeydu上的關鍵目標和產品體驗之一是有人傳送他們的第一張發票。我想問一個問題，我認為需要哪些經驗才能有人對向企業傳送發票有信心？像“他們需要使用我們行業批准的模板之一”或“他們看到Honeydu網路中已經列出的業務”這樣的假設表明，我們需要能夠跟蹤經驗，以便量化並從假設轉向對相關性/因果關係的信心。示例二：透過Honeydu支付發票的使用者越多，我們產生的收入就越多。我們應該跟蹤使用者最有可能在什麼時候支付發票，問問自己“使用者什麼時候最有可能透過Honeydu支付發票？今天什麼時候到期？明天？”透過跟蹤Pay Invoice Success事件上的 daysTillDueDate屬性，我們可以為那些沒有自然地看到發票到期日而不在自然傾向之外發送垃圾郵件的使用者提供資訊並構建我們的推送通知和電子郵件策略。
下面是幾個快速示例顯示了意圖→成功→失敗的事件旅程：
- 示例一
- 意圖：新增新付款方式並新增已提交的新付款詳細資訊
- 成功：新增新付款方式成功
- 失敗：新增新付款方式失敗
- 示例二
- 意圖：建立已選中的發票→新發票已啟動→聯絡人搜尋
- 成功：收件人已新增到發票→發票已傳送
- 失敗：已儲存發票草稿（預設操作）
2A - 成功事件
我首先仔細考慮成功事件。成功事件是指產品中的操作已成功完成。這些事件源於我在第一步中收集的業務目標。成功事件的示例可能包括：
- 付款成功
- 註冊成功
- 發票已傳送
- 已完成預訂
為了不過度跟蹤所有內容，我用一個問題對每個事件進行壓力測試。“想象一下，我確實跟蹤了這個，99%的使用者做到了，我會怎麼做？它告訴我什麼？”如果我無法找到可以極端操作的東西，那麼這個事件可能沒有幫助。
2B - 意向性事件
然後，對於每個成功事件，我都會仔細考慮意圖事件。意向性事件通常是任何成功事件的前身所需的一步。跟蹤意向事件對於理解圍繞成功事件的“原因”至關重要。
意向事件告訴我，使用者如何“受過教育”和“有動力”完成我希望他們完成的操作的一些步驟。實際上，一切都是下一個事件的故意事件——但我們通常只認為它們是“目標”，這阻礙了我們準確跟蹤它們。例如，在騎行共享應用程式中，選擇目的地是一個目標，但需要選擇騎行型別的意圖/設定事件（在舊的Lyft/Uber流程中）。然後，預訂某個騎行成為目標，但需要從搜尋/歷史等中找到目的地的意圖/設定事件......
為了想出有意圖的事件，我問——為了完成成功事件，我必須完成哪些步驟？常見的示例包括：
- 在我們的第一個旅程示例中，我們注意到了“新增新付款方式已選擇”和“新增新付款詳細資訊已提交”的意圖事件
- 請注意，我們這裡有兩個層次的意圖——高意圖，即使用者正在積極提交付款詳細資訊，以及低但指示性的意圖，即使用者選擇是透過銀行還是信用卡新增付款詳細資訊。在這些事件之間投遞會導致團隊可以執行的後續步驟：要麼使用者發現輸入欄位令人生畏，要麼當時沒有這些資訊。我們現在知道他們是否選擇了銀行或信用卡付款方式，並可以跟進更多資訊和個性化內容，以幫助使用者完成此步驟。
我還使用Intent Events意圖事件來識別使用者在完成操作時自然採取的路徑。例如，使用我們的發票和賬單支付應用程式，使用者是先匯入聯絡人還是先建立發票來發送發票？隨著我們的賬單支付網路的增長，這種行為會有什麼變化？
同樣，在Gojek的食品配送產品中，我們注意到我們最成功的使用者是那些已經知道自己想吃什麼的人，他們來Gojek只是為了完成送貨服務。這些使用者的意圖是搜尋特定的餐廳，找到他們想要的選單項，最後設定他們的送貨詳細資訊。然而，隨著這些使用者的成熟，我們注意到，隨著使用者開始更多地使用Gojek作為發現新餐廳的手段，而不是滿足他們已經認識的餐廳，最普遍的使用者意向之旅發生了變化。現在，意向性活動包括滾動瀏覽朋友的食物提要、瀏覽折扣交易或使用“附近”功能。
這些意向性事件對於理解Bangaly Kaba（Reforge EIR，Instagram前增長主管）所謂的相鄰使用者至關重要。隨著使用者的成熟和市場的擴張，這些旅程會隨著時間的推移而演變，我們的產品也應該透過匹配新使用者的意圖和成熟的使用者的意圖來實現。
2C - 故障事件
失敗事件是指發生在意圖事件和成功事件之間，阻止使用者取得成功。在意圖事件和成功事件之間存在許多使用者可能會遇到的故障路徑。瞭解失敗路徑對於理解成功路徑同樣至關重要，因為它們為我們提供了關於如何改進成功事件的可操作資訊。要想出故障事件，我問-哪些可能阻止使用者完成目標？有兩種型別的故障事件：
- 隱含失敗是指在成功完成目標之前發生的掉期。使用者只是從我們的旅程中“消失”。在我們上面的兩個旅程示例中，事件的跟蹤方式提供了兩個隱含的故障指標
- 執行Create Invoice Selected但沒有在5分鐘內執行New Invoice Started的使用者表示我們的啟用旅程失敗。
- 執行聯絡人搜尋但在5分鐘內未執行收件人新增到發票的使用者表示我們的搜尋結果或搜尋歷史記錄失敗。使用者可能沒有足夠的動力從頭開始建立聯絡人，或發現令人困惑的結果。
- 顯式故障是指預期體驗出錯的事件。
- 訂購外賣時，Lyft上的“騎行取消”或“訂單取消——餐廳關閉”等事件是明顯失敗的例子
- 在Honeydu中，新增新付款方式失敗和支付發票失敗是事件跟蹤練習中經常被遺忘的兩個例子，因為它們是對使用者行為的響應，而不是產品內實際採取的行動。但是，如果您的網路/移動應用程式收到錯誤並將其顯示給您的使用者，這些錯誤應該易於跟蹤和記錄以進行監控。將這些錯誤響應訊息儲存為事件屬性是快速診斷為什麼常見的使用者旅程可能突然失敗的簡單方法。
3 - 屬性
一旦我們成功、意圖和失敗事件，下一步就是找出我們要與事件關聯的屬性。屬性再次成為實現我們兩個主要目標的關鍵，即提供正確的抽象水平並使資料可操作。
屬性本質上是我想分割事件的方式。一個關鍵錯誤是將分割跟蹤為事件本身。例如：
- 良好：註冊選擇（事件）、來源（財產）、Facebook（財產價值）
- 錯誤：Facebook註冊已選擇
瞭解您可能需要跟蹤哪些屬性的一個關鍵來源是您在第一步中發現的問題和假設。
- 問題示例：使用者更喜歡如何新增聯絡人？
- 屬性示例：來源→歷史記錄/匯入/手動輸入
- 假設示例：與選擇構建自己的發票的使用者相比，初次自由職業者更有可能使用模板開始使用模板，並且需要更多的入職才能獲得核心價值。
- 屬性示例：模板名稱→（空）/基本發票等。
我喜歡問一些高階問題，以確定哪些屬性很重要：
- 我如何細分變得沮喪和無私的使用者？
- 我如何識別成熟使用者和臨時使用者使用的不同路徑？
- 這是否給了我足夠的細微資料來比較和對比成功使用者和下車使用者？
- 如果這是我最後一次從使用者那裡跟蹤的事件，我想知道關於使用者在這個螢幕上的體驗嗎？
屬性往往落入少數常見的桶之一。為了確保我徹底，我使用這些桶來檢視我是否遺漏了什麼：
使用者配置檔案屬性
最常見的屬性集是與使用者配置檔案相關的屬性集。這可能是人口統計或公司資訊。一些例子：
- 城市
- 年齡
- 公司規模
- 角色
- 產品等級
通常情況下，這些都是您希望能夠從屬性更改之前永久分割使用者和事件的東西。一些平臺，如Mixpanel，包含超級屬性等功能，允許您輕鬆做到這一點。要問的問題，以弄清楚要跟蹤以下哪些屬性：
- 如果我是這個使用者的個人助理，我需要了解哪些關於他們的偏好才能提供幫助？
- 哪些人口統計資訊可能會影響使用者的行為？
營銷屬性
第二組最常見的屬性是那些可能影響或影響使用者行為的與營銷相關的屬性。這可能包括以下內容：
- 來源
- 競選活動
- 條目頁面
使用者操作屬性
另一組屬性是與使用者操作相關的屬性。例如：
- 首次購買日期
- 第一種服務型別
- 訂單總數
在這裡，區分兩種型別的屬性很重要：
- 設定和忘記-這些屬性是您設定過一次，但之後不會更改。例如，首次購買日期、首次註冊署名和出生日期。
- 追加/增量-這些屬性用於細分和建立相關的個性化使用者體驗。增量屬性可以是購買總量、總收入等。新增（和刪除）使用者屬性使團隊能夠快速識別他們已經表示感興趣的促銷、新更新和體驗的相關使用者。例如，例如您已經從中購買的餐廳列表（食品配送）、您最喜歡的商店列表（超本地POI），或使用者使用的功能。
行為屬性型別
大多數事件都有與它們相關的型別。區分型別對獲取可操作資料很重要。一些例子：
- 騎行已取消：使用者發起與系統發起
- 已選擇付款：信用卡與電匯
- 上傳的照片：相機與畫廊
- 登入成功：谷歌對臉書對電子郵件對電話
為了弄清楚我問的問題型別，例如：
- 誰負責這種轉換（或失敗）？
- 什麼原因導致了這種轉換（或失敗）？
- 這個使用者在完成此操作時有哪些偏好？
- 我如何描述此操作最重要的使用者旅程路徑？
- 我還可以使用哪些其他資訊來預測此使用者基於此操作的未來操作？
上下文屬性
上下文屬性是那些幫助我理解哪些因素可能會影響使用者完成或不完成目標的動機。一些例子：
- 螢幕上的驅動程式數量
- 顯示的商家型別
- 搜尋結果的編號
我發現有助於發現上下文屬性的問題可能包括：
- 什麼因素會影響使用者完成目標的動力？
- 我如何區分動機的增減？
- 想象一下，這是我們從使用者那裡跟蹤的最後一個事件。關於這次經歷，我們想知道什麼？
原文連結在：實戰經驗：大資料分析為什麼大多數會失敗？
