SDK開発者の悩み「データ分散問題」を解決する、Measurement Protocol活用術

こんにちは！NTTドコモマーケティング戦略部の井上裕太です。

普段はコンシューマー向けアプリに導入されているSDKの開発チームに所属し、プロダクトオーナー業務の一端を担っています。

SDK開発者のみなさん、「自分たちが提供しているSDKが、実際にアプリ内でどう動いているか」を正しく把握できていますか？

「SDKの利用データを計測したいが、導入アプリ（ホストアプリ）の分析設定と競合するのが怖い」「通常の手段でログを送ると、各アプリのプロパティにデータが送信されてしまい、SDKチームの手元でデータを集約・分析できない」 SDK開発者なら、そんな「データの所有権」や「集約」の課題に頭を悩ませたことがあるのではないでしょうか。

今回は、我々SDKチームが直面した「分析データが分散してしまう問題」と、それをGoogle アナリティクス4 (GA4) の Measurement Protocol を活用して解決し、プロダクト品質の向上につなげた話をご紹介します。

抱えていた問題

我々のSDKには、これまで十分なデータ分析機能が搭載されていませんでした。

機能改善や不具合調査のために「ログを取りたい」と考えたとき、SDK開発ならではの構造的な壁にぶつかりました。

1. 技術的な制約

通常、モバイルアプリでGA4を利用する場合はFirebase SDKを導入するのが一般的です。しかし、この方法は「アプリ」のためのものであり、「SDK（ライブラリ）」が独自にデータを収集するために使うことはできません。

Googleの仕様上、Google アナリティクスは1つのアプリにつき1つの設定ファイル（google-services.json や GoogleService-Info.plist）に紐づくため、仮にSDK内にFirebase SDKを組み込んだとしても、ログはすべてホストアプリ側のプロパティに送信されてしまいます（あるいは依存関係の競合でビルドエラーを引き起こします）。

2. データの分断

SDKを導入しているアプリがFirebase SDKを組み込んでいる場合はデータを送信することが可能ですが、仮にデータを送れたとしても「各アプリのプロパティ」に格納されてしまいます。（逆に、SDK導入アプリがFirebase SDKを組み込んでいなければ、そもそもデータを送信することもできません。）

AアプリのSDKログ → AアプリのGA4プロパティ
BアプリのSDKログ → BアプリのGA4プロパティ

これでは、我々SDK開発チームにデータの閲覧権限がありませんし、仮に閲覧できたとしても「全導入アプリを横断的に分析する」ことが不可能です。「特定の環境下で発生するエラー」や「アプリごとの利用頻度の偏り」を見つけ出すことが非常に困難でした。

我々がやりたかったのは、「ホストアプリの環境に一切依存せず、SDKチームが管理するプロパティに、全アプリのSDKデータを集約すること」でした。

解決策：Measurement Protocol の採用

この課題を解決するために採用したのが、Google アナリティクスの Measurement Protocol です。

Measurement Protocol とは？

Measurement Protocol は、HTTPリクエストを使って、Google アナリティクスのサーバーに直接イベントデータを送信できる仕組みです。

通常のモバイルアプリ向けSDK（Firebase SDK）がアプリ内のライブラリとして動作します。一方、Measurement Protocolはサーバーやスクリプト、あるいはSDK内部からHTTP POSTを投げるだけで動作します。

参考：Measurement Protocol（Google アナリティクス 4） | Google Analytics | Google for Developers developers.google.com

採用の決め手

最大のメリットは、送信先のプロパティをこちらで完全に制御できる点です。

ホストアプリがどのGA4アカウントを使っていようと、SDK内部からHTTPリクエストを生成し、我々が管理する firebase_app_id 宛に送信すれば、データは確実に我々のプロパティに蓄積されます。これにより、ホストアプリの設定に干渉することなく、独自の計測網を構築できるようになりました。

Measurement Protocol の技術解説

ここでは、実際にどのような仕組みでデータを送信するのか、一般的な仕様に基づいてご紹介します。実装は非常にシンプルで、主に以下のステップで行います。

1. 準備：IDとシークレットの取得

GA4の管理画面から、以下の2つを取得します。

firebase_app_id: データの送信先となるデータストリームのID
API Secret (api_secret): 不正なデータ送信を防ぐためのシークレット

2. リクエストの構築

データは HTTP POST リクエストで送信します。

エンドポイント: https://www.google-analytics.com/mp/collect
クエリパラメータ: firebase_app_idと api_secret を付与

3. リクエストボディ（JSON）の構築

実際に送信するデータはJSON形式で構築します。以下は、SDKの初期化イベントとエラーイベントをまとめて送信する場合のペイロード（データ本体）の例です。

主要パラメータの解説

app_instance_id: ユーザー（またはデバイス）を一意に識別するID。SDK側でUUIDなど（「-（ハイフン）」なしの文字列である必要があります）を生成するような実装が必要になります。また、この値が変わると別ユーザーとしてカウントされるため、セッション継続性を意識する場合はローカルストレージなどに保存して使い回す工夫が必要です。
events: 発生したイベントの配列。
- name: イベント名（例: sdk_initialized, sdk_error）。
- params: カスタムパラメータ（例: sdk_version, error_code）。SDKのバージョンやエラーコード、処理にかかった時間などをここに詰め込みます。

実装上の注意点

Measurement Protocol は強力ですが、通常のFirebase SDKと異なり「自動でやってくれること」が少ないです。

例えば、アプリのライフサイクル管理やネットワークオフライン時の再送処理などは、SDK側でロジックを組む必要があります。また、リクエスト数が膨大になるとクライアントの通信量を圧迫するため、バッチ送信（複数のイベントをまとめて送る）などの工夫も検討すべきでしょう。

また、Measurement Protocolで送信したイベントをGA4の「DebugView」で確認するには、公式ドキュメントにある「DebugViewを有効にする」だけでは不十分で、送信するデータ自体（上記で紹介したJSON）に特定のフラグを埋め込む必要があります。

具体的には、リクエストボディ（JSON）内の各イベントの params に"debug_mode": 1 （または true）を含めてください。このパラメータがないと、データは通常の通信として処理され、リアルタイムレポートには表示されますが、DebugViewのタイムラインには表示されません。

さらに、送信するイベントのapp_instance_idにはFirebase SDKから取得したIDをセットする必要がある点にも注意してください。

導入後の成果：アプリを横断した分析が可能に

ここまででご紹介したデータ分析の仕組みをSDKに導入した結果、我々の管理画面1つで、すべての導入アプリのSDK利用状況を可視化できるようになりました。

1. データの集約と可視化

これまでブラックボックスだった「各アプリ内で我々のSDKがどう動いているか」が、迅速に把握できるようになりました。SDKのバージョンごとの普及率や、特定のOSバージョンでのエラー発生率などが一目瞭然です。

2. 横断分析によるアプリの品質改善

データを集約できたことで、アプリ間の比較分析が可能になりました。例えば、あるエラーイベントの発生率をアプリごとにグラフ化したところ、「エラーがほとんど出ないアプリ」と「頻繁にエラーが出ているアプリ」が明確に分かれました。

分析: 両者の実装方法やパラメータ設定をヒアリングし、比較。
発見: BアプリはSDKが提供しているAPIの実行タイミングが推奨と異なっており、特定の条件下でエラーを引き起こしていたことが判明。
アクション: この知見を基に、優良実装（Aアプリ）のパターンを参考にドキュメントを改修し、全アプリに向けて展開。Bアプリに対しては個別にサポートを行い、エラーが出やすい実装パターンの改修を実施。

結果として、Bアプリだけでなく、同様の実装をしていた他のアプリの安定性も向上させることができました。

これは、個別の問い合わせ対応だけでは見えてこなかった、データ集約ならではの成果です。