東南亞最大消費App：大資料分析為什麼大多數會失敗？

banq發表於2022-02-12
APP大資料

東南亞最大消費app的商業智慧副總裁的BI經驗證明：沒有業務領域深入挖掘，就得不到大資料分析帶來的業績提升，只會導致大資料殺熟敲詐。
本帖由東南亞最大的超級應用程式之一Gojek的前商業智慧BI高階副總裁Crystal撰寫，本文雖然沒有提到DDD領域驅動設計，但是其資料分析的軌跡恰好與DDD、事件風暴等理論概念符合，首先她發現沒有DDD統一通用語言，因此她建立了事件字典，這種類似漢語字典的業務本體語言表達，統一了團隊業務用詞與術語，然後，針對事件提出了抽象和詳細的設計意見，雖然這些事件基本是介面相關事件，有可能和“核心業務邏輯”無關，但是也是屬於事件風暴中領域事件設計範疇，因為所謂“核心業務邏輯”是由領域事件派生出來的，文章中大量有關領域事件設計細節對事件風暴、事件建模等DDD戰略分析設計都有幫助，包括事件旅程的追蹤和追溯，可以直接落地為事件溯源eventsourcing，以下是摘要，原文點選標題：
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、紅杉投資組合公司和其他公司等初創企業在迷宮中導航。
除了所有工具外，還有一個基礎的事情可以促成或破壞公司內部的任何資料倡議：您如何思考跟蹤什麼，如何跟蹤它，以及如何隨著時間的推移對其進行管理。
如果你把這些原則方法弄錯了，世界上最好的工具不會拯救你。
 
在本帖中，我分析了：
  1. 資料症狀 - 團隊在資料問題方面最常見的症狀。
  2. 資料問題的根本原因 - 這些症狀的實際根本原因。
  3. 分步流程-我逐步瞭解如何思考要跟蹤的內容，如何跟蹤它，以及如何隨著時間的推移對其進行管理，並配有事件跟蹤器模板，以幫助指導流程。


 
大多數公司可能會將自己的資料描述為“混亂”。當他們這麼說時，他們通常指的是少數常見症狀之一：
  1. 缺乏共享語言
  2. 知識轉讓緩慢
  3. 缺乏信任
  4. 無法快速處理資料

缺乏領域共享通用統一語言：
在應用程式中描述相同體驗的方法有很多。如果您問您的團隊“使用者如何結賬？”——在許多情況下，沒有人會使用相同的術語說出相同的步驟集。
當應用程式中有多種方法做同樣的事情時，或者當導航選項卡是未命名的圖示時，這主要是個問題。例如定價頁面可以是定價概覽或詳細定價。是描述檔案還是帳戶設定？這些聽起來可能相同，但在許多產品中有所不同。
缺乏共享語言開始使資料變得無用。與其他團隊就資料進行深思熟慮的討論或對資料的實際含義達成共識需要花費更多時間。更糟糕的是，當團隊真的不理解時，他們可能會認為他們有一個共同的理解。這種摩擦通常會導致沮喪和完全避免使用資料。

 
上述挑戰在於它們只是症狀。許多團隊試圖透過以下方法解決症狀：
  • 新工具
  • 更好的/更多的培訓
  • 要求更高的技術/分析標準來招聘

但通常，這些事情可能會浪費時間和金錢，因為你沒有解決根本原因和實際問題。相反，根本原因通常源於以下一個或多個：
  1. 分析指標，而不是如何跟蹤指標。
  2. 開發者/資料思維與業務使用者思維。
  3. 抽象程度錯誤。
  4. 僅書面與視覺溝通
  5. 資料作為一個專案與正在進行的倡議

瞭解它們對於成功團隊和失敗團隊分開很重要，所以讓我們單獨檢查每個團隊。
 
許多團隊認為，資料分析的目標是跟蹤指標。然而，真正的資料分析目標是分析這些指標。
這兩件事非常不同。
後者是我們如何使資訊可操作。使資訊可操作性不是報告做某事的人數，而是我們如何區分成功人士和失敗者在我們的產品中做什麼，以便我們能夠採取措施進行改進。這種細微差別通常會消失，但正如您將看到的那樣，我們如何處理跟蹤的內容和跟蹤它的方式發生了根本變化。
 
跟蹤最難做的事情之一是正確地抽象了跟蹤的內容。糟糕的跟蹤是指當我們的領域或介面事件過於抽象寬泛具有普遍性，良好的跟蹤是指當我們的領域或介面事件比較具體，出色的領域或介面事件設計是指當我們平衡這兩者。
 

讓我們考慮一個常見的使用者註冊事件。
  • （壞）“Facebook註冊”或“谷歌註冊”-在這種情況下，我們根據“來源”將事件命名為來自“Facebook註冊”和“谷歌註冊”。然而，它太寬泛了。這是否意味著只是在介面選擇selected註冊按鈕但是沒有點選？或已經是註冊成功完成？如果註冊嘗試卻失敗了怎麼辦？僅僅透過檢視事件名稱，我不知道這些問題的答案。此外，如果我想知道這些註冊中有多少次，我需要單獨新增所有這些獨特的事件，使任何潛在的分析對任何PM來說都乏味和令人望而卻步。
  • （好的）“註冊已點選”-在這種情況下，我們對事件非常具體。在這裡，我至少確切地知道事件發生時意味著什麼。挑戰在於，如果我想檢視所有選定的註冊來源。我不知道存在哪些來源，也很難做出實際決定。雖然我們有透過事件行為行為的“症狀”，但我們沒有能力透過引數值“診斷”。
  • （很棒）“註冊已選中”-在本例中，我們有正確的抽象水平。事件是明確的，已經選擇了註冊方法，我對源事件需要設立有一個專門來源屬性，以便在需要時可以追溯。

   

透過設計事件字典統一領域語言：
事件跟蹤詞典中的欄位屬性有專門規定，像一部字典一樣，字典中的基礎欄位是：
  • 事件名稱 - 操作的名稱。最佳使用特定短語命名，這些短語可能由資深使用者用來描述他們的行為
  • 當...觸發時-作為此事件及其屬性傳送到我們日誌的快照的特定API響應、使用者操作或事件。
  • 螢幕 - 顯示觸發操作時使用者位置的截圖或影像
  • 屬性-將隨此事件一起跟蹤的屬性名稱列表（例如源，isLoggedIn）
  • 屬性值示例-最好詳盡無遺地完成，上面每個屬性下的潛在值列表。在潛在價值集有限的情況下（例如Facebook、電子郵件、Google等潛在的註冊來源），最好在這裡列出它們。
  • 資料/屬性型別-每個屬性都應限制為一種資料型別，如布林值、字串、數字、緯度和經度或浮點。
  • 描述 - 您如何描述此事件被記錄給以前從未使用過該產品的人？使用此欄位消除未來使用該欄位的業務團隊和執行這些規範的工程團隊之間任何錯位的可能性。
  • 技術評論-OAuth、API和內部服務可以有自己的怪癖，你想在這裡詳述。像將2XX個響應聚合到單個“成功”值這樣的規範可以在這裡進行。
  • 測試評論-這是一個活生生的、令人呼吸的文件。當新功能釋出時，最好透過QA並確保事件在必要時引發。在這裡傳達更改和問題可以快速解決問題。

 
團隊拓撲與產品管理：
大多數分析系統的終端使用者都是業務使用者。我們需要構建一些與該終端使用者產生共鳴的東西。這意味著使資料和分析過程人性化。這會影響我們如何選擇要使用的工具、要跟蹤的事件、如何命名事件以及需要什麼屬性。在這裡花費有意義的時間是值得的，就像我們在新產品的客戶研究中一樣。
為了進入業務使用者的心態，我經歷了四個層次的問題。對於每個問題，我都提供了我最近合作過的一個名為Honeydu的產品中的一些示例，Honeydu是公司線上免費傳送和接收發票的一種方式。
  1. 業務目標和目的是什麼？業務和執行團隊正在最佳化哪些關鍵結果和指標？這些資訊的來源將是當前和歷史的OKR、季度和年度規劃檔案以及董事會甲板。示例一：X個新使用者在2020年第四季度末之前收到/傳送發票示例二：傳送給新使用者的發票的X%會導致新使用者註冊示例三：2020年第四季度末活躍的X張經常性發票
  2. 每個團隊的目標和目的是什麼？公司的高水平目標是不夠的。每個團隊通常都有一套目標和目的，這些目標和目的可以提升到公司級別的指標。要了解這些目標和目的，您可以找出每個團隊的 OKR，與團隊領導交談等。在這裡，您想了解他們在歷史上的幾個時間段時間段，以及團隊領導在將來的幾個時間段時間裡的想法。示例一：（新使用者增長）前7天內傳送2張發票示例二：（付款整合）85%的新付款方式已成功驗證示例三：（NUX）以發票模板開頭的新使用者百分比
  3. 圍繞這些目標和目的，產品體驗有哪些？接下來，對於每個目標/目標，我確定與推動這些目標/目標對應的產品體驗。重要的是，不僅要識別產品或漏斗的特定螢幕，還要識別可能影響目標或行動的體驗背景。例如，在優步這樣的拼車產品中，如果產品體驗是預訂拼車，除了預訂拼車的漏斗外，我可能還想知道地圖上有多少司機？或者，預計時間是多少？第1步：在Honeydu中，許多不同的因素可能導致使用者傳送他們的第一張發票，這是我們的核心行動。我們會問自己：
    • 當使用者選擇要向其傳送發票的聯絡人時，當使用者的歷史業務列表中有聯絡人時，或者當他們需要搜尋時，他們更有可能成功嗎？
    • 哪些支援操作可以幫助使用者建立和傳送他們的第一張發票？發票模板是加快傳送時間的好方法嗎？還是更重要的是，他們的聯絡人首先匯入？

    第2步：下一步是思考可能阻止使用者實現我們的目標和目的的經驗。在Honeydu的案例中，我會問：為什麼新使用者沒有成功建立他們的第一張發票？他們是否檢視了不同的模板，但沒有找到與他們相關的模板？他們是否嘗試從頭開始建立發票，發現回到我們的模板目錄太難了？我們已啟用的使用者執行了哪些操作，而未啟用的使用者沒有執行？
    第3步：最後，想象一下，任何事件都可能是我們在產品中從使用者那裡跟蹤的最後一個事件。關於這次經歷，我們想知道什麼？我們需要知道他們在聯絡搜尋後是否獲得了“未找到結果”頁面，或者在新增新付款方式時出錯，並利用這些活動的受歡迎程度開始對我們使用者體驗中的問題進行分類診斷。
  4. 我/他們可能想圍繞這些目標和產品體驗回答哪些問題/假設？
    接下來，我想一想他們（或我）在這些目標或目的周圍可能有什麼問題或假設。同樣，在這裡，與團隊領導或團隊中的個人貢獻者討論他們面臨的問題。但也請自己思考，提出問題的假設，並與該團隊驗證這些問題的重要性水平。
    示例一：Honeydu上的關鍵目標和產品體驗之一是有人傳送他們的第一張發票。我想問一個問題，我認為需要哪些經驗才能有人對向企業傳送發票有信心？像“他們需要使用我們行業批准的模板之一”或“他們看到Honeydu網路中已經列出的業務”這樣的假設表明，我們需要能夠跟蹤經驗，以便量化並從假設轉向對相關性/因果關係的信心。
    示例二：透過Honeydu支付發票的使用者越多，我們產生的收入就越多。我們應該跟蹤使用者最有可能在什麼時候支付發票，問問自己“使用者什麼時候最有可能透過Honeydu支付發票？今天什麼時候到期？明天？”透過跟蹤Pay Invoice Success事件上的 daysTillDueDate屬性，我們可以為那些沒有自然地看到發票到期日而不在自然傾向之外傳送垃圾郵件的使用者提供資訊並構建我們的推送通知和電子郵件策略。

    東南亞最大消費App：大資料分析為什麼大多數會失敗？
    後續見下：

    5.

    相關文章