Firebase Analyticsは、Googleが無料で提供するアプリ向けの計測SDKです。現在の正式名は「Google Analytics for Firebase」で、集めたデータはFirebaseプロジェクトにリンクしたGA4(Google Analytics 4)のプロパティに入ります。Firebaseコンソールで見るレポートとGA4の管理画面で見るアプリのレポートは、公式ドキュメントが「identical(同一)」と書く同じものです。
この記事では、GA4との関係を最初に整理したうえで、自動で集まるイベントと上限値、Android・iOS・Webの導入コード、DebugViewでの確認方法、同意取得の設定、BigQueryへのエクスポートまでを2026年9月時点の公式ドキュメントに沿って説明します。
まとめ:Firebase Analyticsの要点(2026年9月時点)
- Firebase Analyticsの料金は、SparkプランでもBlazeプランでも無料です。アプリの異なるイベント名はアプリユーザーあたり500種類までで、自動収集イベントはこの枠に含みません。
- GA4と別のツールではありません。1つのFirebaseプロジェクトは1つのGA4プロパティにだけリンクでき、アプリのデータはそのプロパティのアプリ用データストリームに入ります。
- イベント名は40文字、1イベントのパラメータは25個、ユーザープロパティは25個が上限です。自動収集イベントは500種類の枠に数えません。
- SDKの最新版は、Android BoMが34.19.0(firebase-analytics 23.2.0)、iOSが12.19.2、Web(npmのfirebase)が12.19.0です。
- イベントは通常およそ1時間ごとにまとめて送られます。実装の確認はDebugViewで行い、開発端末のデータはデータフィルタで除外します。
- EEA(欧州経済領域)のユーザーがいるアプリは、同意モードv2の4項目(analytics_storage・ad_storage・ad_user_data・ad_personalization)を設定します。
- 生データはBigQueryへエクスポートできます。標準のGA4プロパティは日次バッチが1日100万イベントまでで、ストリーミングには件数の上限がありません。
- Firebase Predictionsは2022年2月に非推奨となり、現在は提供が終わっています。
導入前に、GA4との関係とイベントの上限を確認してください。
Firebase Analyticsでできることと料金
Firebase AnalyticsのSDKをアプリに入れると、初回起動・セッション開始・画面遷移・操作時間などのイベントが自動で記録されます。自社の業務に合わせて「商品をカートに入れた」「チュートリアルを完了した」といったカスタムイベントを追加でき、ユーザーの属性はユーザープロパティとして付けられます。
集めたデータから作れるのは次のものです。
- アクティブユーザー数・維持率・イベント数などのレポート(Firebaseコンソールと、リンク先のGA4プロパティ)
- 端末情報・カスタムイベント・ユーザープロパティを条件にしたオーディエンス
- Remote Config・A/B Testing・Cloud Messagingの配信対象や、A/B Testingの目標指標
- Crashlyticsのクラッシュ前の操作ログ(ブレッドクラム)
- BigQueryへのイベント単位の生データのエクスポート
料金はFirebaseの料金表でAnalyticsが「No-cost」とされ、無料プランのSparkでも従量課金のBlazeでも変わりません。BigQueryでは保存料とクエリ料に加え、ストリーミングエクスポートを使う場合はデータ取り込みの料金も発生します。Firebase全体の無料枠と超過単価はFirebaseの料金の無料枠とBlaze超過単価にまとめています。
Google Analytics(GA4)との違い:別ツールではなく同じプロパティ
「Firebase AnalyticsとGoogle Analyticsの違い」は、旧Googleアナリティクス(ユニバーサル アナリティクス、UA)の時代には意味のある問いでした。UAにもAndroid・iOS向けのSDK(Google Analytics Services SDK)によるアプリ計測はありましたが、2019年10月に終了が始まり、アプリはFirebase SDKで測るよう案内されていました。GA4ではWebとアプリが1つのプロパティにまとまり、UAの標準プロパティは2023年7月1日にデータの処理を止めています。
現在の関係は次の表のとおりです。
| 観点 | Firebaseコンソール | GA4の管理画面 |
|---|---|---|
| データの保存先 | 同じGA4プロパティ(1プロジェクト=1プロパティ) | |
| アプリのレポート | 同一(公式が identical と明記) | |
| 主な画面 | ダッシュボード・イベント・オーディエンス・DebugView | レポート全般・探索・広告 |
| Webの計測 | Firebase JS SDK(getAnalytics) | gtag.js・Googleタグマネージャー |
| 他機能との連携 | Remote Config・A/B Testing・FCM | Google 広告・BigQueryリンク |
Firebaseコンソールのレポート画面には「View more in Google Analytics」があり、そこからGA4側の同じデータに移れます。探索レポートで細かく分析したいときや、Webサイトとアプリをまたいで見たいときはGA4の画面を使います。GA4そのものの仕組みはGA4の仕組みとUAとの違いで扱っています。
「分析対象」「レポート項目」で比べる解説が古い理由
日本語の解説記事には、両者を「分析対象(アプリかWebか)」「レポート項目」「計測方法」「画面の設計」の4点で比べるものが今も多く見られます。これはUAとFirebase Analyticsが別の製品だったころの整理です。GA4ではイベントとパラメータという同じデータモデルでWebもアプリも記録するので、別々の分析基盤として比べる意味はなくなりました。区別が必要なのは、SDKかタグかという実装方法と、FirebaseコンソールとGA4の画面で使える分析機能の違いです。
残っている差は、データストリームの種類による上限値の違いです。たとえば異なるイベント名の数は、アプリのデータストリームではアプリユーザーあたり500種類までですが、Webのデータストリームには上限がありません。比べるなら「Firebaseかどうか」ではなく「アプリのストリームかWebのストリームか」で見ます。
Webサイトで使う場合の選び方
Firebase Analyticsは、Webでも使えます。Firebase JS SDKのgetAnalytics()は内部でgtag.jsを読み込み、GA4のWebデータストリームへ送ります(npmのfirebase 12.19.0のソースで確認)。JS SDK v7.20.0以降は初期化時に測定IDを動的に取得するので、設定オブジェクトのmeasurementIdは省略しても動きます(取得に失敗したときの予備として使われます)。
AuthenticationやFirestoreなど他のFirebase機能をすでに使っているWebアプリなら、JS SDKのほうが初期化を1か所にまとめられます。一方、マーケティング担当がタグを管理しているコーポレートサイトや、広告タグと一緒に運用するサイトなら、GoogleタグマネージャーでGA4を入れるほうが自然です。同じイベントを同じ測定IDへ両方から送ると二重計測になります。送信処理は一方に集約し、併用する場合は既存タグとの設定を調整します。
自動収集イベントとカスタムイベントの設計
SDKを入れただけで記録される主な自動収集イベントは次のとおりです。
| イベント | 記録されるタイミング | 対象 |
|---|---|---|
| first_open | インストール後の初回起動 | アプリ |
| session_start | アプリの利用・サイトの閲覧開始 | アプリ・Web |
| user_engagement | 前面表示が1秒以上続いたとき | アプリ・Web |
| screen_view | 画面が切り替わったとき | アプリ |
| app_update | 更新後に起動したとき | アプリ |
| os_update | OSが更新されたとき | アプリ |
| app_remove | アンインストールされたとき | Androidのみ |
| app_exception | クラッシュ・例外(Crashlytics連携時) | アプリ |
first_openはダウンロードではなく初回起動で記録されるため、ストアのダウンロード数とは一致しません。app_removeもGoogle Play Consoleのアンインストール数とは数え方が違い、Play以外から入れたアプリの削除も含みます。数字が合わないときは、まず定義の違いを疑ってください。
カスタムイベントは、GA4が用意する推奨イベント(select_item・purchase・tutorial_completeなど)で表せるものは推奨イベント名を使い、足りない分だけ独自の名前を付けます。推奨イベントの名前とパラメータを使うと、GA4の標準レポートでそのまま集計されます。
イベント・パラメータ・ユーザープロパティの上限値
標準のGA4プロパティ(無料版)で、アプリのデータストリームに適用される主な上限は次のとおりです。上限を超えたイベントやパラメータは記録されません(出典:Google アナリティクス ヘルプ「イベント収集の上限」)。
| 項目 | 上限 |
|---|---|
| 異なるイベント名の数 | アプリユーザーあたり500種類 |
| イベント名の長さ | 40文字 |
| 1イベントのパラメータ数 | 25個 |
| パラメータ名の長さ | 40文字 |
| パラメータ値の長さ | 100文字 |
| ユーザープロパティの数 | プロパティあたり25個 |
| ユーザープロパティ名・値の長さ | 24文字・36文字 |
| 1ユーザー1日あたりのイベント数 | 100,000件 |
設計で効いてくるのは3点です。1つ目は、ユーザープロパティの名前が24文字、値が36文字とイベントより短いこと。上限を超える値を指定すると、そのユーザープロパティの更新は無視され、エラーが記録されます。2つ目は、キーイベントとして使う場合もイベント名を40文字以内に収めること。3つ目は、画面名や商品IDのような値をイベント名に埋め込むと500種類をすぐ使い切ることです。値はパラメータに入れ、イベント名は操作の種類だけにします。
Firebase Analyticsの導入手順(Android・iOS・Web)
どのプラットフォームでも、流れは次の順です。
- Firebaseコンソールでプロジェクトを作り、Google Analyticsを有効にする(既存プロジェクトは[プロジェクトの設定]の[統合]からリンク)
- アプリを登録し、設定ファイル(Androidは
google-services.json、iOSはGoogleService-Info.plist)を取得する - SDKを追加して初期化する
- 必要なカスタムイベントを
logEventで送る - DebugViewで届いていることを確かめる
SDKの版はFirebaseのリリースノートで更新されるので、導入時に最新版を確認してください。プロジェクト作成から初回デプロイまでの共通手順はFirebaseの導入手順で詳しく説明しています。ここではAnalytics固有のコードだけを載せます。
AndroidのSDK追加とイベント送信(BoM 34.19.0)
アプリモジュールのbuild.gradle.ktsにBoMとAnalyticsを追加します。BoMを使うと個別ライブラリの版を書かずに済みます。
dependencies {
implementation(platform("com.google.firebase:firebase-bom:34.19.0"))
implementation("com.google.firebase:firebase-analytics")
}
KotlinではFirebase.analyticsでインスタンスを取り、logEventのブロック内でパラメータを渡します。select_itemのような推奨のeコマースイベントでは、商品の情報をイベント直下ではなくitems配列に入れます。直下に置いた商品IDは商品単位の集計に使われません。
import android.os.Bundle
import com.google.firebase.Firebase
import com.google.firebase.analytics.FirebaseAnalytics
import com.google.firebase.analytics.analytics
import com.google.firebase.analytics.logEvent
val firebaseAnalytics = Firebase.analytics
val item = Bundle().apply {
putString(FirebaseAnalytics.Param.ITEM_ID, "sku_1234")
putString(FirebaseAnalytics.Param.ITEM_NAME, "トートバッグ")
}
firebaseAnalytics.logEvent(FirebaseAnalytics.Event.SELECT_ITEM) {
param(FirebaseAnalytics.Param.ITEM_LIST_ID, "top_page")
param(FirebaseAnalytics.Param.ITEMS, arrayOf(item))
}
BoM 34.0.0ではKTXモジュール(firebase-analytics-ktx)がBoMの管理対象から外れ、新版の提供も終了しています。古い記事のとおり-ktx付きの依存をBoM 34.0.0以降でバージョン指定なしに追加すると解決できないため、上のようにメインのモジュールを指定します。
iOSのSDK追加とイベント送信(SDK 12.19.2)
Swift Package Managerでhttps://github.com/firebase/firebase-ios-sdkを追加し、FirebaseAnalyticsを選びます。起動時にFirebaseApp.configure()を呼んだあと、イベントを送ります。
import FirebaseCore
import FirebaseAnalytics
FirebaseApp.configure()
let item: [String: Any] = [
AnalyticsParameterItemID: "sku_1234",
AnalyticsParameterItemName: "トートバッグ"
]
Analytics.logEvent(AnalyticsEventSelectItem, parameters: [
AnalyticsParameterItemListID: "top_page",
AnalyticsParameterItems: [item]
])
IDFA(広告識別子)を一切集めたくない場合は、FirebaseAnalyticsの代わりにFirebaseAnalyticsCoreを選び、AdSupportフレームワークを含めないようにします。ただし、IDFAを収集しない構成でも、他社のアプリやサイトをまたぐトラッキングを行う場合はApp Tracking Transparencyの許可が必要です。
Webの対応環境確認とイベント送信(firebase 12.19.0)
Webの例は、firebaseパッケージを導入し、Firebaseコンソールから取得した設定をfirebaseConfigに定義したブラウザ側のESモジュールで使います。ブラウザ拡張内やCookieが無効な環境などでは、Analyticsを利用できません。isSupported()で確かめてから初期化すると、SSRやWebViewでのエラーを避けられます。
import { initializeApp } from "firebase/app";
import { getAnalytics, isSupported, logEvent } from "firebase/analytics";
const app = initializeApp(firebaseConfig);
if (await isSupported()) {
const analytics = getAnalytics(app);
logEvent(analytics, "select_item", {
item_list_id: "top_page",
items: [{ item_id: "sku_1234", item_name: "トートバッグ" }]
});
}
isSupported()は、ブラウザ拡張の環境でないこと、Cookieが有効なこと、IndexedDBが使えることなど4つの条件を調べて真偽値を返します。
DebugViewで計測を確認する手順
アプリのイベントは、電池と通信量を節約するため通常およそ1時間ごとにまとめて送信されます(Firebase公式ドキュメント「DebugView」)。実装直後にレポートを開いても何も出ないのはこのためです。確認にはデバッグモードを有効にして、FirebaseコンソールのDebugViewを使います。
- Android:
adb shell setprop debug.firebase.analytics.app パッケージ名を実行します。解除はadb shell setprop debug.firebase.analytics.app .none.です。 - iOS:Xcodeのスキームの「Arguments Passed On Launch」に
-FIRDebugEnabledを追加します。解除は-FIRDebugDisabledを指定します。 - Web:Chrome拡張の「Google Analytics Debugger」を有効にしてページを再読み込みします。
DebugViewでは直近60秒のイベントと直近30分の件数が端末ごとに並び、イベントを選ぶとパラメータを確認できます。Androidで端末側のログも見たいときは、adb shell setprop log.tag.FA VERBOSEとadb shell setprop log.tag.FA-SVC VERBOSEを設定してからadb logcat -v time -s FA FA-SVCで出力を追います。上限超過で捨てられたイベントは、ここに理由が出ます。
見落としやすいのは、デバッグモードで送ったイベントも既定では日次のBigQueryエクスポートに含まれることです。テストのデータを本番の数字に混ぜないよう、GA4のプロパティで開発者トラフィックのデータフィルタを設定しておきます。
同意取得とデータ収集の停止(GDPR・同意モード)
利用者の同意を取るまで計測を止める、あるいは特定の版で計測をやめる場合の設定は、プラットフォームごとに用意されています。GDPRの対象になる欧州の利用者がいるアプリや、社内規程で同意前の送信を禁じているアプリで必要になります。
初期状態で収集を止める設定
AndroidはAndroidManifest.xmlのapplication要素に次のメタデータを置きます。名前はfirebase_analytics_collection_enabledで、analytics_collection_enabledではありません。
<meta-data
android:name="firebase_analytics_collection_enabled"
android:value="false" />
iOSはInfo.plistのFIREBASE_ANALYTICS_COLLECTION_ENABLEDをNOにします。同意が得られたら、どちらもsetAnalyticsCollectionEnabled(true)で再開します。この値はアプリを再起動しても保持され、設定ファイルの値より優先されます。特定の版で恒久的に止めるなら、iOSはFIREBASE_ANALYTICS_COLLECTION_DEACTIVATEDをYESにします。
同意モードv2の4項目
広告に使うデータの扱いまで利用者の選択に合わせるには、同意モードを使います。同意モードv2では、従来のanalytics_storageとad_storageにad_user_dataとad_personalizationが加わり、EEAの利用者に向けた同意ポリシーへの対応にこの2項目が必要になりました。初期値はAndroidならマニフェストのgoogle_analytics_default_allow_analytics_storageなどで決め、利用者の選択後にsetConsentで更新します。
import com.google.firebase.analytics.FirebaseAnalytics.ConsentStatus
import com.google.firebase.analytics.FirebaseAnalytics.ConsentType
firebaseAnalytics.setConsent(
mapOf(
ConsentType.ANALYTICS_STORAGE to ConsentStatus.GRANTED,
ConsentType.AD_STORAGE to ConsentStatus.DENIED,
ConsentType.AD_USER_DATA to ConsentStatus.DENIED,
ConsentType.AD_PERSONALIZATION to ConsentStatus.DENIED
)
)
Web版のsetConsentは、この4項目に加えてfunctionality_storage・personalization_storage・security_storageも受け付けます。
なお、アプリのネットワークログやプライバシーレポートにapp-measurement.comという通信先が出ることがあります。これはGoogleのGA4データフロー図でFirebase SDKのアプリ計測データの収集先として示されているドメインで、不審な通信ではありません。広告ブロッカーやDNSフィルタでこのドメインを止めている端末からは、イベントが届かなくなります。
BigQueryエクスポートとデータ保持期間
GA4の管理画面で遡れる期間には制限があります。標準のGA4プロパティでは、ユーザー単位のデータとイベントデータの保持期間を「2か月」か「14か月」から選びます。この設定が効くのは探索レポートのような非集計のレポートで、保持期間より長い期間を指定しても、超えた分のデータは表示されません。
14か月より前のデータを分析したい、あるいは自社のデータと結合したいなら、BigQueryへのエクスポートを使います。FirebaseプロジェクトがSparkプランでもBigQueryのサンドボックスで試せますが、サンドボックスではテーブルの既定の有効期限が60日に設定されるので、長期の保存には向きません(BigQuery無料枠の内訳とサンドボックスの60日制限)。Blazeプランに切り替えるとBigQueryの機能をすべて使えます。
標準のGA4プロパティの日次バッチエクスポートは、1日100万イベントが上限です。上限を超え続けると日次エクスポートが一時停止されるので、その規模のアプリはデータフィルタでエクスポートするイベントを絞るか、件数上限のないストリーミングエクスポートを検討します。ただしストリーミングは1GBあたり0.05ドルの追加料金がかかり、欠損がありうるベストエフォート方式で、新規ユーザーの流入元(traffic_source)も含まれません。日次データの完全な代わりにはならない点を前提に選んでください。
エクスポートされたテーブルは、1行が1イベントで、パラメータは配列の中に入っています。次のクエリは、プロパティの日付で選んだ日次テーブルを日本時間の日付で集計します。日本時間の月間集計として使う場合は、プロパティのタイムゾーンもAsia/Tokyoに設定されていることを確認してください。
SELECT
DATE(TIMESTAMP_MICROS(event_timestamp), "Asia/Tokyo") AS day_jst,
event_name,
COUNT(*) AS events,
COUNT(DISTINCT user_pseudo_id) AS users
FROM `your-project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN "20260901" AND "20260930"
GROUP BY day_jst, event_name
ORDER BY day_jst, events DESC;
event_timestampはUTCのマイクロ秒、event_dateはプロパティのタイムゾーンでの日付です。タイムゾーンを指定せずにTIMESTAMP_MICROSを日付に変えると、日本時間の0時から9時のイベントが前日に入ります。パラメータを取り出すUNNESTの書き方はBigQuery UNNESTの書き方とGA4スキーマを参照してください。
他のFirebase機能との連携とFirebase Predictionsの終了
Firebase Analyticsのデータは、次の機能の前提として使われます。
- Crashlytics:Analyticsを有効にすると、クラッシュや非致命的エラーの前に利用者が何をしていたかのブレッドクラムが自動で付きます(Firebase Crashlyticsの収集の仕組み)。
- Remote Config:ユーザープロパティやオーディエンスを条件にして、設定値を出し分けられます(Firebase Remote Configの条件配信と段階ロールアウト)。
- A/B Testing:実験の目標指標に、購入・維持率・クラッシュフリーユーザーなどの組み込み指標のほか、Analyticsのキーイベントや任意のイベントを選べます。目標のほかに5つまで指標を追えます。
- Cloud Messaging:通知の受信・開封などのイベントが自動で記録され、オーディエンス単位で配信できます(FCMの仕組みと送信方法)。
旧版の解説でよく紹介されていたFirebase Predictions(離脱や課金の予測)は、GoogleがFirebaseの公式サイトで公開しているSOC 3報告書(2022年6月版)に「2022年2月21日に非推奨」と記載があり、現在は提供が終わっています。Firebaseのステータスダッシュボードは代わりにRemote Configのパーソナライズを使うよう案内しています。予測を前提にした設計は、Remote ConfigのパーソナライズかGA4の予測オーディエンスで組み直してください。
Firebase Analyticsを主軸にしないほうがよいケース
アプリの利用状況を無料で広く測る用途なら、Firebase Analyticsで足ります。ただし次の条件に当てはまる場合は、これだけに頼る設計を避けてください。
- 標準プロパティの探索で、14か月を超える期間のイベントデータを使ってコホートや継続率を分析したい場合。保持期間は最長14か月なので、BigQueryへのエクスポートを最初から用意する必要があります。
- 計測データをGoogleのサーバーへ送ること自体が社内規程や契約で認められない場合。同意モードは送る範囲を調整する仕組みで、送信先を自社サーバーに変えるものではありません。
- プロダクト担当者が画面上でファネルやリテンションを頻繁に切り直したい場合。GA4の探索でもできますが、プロダクト分析専用のツールのほうが操作の自由度が高いことがあります。
プロダクト分析ツールとの比較はGA4・Amplitude・Mixpanelの上限と選び方で詳しく扱っています。
よくある質問
Firebase Analyticsでは何ができますか?
アプリの初回起動・セッション・画面遷移などを自動で記録し、カスタムイベントとユーザープロパティを追加して、アクティブユーザー数や維持率のレポート、オーディエンスの作成ができます。データはRemote Config・A/B Testing・Cloud Messaging・Crashlyticsでも使われ、BigQueryへ生データを出力できます。料金はかかりません。
Firebase AnalyticsとGoogle Analyticsの違いは何ですか?
現在は別のツールではありません。Firebase Analyticsは、GA4のプロパティにアプリのデータを送るためのSDKと、Firebaseコンソール上の表示画面です。Firebaseコンソールのアプリのレポートは、GA4の管理画面のアプリのレポートと同じものです。アプリとWebではSDK・タグによる実装方法や一部の上限値が異なり、FirebaseコンソールとGA4の画面では利用できる分析機能も異なります。
Firebase Analyticsの使い方は?
Firebaseプロジェクトを作るときにGoogle Analyticsを有効にし、アプリを登録して設定ファイルを入れ、SDKを追加します。自動収集イベントはそれだけで記録され、必要な操作はlogEventで送ります。実装の確認は、デバッグモードを有効にしてFirebaseコンソールのDebugViewで行います。
Firebase AnalyticsはWebサイトでも使えますか?
使えます。Firebase JS SDKのgetAnalytics()はgtag.jsを読み込んでGA4のWebデータストリームへ送ります。他のFirebase機能を使うWebアプリならJS SDK、マーケティング用のサイトならGoogleタグマネージャーが向いています。両方から同じ測定IDへ同じイベントを送ると二重計測になるため、送信処理の重複を避けます。
Firebase Predictionsはまだ使えますか?
使えません。2022年2月に非推奨となり、現在は提供が終わっています。Firebaseのステータスダッシュボードは、代わりにRemote Configのパーソナライズを使うよう案内しています。