17 Media 資料生命週期概述

引言

過往，企業依賴顧問的經驗來提升經營績效、開拓新市場、或是解決問題。而今天，企業則是透過數據分析來完成上述的所有事情。

數據分析是指用適當的統計分析方法對收集來的數據進行分析，從中提取對人們有意義的資訊，詳加研究，最後概括總結的過程。

從字面上看，數據分析本身就是「數據」和「分析」兩塊工作。一方面是採集、加工、整理數據，另一方面是結合數據背景分析數據，從中提取出對業務有幫助的結論。

那支撐 17 Media 營運的數據分析是怎麼完成的呢？就請大家繼續往下看這篇文介紹的主角：資料團隊。

17 Media 的資料是如何收集的

首先，簡單介紹一下目前公司本身的系統架構：

為了讓讀者方便理解，本文會分成三個部分來介紹，分別是 application 本身的資料來源、後端所產生的資料來源、資料庫的資料來源。這些資料就是讓資料團隊變成數據王國。

從 app 收集使用者資訊

首先，要介紹的第一個部分就是資料來自 application 本身，有三個工具讓我們收集使用者的操作行為。透過 Firebase 追蹤手機 app UI 上的使用紀錄，這在分析使用者的行為數據是非常重要的，為了要做出能打中觀眾的直播內容與產品，故蒐集使用者在 app 的行為來使產品更完善，包含使用者在哪個畫面做了什麼點擊，瀏覽了什麼資料等。另外在開發新功能時，我們也會使用 Firebase 的 custom metrics 功能來紀錄對於該功能有意義的資料點，以作後續分析。

另一個來源，則透過 AppsFlyer 這個平台，與行銷部門做資料交換，目的是要讓行銷部門知道每個廣告渠道的數位行銷成效與指標，例如 CPI 跟 CPA，會這樣做的目的在於行銷部門需要投廣告，透過這些資料知道哪些廣告商的績效是否如他說得好。透過曝光所有廣告成效相關資料，使合作無論對外對內都公平。又因為 AppsFlyer 產生的資料量非常大，且沒有像 Firebase 一樣跟 BigQuery 有整合，故透過使用 Fluentd 這個資料蒐集工具做緩衝，不要讓資料一口氣全部進入 BigQuery 中。

圖下方有個工具叫 OneSignal ，是個推播管理工具。主要用以區分用戶，並提供簡單介面讓行銷決定發不同的訊息內容給不同類別的用戶並做訊息管理。在訊息發出後，資料團隊就可以蒐集推播資料，以及推播的時間點等。

光是從 app 端就有多種資料來源，整理方面就非常地麻煩，17 Media 使用 Google 的 BigQuery 服務，作為所有資料的集散中心。

從後端收集資料

17 的後端是透過 log 機制紀錄使用者資訊，並將這些資訊推播到 BigQuery 裡面。使用 schema-less log 是因為他對開發者很輕量化，只需要一行代碼就可傳遞所需訊息，而不需額外定義 schema。

後端發出的 log 透過兩個工具傳遞處理：Cloud Pub/Sub 跟 Cloud Dataflow。Cloud Pub/Sub 是 GCP 推出的訊息佇列工具，用來暫存傳入的大量訊息以避免下一級工具處理不及。Cloud Dataflow 是個專門用來處理資料的 worker，他讓開發者自定義資料處理邏輯以處理不同類別的資料事件。同時 Cloud Dataflow 是個全代管服務，會自動處理應該要有 worker 數量，不需維運人員擔心。

從資料庫收集資料

17 目前使用的資料庫包括 MongoDB、MySQL 以及 Redis。其中 MongoDB 負責絕大部分的商業邏輯資料，與交易有關需要確保一致性與完整性的資料存放在 MySQL，Redis 則是負責快取以及少部分需要大量讀取的即時性資料。

17 App 每天透過使用者產生的後端相關數據約是 2 億多筆，這些資料透過 embulk 框架將大量資料搬移至BigQuery。目前資料庫每小時同步一次，透過 digdag 作為排程伺服器，確保每小時的資料同步如期完成，而不讓資料的時間序列錯誤。這些資料會透過腳本同步至 BigQuery 中的 layer 1 dataset。

資料處理

如上所述，不同來源的原始資料都會匯集至 BigQuery。這是資料匯集的終點，也是分析的起點。17 Media 的資料分析以資料整理的想法出發，將原始資料一層一層匯總成具商業價值的資料報表。以下介紹各層之間的轉換，以及執行數據分析的手法。

layer 1 到 layer 2

Layer 1 是 17 的原始資料集散地，收集了不同來源的資料，每個來源的資料格式都不盡相同。這些原始資料會先進行預處理以利後續分析：以來自 Firebase 的事件為例，我們會按照 UI 或是 app 的功能把事件做分類，這些整理好的資料就會存放到 layer 2。由於 layer 1 每張資料表之間沒有交互關係，所以不同 layer 1 資料表到 layer 2 的工作可以平行進行互不干擾。

layer 2 到 layer N

不同表格之間會有不同的交互作用，例如把使用者資料與他相關的付費記錄組合起來，就可以針對用戶付費行為做後續分析。從 layer 2 到 layer N 之間，需要不同資料來源或是資訊，聚合 (aggregation) 成下一個層級需要的資料。同時也會加入非 BigQuery 來的資料，舉例來說：行銷部門針對各個廣告渠道整理出的試算表，或是節目部門所維護的直播主帳號名單。這些非系統或軟體所產生的資料，與其他數據整合之後，就可以輔助決策組織的下一步，像是前面提到的節目部配合數據，協助直播主產生更多元的直播內容吸引觀眾，如此就能比競爭對手更有效率地拿下市場。

從前面提供的架構圖中省略了好幾層 layer，原因是中間經過不少的邏輯演算、資料處理，有些資料在某層就產生了人們想要知道的結果，但有些資料則是要經過非常多層的演變才能提供可分析的樣態。

經過多道程序後完成的資料表，資料格式更適合分析，可以隨時讓分析師或內部人員取用。一般我們會把同性質的資料整合成一張表格，例如 UserBehavior 這張表格包含用戶基本資料、追蹤主播、送禮點數、直播觀看次數、App 功能使用情形。匯總的資料表利於非工程人員透過簡單的操作達到分析目的。

最後對於業務需求高度相關的資料，團隊會建立 dashboard 讓公司所有人一目了然。每張 dashboard 背後會有一個對應的資料表稱為 view，針對 dashboard 上所想要呈現的資料跟型態做最終的資料整理。

資料支撐營運

如果只是單純要產生營運資訊，為什麼要刻意用那麼多層資料處理程序呢？其實過程中資料產出物，除了內部自己的團隊要使用，也有兩個主要用途。

提供資料給公司營運

另外一種會主動提供給其他部門的，就是公司內部營運用的資料，例如點數的購買及消耗紀錄。這些交易紀錄都存在 MySQL 中，但如果直接從 MySQL 中撈取資料，處理上會非常耗時；透過 BigQuery 的服務以及整理過後的資料表，直接讓系統去撈整理好的資料並做呈現。

每日報表 v.s. 即時報表

以上數據工程所執行的流程是以產生日報表為主，在每日固定時間產生報表給營運團隊。這一類資訊不需要即時呈現，所以每日只執行一次，例如新安裝 app 以及註冊人數，營運團隊會在每日整理出前一天相關的資訊，以作為策略改進方針。

對於營收相關報表，由於對公司影響較大，營運團隊需要即時數據以作更快的應變。與金流相關的報表會透過另外一個流程產生，此流程下報表與實際數據的時間差約為五分鐘，讓營運團隊第一時間可以應變。

資料生命週期範例：功能使用率

17 產品團隊平均每週都有新功能上線。為了讓團隊更了解一個功能的使用情形，包括：營運成效如何計算、是否達成部門目標、新功能是否有表現較好等。資料團隊會針對每個功能算出使用率並且視覺化；同時也須克服各種不同的功能有不同的資料格式的問題，及要如何呈現在同一個 dashboard 來比較成效。

上圖是簡化的資料流向圖，在此我們拿兩個功能作為範例：一是遊戲功能、一是聊天功能。當用戶使用該功能時，後端會將使用資訊記載在資料庫中；這些資料會定時同步至位於 BigQuery 的 layer 1。Layer 1 的資料會包含一些無效紀錄，例如遊戲資料欄位中 player_id 或 timestamp 為空值，或是聊天功能中時長小於 1 分鐘的對話時間，這些都會在 layer 1 到 layer 2 的預處理中刪除。目前難以在這個階段判讀出一個結果，所以從 layer 2 到 layer N 的過程中，與不同的資料表交集、匯總計算出目標資料內容，找出不重複的用戶數，以及這個功能的 id，寫進 report_summary 這張資料表中。有了這些資料內容，就可以將各功能不重複的使用次數視覺化成如下的使用率比較圖，從中了解不同功能的被使用率。

日均功能使用率比較。由圖上可知第一個功能的使用率有 48.13%。這數據可讓產品經理判斷是否要花更多的心力來加強功能。

我們也可以在分析的過程中找出單一功能的使用次數是否逐日增加，例如遊戲功能的使用是否有成長的趨勢。我們一樣可按照前面的分析流程，將遊戲功能的資料格式加入時間戳記，利用不同天數作為比較基準進行交集，經過幾層的數據分析所產生的結果寫進 report_summary 中，透過每日定時的時間戳記進行比較，就可以知道此功能是否有逐漸被多數人使用，是否有達到預期的成效。