Google Analytics for Firebase 是 Google 開發 (收購) 的一款免費的工具，它可以協助我們做到許多事情 (全覽)，但這篇文章主要會從產品經理的角度，來分享如何正確的使用 Firebase 追蹤 App 使用者行為數據、並用這些數據做分群推播與 A/B Testing、以及後續怎麼從 BigQuery 做更多的分析等三個項目。如想你進一步了解這些項目，就很適合閱讀這篇文章。
記得筆者公司曾經同時使用 Facebook Analytics、AppsFlyer 和 Firebase，來追蹤使用者操作 App 的行為數據。在經歷這段混亂期後，我們選擇拿掉 FB Analytics，留下 AppsFlyer 來追蹤使用者下載安裝 App 的渠道，而進入 App 後的操作行則由 Firebase 接手處理。但對我而言，FB analytics 內建的數據解析介面一直是優於 Firebase，但考量我們的產品架構逐漸轉往 GCP，想到 Firebase 串連 BigQuery 後的大量應用，我們才選擇捨棄 FB Analytics。因此如果團隊暫無資源使用這些服務的話，或許可以仔細評估後再擇一使用。
Firebase從三種追蹤工具中存活下來後，我們也開始深化他的使用方式，單單就 App 使用者行為數據部份，就涵蓋了追蹤、應用(推播與A/B Testing)，與進階分析等三個項目。以下不多說，就直接進入正題：
1. 透過 Firebase 追蹤App使用者行為數據
在 Firebase 的 Analytics→Retention 與 Conversions 頁面，可以直接檢視活躍用戶數 (active users)、日/週/月留存率 (retention/ retention cohorts，見下圖)，以及特定事件的轉換率與轉換漏斗 (conversion rate and funnel)。但在直接使用這些數字做決策之前，務必要思考自身產品特性是否相符。實務上，應該也很少會直接採用 Firebase 提供的數字，而是會從新定義事件，並由資料團隊直接從 BigQuery 端取得資料然後再做分析，其原因與具體作法則如後所述。
1–1. 先有符合需求的活躍用戶定義，才有分析留存率的價值
Firebase 對活躍用戶定義是指「當日使用App超過30分鐘的使用者」，因此如果你的產品不適用於此定義的話，務必要建立新事件來作為活躍用戶的追蹤指標。舉例來說，做美食外送服務的App，可能是「當日完成一次訂餐的使用者」才可稱為活躍用戶。因此要先依據產品特性，建立活躍用戶的指標事件，並將使用者本身的帳號或裝置資訊等 unique key 作為一個事件參數回傳後，才能進行有效的留存率分析。
如何將 Firebase 資料串連至 BigQuery，可參考此連結。設定完成的一天後，就可在 BigQuery 上看到使用者操作行為數據的 table 了(約莫有30–90秒的時間差)。從 BigQuery 查看這些使用者行為數據的最大好處，在於你可以下query 撈出遠比在 Firebase 上面還多的數據，如App版本、裝置細節、地理位置與事件細節等(見下圖)，這些都是非常實用的資訊，也可以直接串接Google Studio來建立公司內部的 dashboard。
1–2. 先了解使用者操作生命週期，再檢視轉換漏斗類型
A. 操作生命週期：
Firebase 在2018年底推出一個功能叫做 session，簡單的來說就是當App被使用者開到前景>10秒後，就會生成一個 session，而這個 session 要等到使用者離開App 30分鐘後 (預設值) 才會消失。我是把他視為使用者一次操作的生命週期來理解，使用者開始使用 App 等於一個生命的出生，而不再使用的時候，就是這個生命的終結，而發生在出生到死亡中間的各種事件，就是分析轉換率的依據。
同樣的，使用 session 前同樣務必依據自身的產品特性，定義好何謂一次操作的生命週期。舉做美食外送服務的 App 來說，使用者完成訂餐後，就會進入等待送餐的過程，如果是訂一個披薩，使用者可能60分鐘後才會再次開啟App，而這時間已經超過預設的30分鐘，但這情境對訂餐服務來說，還會是一個生命週期，因為餐點送達後，要等使用者給完評價後才終結掉。那這個預設時間到底要怎麼訂呢？建議是定義一個最小的合適時間，然後透過給評價的事件帶回 extend_session 參數，來有效延伸此 session，就可完美契合產品特性了。
B. 轉換漏斗：
在直接查看 Firebase 事件轉換前，務必要理解到Firebase是所謂的開放型轉換漏斗。舉美食外送服務 App 的案例來說，使用者進入訂餐頁面按下「訂餐」前，可能會有多個頁面進入點 (推薦、最愛、搜尋頁面等)，因此你想查看「從推薦頁面進入且在訂餐頁面完成訂餐」的轉換率時，就會發現進入推薦事件的人數，遠低於在訂餐頁面完成訂餐的人數，而這轉換率當然就不可參考了。要解決這件問題也很簡單，就是透過 session 串連該次使用者的操作生命週期，找出訂餐事件前的操作紀錄，就可以找到解答了。進階的作法，還會去分析使用者在整個操作生命週期發生的事件，並找出各種增加訂餐成功率的因素。
但如果確定轉換漏斗是屬於閉鎖型，那就可以大膽使用Firebase的功能了。舉例來說 DAU/App-DAU (當日實際活躍人數, Daily Active User; 當日登入的使用者, App-DAU) 就可直接採用，因為使用者登入 App 後，不管中間去哪裡，最終都只有是否完成訂餐兩種結果。
能夠有效的追蹤留存率與轉換率後，如何使用 Firebase 做分群推播與 A/B Testing，還有如何串連 BigQuery 做進一步的分析就相對容易了，因為難度是取決於想做什麼，而非工具的使用。而這兩點我會寫到下一篇的文章中。
如果這篇文章，有幫助你產生新的想法，就給我幾個拍拍手吧：）