LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

GA4・Firebase Analyticsによるアプリ解析基盤とは

アプリの解析基盤とは、Google Analytics 4（GA4）とFirebase Analyticsを組み合わせ、アプリ内でユーザーがどの画面を開き、どの機能を使い、どこで離脱したかをイベント単位で記録・分析する仕組みを指します。Firebase Analyticsが収集したデータはGA4のプロパティに集約され、探索レポートやBigQueryエクスポートを通じて分析できる構成が標準です^*1。

ここで扱う解析基盤は「アプリ内でユーザーがどう行動したか」を分析するための仕組みです。広告経由のインストールを追跡するアトリビューション計測（MMP=モバイル計測プラットフォーム。AppsFlyer・Adjustなどが代表）とは目的が異なります。広告効果を測るアトリビューション計測についてはすでに別稿で扱っており、本稿はインストール後の画面遷移・機能利用・継続率といったアプリ内行動の分析に絞って解説します。

Firebase Analyticsが収集する情報は、画面表示・タップ・購入といった「イベント」と、年代や言語設定などの「ユーザープロパティ」の2種類が基本単位です。この2つの設計品質が、後段のファネル分析やリテンション分析の精度をそのまま左右します。

アプリの継続率や離脱要因は、画面上の見た目だけでは判断できません。どの画面で離脱が集中しているか、どの機能を使ったユーザーが定着しやすいかをデータで裏付けるには、行動ログを体系的に収集する仕組みが欠かせません。

イベント設計 — 自動収集・推奨・カスタムの使い分け

Firebase Analyticsのイベントは3種類に分かれます。まず自動収集イベントで、アプリ起動や初回起動など、コードを追加しなくても自動的に記録される項目です^*2。追加の実装なしで基礎的な利用状況を把握できる点が特徴です。

推奨イベントは業種別の標準語彙

推奨イベントは、小売・EC、旅行、ゲームなど業種別に定義された標準的なイベント名とパラメータのセットです^*2。名称とパラメータの型を公式仕様に合わせておくと、GA4側の自動レポートやベンチマーク機能と噛み合いやすくなります。推奨イベントと異なる名前を付けてしまうと、標準機能が正しく機能しない場合があるため、該当する業種のイベントがあれば優先して採用するのが基本方針です。

カスタムイベントは自社固有の行動を補う

推奨イベントでカバーできない自社固有の行動は、カスタムイベントとして自由に定義できます^*2。1アプリで記録できるイベントの種類は500種類までという上限があり^*2、イベントの発生回数そのものには上限がありません^*2。イベント名は大文字・小文字を区別する仕様のため、命名規則を事前にチーム内で統一しておかないと、表記ゆれによって同じ行動が別イベントとして集計される事態が起こり得ます。

イベント設計で失敗すると、後から取り直しができない点に注意が必要です。実装後にログを取り始めた時点より前のデータは存在しないため、「このイベントを取得しておけばよかった」と気づいたときにはすでに機会損失が発生しています。企画段階で「何を意思決定するためにこの数値が必要か」を先に定義し、そこから逆算してイベント一覧を設計する順序が有効です。

ユーザープロパティ設計とセグメント分析の勘所

ユーザープロパティは、年代・会員ランク・利用プランといった、ユーザー単位で持続する属性情報を指します。イベントが「いつ何をしたか」を記録するのに対し、ユーザープロパティは「どのようなユーザーか」を記録する役割分担です。

プロジェクトあたり25個という上限

Firebase Analyticsでは、1プロジェクトにつき設定できるユーザープロパティの上限が25個です^*3。Age・Gender・Interestの3つは予約済みの名称のため自社定義には使えません^*3。上限が限られているため、「将来使うかもしれない」属性を先回りしてすべて登録するのではなく、実際にセグメント分析で使う予定がある属性に絞り込む取捨選択が必要になります。

セグメント分析はユーザープロパティの設計で決まる

GA4の探索レポートでは、ユーザープロパティを軸にしたセグメント（会員ランク別・利用歴別など）を作成し、行動の違いを比較できます。この比較軸として使えるのが、事前に設定したユーザープロパティです。設計段階でどのセグメント別に成果を見たいかを具体化しておかないと、後になって「知りたい切り口のデータが取れていない」という状態に陥りやすくなります。

プロパティ名も大文字・小文字を区別する仕様のため、イベント名と同様に命名規則をドキュメント化しておくことが望ましいでしょう。設定は各プラットフォームのSDKが提供する専用メソッドで行い、Firebaseコンソールのカスタム定義ページで登録する2段階の作業になります^*3。

ファネル分析とリテンション分析で行動を可視化

イベントとユーザープロパティを設計・実装した後は、GA4の探索レポートでファネル分析とリテンション分析を行い、行動データを意思決定に使える形へ変換します。

ファネル探索はクローズド型とオープン型を使い分ける

GA4のファネル探索は、ユーザーが目的の行動に至るまでの複数ステップを可視化し、各ステップでの離脱状況を確認する機能です^*4。既定のクローズドファネルでは、ユーザーは最初のステップからしか入場できず、途中のステップを飛ばして入ると、それ以降の集計対象から外れる仕様です^*4。一方オープンファネルでは、どのステップからでも入場できる設定に切り替えられます^*4。会員登録から購入までのような決まった導線を検証する場合はクローズド型、複数の入口があるコンテンツ回遊を分析する場合はオープン型が適しています。

リテンション概要レポートは初回42日間のコホートを追う

GA4のリテンション概要レポートは、ユーザーを獲得された日ごとのコホート（集団）に分け、獲得後42日間にわたって何パーセントが再訪問したかを可視化する仕組みです^*5。新規ユーザー数・復帰ユーザー数・コホート別の維持率が標準の指標として表示されます^*5。特定の機能を使ったユーザーとそうでないユーザーでリテンション率を比較すれば、どの機能が継続利用に貢献しているかを定量的に検証できます。

ファネル分析とリテンション分析は役割が異なります。ファネル分析は「1回の目的達成までの離脱箇所」を特定するのに対し、リテンション分析は「獲得後どれだけ使われ続けるか」という中長期の定着を扱う点で観点が分かれます。両方を組み合わせることで、短期の導線改善と中長期の継続率改善の両輪で施策を検討できます。

探索レポートだけでは足りない分析はBigQueryへ

探索レポートの標準機能で対応しきれない詳細な分析（イベントパラメータ単位の集計、他システムのデータとの結合など）は、Firebaseの管理画面からBigQueryへのリンクを設定し、日次で自動同期されるイベントログを直接クエリする方法が使われます^*6。無償版のGoogleアナリティクスでは、BigQueryへのエクスポート対象イベントが1日あたり100万件までに制限されているため^*6、イベント量が多いアプリではフィルタリングでエクスポート対象を絞り込む設計が必要になる場合があります。

プライバシー同意とデータガバナンスの設計

アプリ内行動データを収集する以上、ユーザーの同意状況に応じて計測範囲を制御する設計は避けて通れません。特にEU圏のユーザーを含むアプリでは、同意管理の実装が計測基盤設計の前提条件になります。

Consent Mode（同意モード）は4つのパラメータで制御する

Googleが提供するアプリ向けConsent Mode（同意モード。ユーザーの同意状況に応じてSDKの動作を調整する仕組み）は、ad_storage・analytics_storage・ad_user_data・ad_personalizationという4つのパラメータで構成されます^*7。アプリの初期設定でデフォルトの同意状態を定義し、ユーザーが同意バナーで選択した内容に応じて、setConsentメソッドで動的に値を更新する実装が基本です^*7。設定した値はデフォルト値より優先される仕様のため、同意取得のタイミングと計測開始のタイミングの整合を取る必要があります^*7。

同意管理は計測要件と法務要件の両輪で設計する

同意モードの実装は技術的な作業に見えますが、実際にはどのデータをどの同意状態で収集してよいかという法務・プライバシーポリシー側の判断が前提になります。技術担当だけで進めると、後から法務確認で計測設計の手戻りが発生しかねません。企画段階でプライバシーポリシーの記載内容と、収集するイベント・ユーザープロパティの対応関係を整理しておくことが望ましいでしょう。

同意状態によって収集されるデータ量が変わるため、分析結果を解釈する際は「同意率が変われば集計対象の母数も変わる」という前提を分析担当者間で共有しておく必要があります。同意率の変動を無視して期間比較をすると、実態とは異なる増減として誤読するおそれがあります。

外注時に確認すべき計測実装と引き継ぎの論点

アプリの解析基盤導入をアプリ開発会社に外注する場合、イベント設計と実装の両方を丸投げにすると、後になって「知りたい指標が取れていない」という事態が起こり得ます。発注前に確認しておきたい論点を整理します。

自社で内製するには何が必要か

アプリ解析基盤の構築を内製で行うには、イベント設計・SDK実装・GA4の探索レポート運用という3つの領域を横断して担える人材が必要です。イベント設計だけでもマーケティング側の分析要件とエンジニア側の実装制約をすり合わせる調整力が求められ、単発の実装経験だけでは対応が難しい領域だと言えます。社内に計測設計を専門に担当するメンバーがいない場合、要件定義の段階でつまずくケースが少なくありません。

発注先が提案するイベント設計の根拠を確認する

提案書に「GA4を導入します」とだけ書かれている場合、どのイベントを推奨イベントとして採用し、どこからカスタムイベントに切り替えるのか、その判断基準まで確認する必要があります。ユーザープロパティの設計方針、同意モードの実装範囲、DebugView（実装したイベントをリアルタイムで検証する機能）を使った検証工程の有無を打ち合わせで具体的に質問し、回答の解像度を見ることが実装力を見極める手がかりになります。

イベント定義書とタグ実装箇所の引き継ぎ範囲を契約に明記する

開発会社との契約が終了した後、別の会社や自社に運用を引き継ぐ可能性がある場合は、イベント定義書（イベント名・パラメータ・発生条件の一覧）とSDK実装箇所のソースコードを納品物に含めるよう契約段階で明記しておく必要があります。これらの資料がないまま引き継ぐと、後任の担当者が既存の実装を1つずつ解析するところから作業を始めることになり、追加の調査コストが発生しかねません。

解析基盤は一度作って終わりではなく、アプリの機能追加のたびにイベント定義を更新し続ける運用が前提です。発注時にはこの運用フェーズまで含めた体制を確認しておくことが、長期的な計測品質の維持につながります。

まとめ：アプリ解析基盤導入を機能させる3つの判断軸

本稿では、GA4・Firebase Analyticsを用いたアプリ解析基盤の導入について、イベント設計からユーザープロパティ、ファネル分析・リテンション分析、プライバシー同意までの勘所を整理しました。要点を3つに集約すると次の通りです。第一に、イベントとユーザープロパティは実装後の取り直しが効かないため、意思決定に必要な指標から逆算して設計する順序が欠かせません。第二に、ファネル分析とリテンション分析は役割が異なり、短期の離脱改善と中長期の継続率改善を両輪で検証する視点が必要です。第三に、同意モードの実装は技術要件と法務要件をすり合わせたうえで進め、外注する場合もイベント設計の根拠と引き継ぎ資料の範囲を発注前に確認する姿勢が、長期的な運用品質を左右します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Firebase「Get started with Google Analytics」https://firebase.google.com/docs/analytics/get-started
2. *2　出典：Firebase「Log events」（Google Analytics for Firebase）https://firebase.google.com/docs/analytics/events
3. *3　出典：Firebase「Set user properties」（Google Analytics for Firebase）https://firebase.google.com/docs/analytics/user-properties
4. *4　出典：Google「[GA4] Funnel exploration」（Analytics Help）https://support.google.com/analytics/answer/9327974
5. *5　出典：Google「[GA4] Retention overview report」（Analytics Help）https://support.google.com/analytics/answer/11004084
6. *6　出典：Firebase「Export Firebase data into BigQuery」https://firebase.google.com/docs/projects/bigquery-export
7. *7　出典：Google「Set up consent mode for apps」（Tag Platform）https://developers.google.com/tag-platform/security/guides/app-consent

Tweet