利用Google Firebase 建立數據收集與分析系統

編輯導語：Firebase是一家實時後端資料庫創業公司，它能幫助開發者很快的寫出Web端和移動端的應用，讓你的App從零到一。那麼，如何利用 Google Firebase 建立一個數據收集與分析系統呢？本文作者結合自己的實操方案，為我們做出了解答。

去年年末，我為當時負責的一款產品規劃建立了一套埋點方案。這是一款主打海外市場的內容資訊類產品，上架到 Google Play。

鑑於這是我第一次、從0到1、獨立完成一套結構化的埋點方案，並能夠通過這套埋點方案完成對整個應用的數據收集與分析，因此寫下這篇文章記錄當時的搭建思考和實踐過程。

一、為什麼選擇 Firebase

按照官方的說法，Firebase 是 Google 的移動工具平臺，適用於移動 APP 和 Web 程序。

從我個人的角度來講，Firebase 是 Google Analytics （GA）的增強升級版。過去幾年我經常使用的數據分析工具是 GA，後來 Google 停止維護 GA 的 SDK，要求開發者全部改為使用 Firebase 的 SDK。

因為 GA 有著多年的數據分析產品經驗，完全免費，並可以與 Google Ads 結合等，再加上 Google 在全球範圍內龐大的用戶基礎，GA 可以說是海外產品必備的工具。

但由於網絡限制，主打國內用戶的產品不適合使用 Google Firebase，因為會有很多數據收集不到。

現在的 Firebase 中包含的產品總共分為以下三大類：

1. Develop Products 開發類
2. Quality Products 質量保證類
3. Grow Products 運營增長類

這三大類下面總共細分了 18 個產品模塊，開發者可以通過這些產品模塊實現構建應用，提高應用質量，拓展業務等目的。

二、應該集成哪些產品模塊

Firebase 提供的產品模塊如此眾多，要實現數據收集與分析系統該選擇哪些呢？

1. Google Analytics

Google Analytics（分析）是 Firebase 的核心，你可以通過它收集用戶事件、行為等，並生成分析報告。搭建基本的數據分析系統，只需（也是必需）集成 Google Analytics。

2. Prediction + A/B Testing

你可以集成 Prediction（預測）、A/B Testing（A/B 測試） 實現一些精細化的、偏運營側的需求。

如果集成了 Prediction（預測），Firebase 會利用自己的機器學習技術幫助你細分用戶群體、預測用戶行為，你可以為不用的用戶群體配置不同的產品和運營策略。

舉例： 你可以利用 Prediction 分析用戶對於應用內購買的接受程度以及可能性，從而精細化分營銷推廣策略：為付費接受程度高的用戶推薦高級套餐，為接受程度低的用戶推薦初級套餐。再結合 A/B Testing 進行對比測試，即可知道這種運營方式是否奏效。

3. Crashlytics + Performance Monitoring

集成 Crashlytics（崩潰分析）、Performance Monitoring（性能監控） 可以幫助開發人員收集並分析程序的崩潰記錄，實時監控應用的性能表現。

三、如何收費

GA 完全免費，但 Firebase 不是完全免費的，它的價格方案分為 Spark（免費方案）和 Blaze（即用即付，按使用量付費） 兩種，詳細收費方案可在官網中的查看。

上面提到的5個產品均可在 Spark 方案中免費使用。

四、Firebase Analytics 四要素

使用 Firebase Analytics 時的四個要素分別是 Event 事件、Conversion 轉化、User Property 用戶屬性、Audience 受眾群體。

理解這四個要素後，我們便知道了在產出埋點方案時，應該從哪幾個角度出發。

1. Event 事件

用戶在應用中進行的點擊、瀏覽等操作即為「事件」，這是最基本、最重要的要素。

2. Conversion 轉化

如果某個事件對你的業務來說十分重要，例如用戶註冊、付費等關鍵業績指標（KPI），你可以將這個事件標記為「轉化」。當事件被標記為轉化後，系統即開始收集與該事件相關的用戶行為及相關數據。

3. User Property 用戶屬性

即用戶的身份特徵或所使用設備的特徵，如年齡、興趣愛好、所在地區、語言、作業系統版本等。

用戶屬性也是比較基礎的數據，在後期進行數據分析或者查找問題的過程中，用戶屬性可以作為篩選條件幫助你分析用戶。

4. Audience 受眾

此要素無需單獨添加代碼獲取，而是在控制臺中通過「Event 事件」與「User Property 用戶屬性」組合後篩選出的細分用戶群體。

在上述的四要素中，Firebase 會根據應用類型自動捕獲或預設一部分事件、轉化、用戶屬性，但更多的、更詳細的則需要開發者自行添加代碼配置。

五、其他要素

1. Parameter 參數

與 Event 事件息息相關的一個重要概念是 Parameter 參數，你可以為一個事件關聯多個參數，從而更細緻地分析某個事件。

舉例：用戶分享了應用中的內容到社交平臺，此時觸發的是「share」事件，那麼這個事件可以關聯收集「content_type」（內容類型）參數、「share_channel」（分享渠道）參數，由此可以知道用戶對於社交網絡的使用偏好等。

參數需要開發人員在程序中添加代碼配置，生效後即可在控制臺中為事件關聯參數。在 Console 控制臺關聯參數時，可以選擇要統計該參數的 Text 文本還是 Number 數量。

舉例：用戶在應用中點擊內容觸發「content_click」事件，這個事件關聯了「content_title」參數。

當你在控制臺配置「content_title」參數時，如果你選擇了 Text ，則用戶所點擊的內容標題及每個標題的點擊數會被逐一記錄；如果你選擇了 Number，則系統會記錄用戶觸發的該事件的總數。

參數並不附屬於某個事件，兩者是關聯的關係，你可以在控制臺中為某個事件關聯參數，這不會影響這個參數繼續被其他事件關聯。

但是 Firebase 對一個項目中使用的參數總數量有限制（「應用+網站」類型項目最多支持 100 個參數），並且同一個參數如果被多個事件關聯，那麼關聯的次數都會算進參數的總限制數量中。

舉例：你的項目支持 100 個參數，如果你在 10 個事件中關聯了同一個參數，則可使用的參數數量還剩 100-10 個。

所以你需要在埋點前儘量全面地梳理自己項目所需的參數，避免出現參數用盡的情況。

2. Session 對話

當應用轉到後臺運行後，Firebase 會開始計算會話超時時長。

默認的會話超時時長是 30 分鐘，這意味著如果應用在前臺運行了 5 分鐘後又在後臺運行了 30 分鐘（應用沒被系統殺掉的話），則這個用戶本次會話的時長就是 35 分鐘。

這對某些後臺運行需求不強烈的應用來說，可能會干擾他們判斷真正的用戶會話時長。因此，你可以根據自己的應用特性，設定自己應用的會話超時時長。

Session 對話時長不是必須自定義修改的，可以看產品類型和需求來決定。

3. Screen_view 屏幕瀏覽

如果你需要追蹤用戶在應用內的行為流、用戶在不同界面的停留時長、事件數量等等，你可以根據需求對 screen_class 重新命名，然後在控制臺中按照 screen_name 方式查看即可。

或者你也可以自定義進入屏幕、退出屏幕的觸發規則，然後開發人員按照規則統計屏幕瀏覽數據。

以我負責的資訊產品為例： 如果用戶點擊或者左右划動導致界面切換，此時會觸發 Screen_view 屏幕瀏覽。具體的觸發情形包含以下幾種：

1. 點擊內容條目、圖標、按鈕等導致屏幕切換
2. 點擊頂部標籤欄導航屏幕切換
3. 在界面內左右划動屏幕切換
4. 點擊內容進入二級、三級界面

切記屏幕跟蹤方案要與開發人員協商制定，因為不同應用、不同開發人員有不同的代碼架構方式，這決定了他們使用哪種方案性價比最高。

六、制定埋點方案

1. 方法論

關於如何產出埋點的方案文章和方法論有很多，近期讀到的比較好的一篇是友盟+團隊的文章。

簡單來說，你需要根據自己的身份（產品經理、運營、數據分析師、開發），結合應用類型（電商、內容、旅行等）確定自己的數據需求，然後將需求轉化成核心數據。

以我負責的資訊產品為例，我會有以下數據需求：

1. 衡量用戶對於內容品牌的偏好；
2. 衡量用戶對某功能的使用程度；
3. 評估用戶的登錄意願，以及對登錄方式的偏好；
4. 評估用戶的訂閱通常發生在哪些關鍵節點之後；
5. 有了數據需求後，開始著手將需求轉化為所需的核心數據。比如：我需要知道各個內容品牌的閱讀量、停留時長、各分享渠道等等。 這個過程十分重要，但本文不再贅述。

2. 方案呈現—Excel 表格

埋點方案最終交到開發人員手上是採用 Excel 表格的形式，我的方案包含 4 個部分，分成 4 頁 Sheets 呈現。

1）第一頁：Session 定義

在這裡定義：

• Session 會話開始的標誌
• Session 會話的標誌
• 會話的超時時長

2）第二頁：Events

在這裡列出你需要收集的所有 Event 事件，你需要告訴開發人員這些事件的名稱、事件是如何觸發的、事件包含了哪些參數、參數該如何取值。

• Event Name——事件名稱
• Trigger——觸發時機
• Parameters Name——參數名稱
• Parameter Value——參數取值
• Parameter Type——參數值類型

為了是開發人員更加清晰、快速理解這些 Event 事件，你還要告訴開發人員這個事件要滿足滿足哪些數據需求，以及其他一些輔助性的描述，例如：

3）第三頁：Screen

上面已經講過，在收集 Screen_view 屏幕瀏覽數據時，我們需要與開發人員溝通後確定方案。如果溝通後你們需要自定義屏幕跟蹤方案，則可以使用以下方式呈現：

• screen_view——觸發時機
• 模塊/場景
• Screen_Name——屏幕名稱
• 屏幕描述
• 名稱示例

同樣需要寫明一些輔助性的描述：

4）第四頁：User_Property

這裡需要定義清楚產品中會出現的幾類用戶群體：

• User Property Name——屬性名稱
• Description——屬性描述

舉例：根據用戶的 Level 將用戶劃分為不同類型，則屬性名稱可以叫做「user_level」，不同的 Level 分別使用數字標記，0 是一般用戶，1 是付費用戶等等。

快速驗證埋點結果——DebugView，由於 Firebase 採用的是定期輪詢數據的方式，通常 1 小時一次，所以在開發集成的過程中，我們如果等輪巡後將數據展示到控制臺中，然後再檢查埋點是否成功、是否準確，這個過程會非常漫長。

因此 Firebase 在控制臺中提供了「DebugView」功能，通過 DebugView，我們可以在設備上操作應用，相關事件會以 Timeline 的形式實時展示在 DebugView 報告中。

以上就是所有內容了，感謝閱讀！關注微信公眾號「一代小熊」回復「埋點模板」，免費獲取埋點實施方案模板。

 

本文由@Jalyn 原創發布於人人都是產品經理，未經允許，禁止轉載

題圖來自 Pexels，基於 CC0 協議