本帖由東南亞最大的超級應用程序之一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），或用戶使用的功能。
行為屬性類型
大多數事件都有與它們相關的類型。區分類型對獲取可操作數據很重要。一些例子：
- 騎行已取消：用戶發起與系統發起
- 已選擇付款：信用卡與電匯
- 上傳的照片：相機與畫廊
- 登錄成功：谷歌對臉書對電子郵件對電話
為了弄清楚我問的問題類型，例如：
- 誰負責這種轉換（或失敗）？
- 什么原因導致了這種轉換（或失敗）？
- 這個用戶在完成此操作時有哪些偏好？
- 我如何描述此操作最重要的用戶旅程路徑？
- 我還可以使用哪些其他信息來預測此用戶基于此操作的未來操作？
上下文屬性
上下文屬性是那些幫助我理解哪些因素可能會影響用戶完成或不完成目標的動機。一些例子：
- 屏幕上的驅動程序數量
- 顯示的商家類型
- 搜索結果的編號
我發現有助于發現上下文屬性的問題可能包括：
- 什么因素會影響用戶完成目標的動力？
- 我如何區分動機的增減？
- 想象一下，這是我們從用戶那里跟蹤的最后一個事件。關于這次經歷，我們想知道什么？
