在先前教過了Firebase設定，這邊就不再贅述，直接開始啦

按照SDK文檔設定
https://firebase.google.com/docs/analytics/get-started?authuser=0&platform=android
通常會將送出Log的部分再進一步封裝成專案要使用的格式

此範例我們使用Property, Screen, Event, Custom Event這幾個較常用的功能做演示
UserId正常來說會放在登入後取得使用者ID才使用
setCurrenScreen的部分應放在Activity onResume的位置做紀錄，否則可能會有name紀錄不到的問提
logEvent運用較廣泛，主要是用於記錄事件以及約略評估事件的轉換價值

串接完成後就可以實測Firebase analytics部分是否已經連通。Firebase有提供測試工具，首先執行adb shell相關指令，詳細請參考
https://support.google.com/firebase/answer/7201382?hl=zh-TW&utm_id=ad

接著將控制台頁面切換至DebugView頁籤，進行logEvent相關操作，幾秒鐘內即可在列表中看到事件

約略在24小時左右就可以看到前一天有觸發的event在此列表中，可以看到以下列表中除了我們自行紀錄的test_custom_log、test_log事件以外還有其他的事件，這些事Firebase預設會紀錄的項目，包含screen_view也是

選擇screen_view事件，可以看到畫面右側屏幕名是我們自行設定手動觸發的事件，若我們進行手動觸發，則紀錄的內容將會是屏幕類也就是Activity名稱，例如MainActivity

於清單項目右側按鈕中可修改參數報告

選單左側已經有一些預設的參數，可以直接點選後選擇參數類型添加到右側列表中。如果有自行定義的參數，例如test_custom_log中的cust_event_type也可以手動輸入

選擇test_log事件，中間藍色背景的區塊可以看到選擇參數名稱的Filter會列出近30分鐘內的event，最右側content_type及下方的item_id則是上方選定的參數，而價值的部分則是我們在程式中有設定FirebaseAnalytics.Param.VALUE帶入的數值
但是剛開始自行測試的時候可能會發現有像本範例一樣列表中含有很高比例的(not set)的項目，基本上是因為Firebase本身有一些過濾無效事件的機制造成

這是另一個在Google Play上約有200人使用的APP，使用相同的方式紀錄event大部分是正常的，如果仍擔心設定問題導致數據不正確可以在發布Google Play版本的時候先用小量發布，避免大量的錯誤數據湧入造成策略師或行銷人員無法參考

User Properties需要先建立，然後在app執行setUserProperty，最後便能在Event中選擇Property filter數據