資料對於我們的產品而言至關重要。資料分析幫助我們為使用我們服務的使用者提供了流暢的體驗。它也讓工程師、產品經理、資料分析師、資料科學家可以在瞭解情況後作出明智的決定。資料分析影響了 App 的每一個介面：在主介面上顯示什麼，產品以什麼順序顯示，向使用者顯示哪些相關的資訊，什麼妨礙了使用者乘車或註冊，諸如此類。
如此大的使用者群體，如此廣泛的特性，還要覆蓋所有的地理區域，這是一個很複雜的問題。而且，我們的 App 一直在推出新產品，這就要求底層的技術也要有足夠的靈活性來支援這種發展。
資料是實現這種發展的最基本工具。本文將聚焦乘客資料：我們如何收集和處理以及這些資料具體如何影響了乘客端 App 的改進。
乘客資料包含了乘客與 Uber 乘客端 App 的所有互動。其中每天都會有來自 Uber 線上系統的數十億個事件，這些事件轉換成了數百張 Apache Hive 表，為乘客端 App 的不同應用場景提供支援。
下面是可以利用乘客資料分析的主要問題領域：
- 增加漏斗轉化
- 提高使用者參與度
- 個性化
- 使用者溝通
乘客資料有多個來源，但最基本的一個是獲取使用者與 App 的互動過程。使用者互動是通過移動端的事件日誌獲取的。下面是日誌架構設計的一些關鍵原則：
- 日誌標準化
- 跨平臺一致性（iOS、Android、Web）
- 尊重使用者隱私設定
- 優化網路使用
- 可靠但不降低使用者體驗
日誌標準化
有一個標準的日誌記錄過程很重要，因為數以百計的工程師在增加或編輯事件。從客戶端收集的日誌有的是平臺化的（像使用者與 UI 元素的互動事件、內容曝光次數等），有的是由開發人員手動新增的。
我們將一組後設資料進行了標準化，作為預設的公共負載隨每個事件傳送，如位置、App 版本、裝置、暱稱等。這對於後臺指標計算至關重要。
此外，為了確保所有事件跨所有平臺都能保持一致，並且有標準的後設資料，我們定義了 Thrift 結構，事件模型需要實現這個結構來定義其有效負載。Thrift 模式包含一個列舉（表示在不同平臺上的事件 ID）和一個有效負載結構（定義了事件註冊時與之關聯的所有資料），最後還有一個事件型別。
示例：Thrift 模式中分析事件的標準化定義
這些日誌通過管道進入 Unified Reporter，這是客戶端裡的一個框架，用於攝取客戶端產生的所有訊息。Unified Reporter 會將訊息儲存在佇列中，對它們進行聚合，然後通過網路每隔幾秒分批次地傳送給後臺的 Event Processor。
圖 1 事件被記錄到儀表盤和資料集的過程
事件一直在增加或變化——每天處理的事件有幾百種型別。其他日益嚴重的問題還有：跨不同作業系統（Android 和 iOS）的日誌平臺化、可發現性以及如何保持良好的訊雜比。Event Manager 門戶負責管理這些事件的後設資料，併為事件選擇合適的接收器。
Event Processor 根據接收到的後設資料確定如何處理事件以及進一步傳播。此外，如果事件的後設資料和對映不可用，Event Processor 就會阻擋該事件，不再向下游傳播。這是為了提升訊雜比。
伴隨使用者互動，我們要記錄 App 向使用者展示了什麼內容，這很重要。我們是通過在後臺記錄服務層的資料來實現的。後臺日誌記錄處理的資料更多，有些是移動端沒有的，有些是移動端處理不過來的。由移動端或其他系統發起的每次後端呼叫都會有資料記錄。每條記錄都有一個”join“鍵，通過它可以關聯到移動端互動。這項設計可以保證移動端頻寬得到有效使用。
我們把從移動端和服務層收集到的資料進行結構化，並作為離線資料集進行復制。離線資料集幫助我們識別上文提到的問題，並評估為解決這些問題所開發的解決方案有多成功。
原始的大型離線資料集真得很難處理。我們對原始資料進行擴充並建模，形成分層表。在擴充過程中，我們把不同的資料集連線在一起，讓資料更有意義。建模形成的表可以帶來以下幾個方面的好處：
- 節省資源：僅計算一次並儲存。其他任何人都不需要在原始的大型資料集上執行查詢。
- 標準化定義：業務邏輯和指標定義都在 ETL 中（提取、轉化、載入），不需要消費者操心。如果把這項工作留給消費者，那麼每個團隊可能會做不同的計算。
- 資料質量：可以保證適當的檢查對比，因為邏輯都在一個地方，資料很容易檢驗。
- 所有權：隨著資料演化，資料所有者可以確保表能夠適用於新特性。
圖 2 各種離線資料處理場景
讓我們考慮一下下面這個問題描述：
快捷乘車改善了乘客體驗，促成了更多轉化（出行）嗎？
我們從儲存了使用者互動和主介面內容的基礎事實表中篩選出與“快捷乘車”相關的資訊，並通過與其他多個資料集整合對它進行擴充，進而實現漏斗分析：
- 有多少使用者顯示了快捷乘車區域？
- 有多少使用者點選了其中的一個快捷方式？
- 有多少使用者（來自 #2）最終預定了出行？
- 有多少使用者（來自 #3）完成了出行？
- 通過快捷乘車流程和普通流程完成出行的主介面曝光比是多少？
- 快捷乘車對於出行預定的總體效果是什麼？
- 獎勵計劃對於乘客的作用有多大？
為了找出這個問題的答案，表中應該包含如下資料：
- 選擇 / 兌換的獎勵
- 未使用或過期的獎勵
- 乘客如何贏得獎勵？
還有其他一些有趣的資料點，如：
- 獎勵計劃增加了 App 的總體使用量嗎？
- 支出是否與這項計劃的預算相符？
獎勵可以通過 Eats、Rides 和其他 Uber 應用的不同功能進行兌換。一旦使用者在移動端選擇了一項獎勵，就會觸發中心化的獎勵後端服務。它會處理獎勵資訊，將每個獎勵選擇行為記錄為交易資料。有些獎勵是自動應用的，但有些是促銷驅動的。促銷驅動的獎勵兌換是在另一個促銷系統中處理的。此外，這個系統的構建讓運營或產品團隊能夠根據需要輕鬆新增新的獎勵。我們構建工具來獲取獎勵後設資料，這些後設資料反過來又流向另一個系統。有個 ETL 作業會讀取流經不同系統的資料，生成一個獎勵兌換資料模型。此外，這些資料還能幫助財務團隊獲取 Uber 在獎勵計劃中的開銷，讓人們對這個產品有一個良好的理解。
- 在 COVID-19 之後，Uber 航空出行的恢復率是多少？
航空出行的不同指標是從上游多個表收集的，包括出行、會議、理財、航空出行及其他乘客表等不同的領域。來自不同領域的資料會被聚合，然後在一組維度下計算成指標，儲存到一個表中。將最新資料與經過聚合的歷史資料進行比較，可以幫助我們找到上面這個問題的答案。
此外，航空出行資料還被用於繪製機場接機的落地資料熱圖，計算機場總接機量、總預定量等。所有這些資料都有助於我們業務的發展，還有助於業務本地化，滿足不同地域的不同需求。
資料可以為我們提供業務決策的依據。因此，保證資料的完整性和質量變得非常重要。在乘客端 App 的架構中，為了保證資料質量，我們在多個層面做了數項檢查。
在產生事件的時候，我們引入了測試框架進行構建時測試、模式和語義檢查。這些框架會檢查是否有分析事件被觸發，有效負載、順序是否符合預期。
圖 3 資料流資料質量檢查
一旦事件到達離線儲存並處理，異常檢測功能就可以保證資料被記錄並按照預期流轉。系統會監控事件量，如果突然出現下降或峰值，就給所有者傳送告警資訊。這種監控有助於捕捉差異，防止出現中斷而沒有發現。在離線建模的表中，測試框架被用於確保資料的正確性、覆蓋率以及各表之間的一致性。每次管道執行都會觸發配置好的測試，保證產生的任何資料都能滿足質量 SLA（服務水平協議）。
根據上面這些從資料收集機制中瞭解到的東西，我們對乘客端 App 做了一些更改，下面是幾個具體的例子：
並非所有特性在所有市場中都可用
高質量的資料是推動應用程式演進的強大工具。不說別的，它可以幫助我們改善使用者體驗，這反過來又增加了使用者粘度，促進了使用者增長。此外，在新增新特性的時候，資料可以告訴我們什麼最適合使用者，保證更改不會導致使用者體驗下降。我們深刻理解資料的重要性，我們一直在提升 Uber 的資料文化。
英文原文：https://eng.uber.com/how-data-shapes-the-uber-rider-app/