前  言

資料對於我們的產品而言至關重要。資料分析幫助我們為使用我們服務的使用者提供了流暢的體驗。它也讓工程師、產品經理、資料分析師、資料科學家可以在瞭解情況後作出明智的決定。資料分析影響了 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)完成了出行?
  • 通過快捷乘車流程和普通流程完成出行的主介面曝光比是多少?
  • 快捷乘車對於出行預定的總體效果是什麼?
  1. 獎勵計劃對於乘客的作用有多大?

為了找出這個問題的答案,表中應該包含如下資料:

  • 選擇 / 兌換的獎勵
  • 未使用或過期的獎勵
  • 乘客如何贏得獎勵?

還有其他一些有趣的資料點,如:

  • 獎勵計劃增加了 App 的總體使用量嗎?
  • 支出是否與這項計劃的預算相符?

獎勵可以通過 Eats、Rides 和其他 Uber 應用的不同功能進行兌換。一旦使用者在移動端選擇了一項獎勵,就會觸發中心化的獎勵後端服務。它會處理獎勵資訊,將每個獎勵選擇行為記錄為交易資料。有些獎勵是自動應用的,但有些是促銷驅動的。促銷驅動的獎勵兌換是在另一個促銷系統中處理的。此外,這個系統的構建讓運營或產品團隊能夠根據需要輕鬆新增新的獎勵。我們構建工具來獲取獎勵後設資料,這些後設資料反過來又流向另一個系統。有個 ETL 作業會讀取流經不同系統的資料,生成一個獎勵兌換資料模型。此外,這些資料還能幫助財務團隊獲取 Uber 在獎勵計劃中的開銷,讓人們對這個產品有一個良好的理解。

  1. 在 COVID-19 之後,Uber 航空出行的恢復率是多少?

航空出行的不同指標是從上游多個表收集的,包括出行、會議、理財、航空出行及其他乘客表等不同的領域。來自不同領域的資料會被聚合,然後在一組維度下計算成指標,儲存到一個表中。將最新資料與經過聚合的歷史資料進行比較,可以幫助我們找到上面這個問題的答案。

此外,航空出行資料還被用於繪製機場接機的落地資料熱圖,計算機場總接機量、總預定量等。所有這些資料都有助於我們業務的發展,還有助於業務本地化,滿足不同地域的不同需求。

資料質量

資料可以為我們提供業務決策的依據。因此,保證資料的完整性和質量變得非常重要。在乘客端 App 的架構中,為了保證資料質量,我們在多個層面做了數項檢查。

在產生事件的時候,我們引入了測試框架進行構建時測試、模式和語義檢查。這些框架會檢查是否有分析事件被觸發,有效負載、順序是否符合預期。

圖 3 資料流資料質量檢查

一旦事件到達離線儲存並處理,異常檢測功能就可以保證資料被記錄並按照預期流轉。系統會監控事件量,如果突然出現下降或峰值,就給所有者傳送告警資訊。這種監控有助於捕捉差異,防止出現中斷而沒有發現。在離線建模的表中,測試框架被用於確保資料的正確性、覆蓋率以及各表之間的一致性。每次管道執行都會觸發配置好的測試,保證產生的任何資料都能滿足質量 SLA(服務水平協議)。

Uber 乘客端 App 的演進

根據上面這些從資料收集機制中瞭解到的東西,我們對乘客端 App 做了一些更改,下面是幾個具體的例子:

並非所有特性在所有市場中都可用

高質量的資料是推動應用程式演進的強大工具。不說別的,它可以幫助我們改善使用者體驗,這反過來又增加了使用者粘度,促進了使用者增長。此外,在新增新特性的時候,資料可以告訴我們什麼最適合使用者,保證更改不會導致使用者體驗下降。我們深刻理解資料的重要性,我們一直在提升 Uber 的資料文化。

英文原文:https://eng.uber.com/how-data-shapes-the-uber-rider-app/

作者 | Uber 工程部落格
譯者 | 平川
策劃 | 鈺瑩