一般的なSaaS型の広告メディエーションSDKを導入すると、イベントストリーム、つまりすべての広告リクエスト、広告インプレッション、ユーザー識別子が、まずベンダーのサーバーに送信されます。ベンダーはそのデータを処理し、付加情報を加え、場合によっては一部の情報を削除したコピーを自社のデータウェアハウスに返します。手元でデータを確認できる頃には、自社で制御できないシステムをすでに経由しているのです。
Firebaseネイティブ型SDKの仕組みは、その逆です。イベントはまず自社のFirestoreとBigQueryに書き込まれます。ベンダーが自社のプロジェクトからデータを読み取るのであって、その逆ではありません。机上の違いに聞こえるかもしれませんが、初めてGDPR監査を受けると、その意味が実感できます。
自社プロジェクトでデータを保有すると何が変わるか
- 削除リクエストはFirestoreクエリ1つで対応可能。ベンダーへのチケット起票も、SLAに沿った対応待ちも不要
- エクスポートのスキーマを自社で管理できるため、BigQueryのコストを予測しやすい
- スキーマ移行はベンダーのリリースに左右されず、自社のスケジュールで実施できる
- サブプロセッサー（再委託先）の開示対象が減り、大幅に減るケースも多い
商談では語られないトレードオフ
Firebaseネイティブ型にもコストはかかります。従来ならベンダーに任せていたストレージとクエリの料金を、Googleに支払うことになります。DAUが500万のアプリでは、BigQueryの請求額は月額400〜1,200米ドル程度です。無視できない金額ですが、それによって守られる広告収益と比べれば、ごくわずかです。
クォータも考慮する必要があります。Firestoreの毎秒の書き込み数、BigQueryのストリーミング挿入、Cloud Functionsのコールドスタートは、いずれも実際の制約です。SaaS型SDKでは、こうした制約への対応が見えないところで行われています。Apps Kit SDKには書き込みをバッチ化するバックプレッシャー制御レイヤーが搭載されており、DAUが100万未満の大半のアプリで無料枠のクォータ内に収まるよう調整します。
Googleに実際に支払う料金
料金体系は地味で単純です。それこそが重要で、すべての費目を自社の請求コンソールで確認できます。以下は、2026年に稼働しているApps Kit SDKの導入環境で見られる費用の目安です。標準搭載のバックプレッシャー制御と、BigQueryパーティションの有効期限90日を適用した場合の金額です。
- DAU 100万：Firestore 40〜90米ドル、BigQueryストレージ20〜50米ドル、BigQueryクエリ30〜80米ドル、Cloud Functions 10〜30米ドル — 合計で月額250米ドル未満
- DAU 500万：Firestore 180〜350米ドル、BigQueryストレージ100〜220米ドル、BigQueryクエリ120〜400米ドル、Cloud Functions 40〜110米ドル — 合計で月額400〜1,200米ドル
- DAU 2,500万：Firestore 700〜1,400米ドル、BigQueryストレージ450〜900米ドル、BigQueryクエリ500〜1,800米ドル、Cloud Functions 150〜400米ドル — 合計で月額1,800〜4,800米ドル
請求額を大きく左右するコスト最適化のポイント
上記の金額に幅がある主な理由は、3つの選択にあります。1つ目は、BigQueryにストリーミング挿入するか、GCS経由でバッチ処理するかです。バッチ処理なら取り込みコストを80%以上削減できますが、レポートに30分の遅延が生じます。2つ目は、パーティションの有効期限です。私たちがこれまで運用で必要としてきたクエリは、すべて90日分のデータで対応できました。それより古い生データはコールドストレージに保存すべきです。3つ目は、クエリの適切な設計です。1年分のインプレッションに対してスキャン範囲を絞らずSELECT *を実行するダッシュボードが1つあるだけで、それ以外のすべてを合計した額より高くつくこともあります。
2026年に重要性がさらに高まった理由
今年は2つの規制上の変化によって、判断の前提が変わりました。DMAのデータポータビリティ要件は現在、EUのエンドユーザーデータを処理するすべてのベンダーに適用され、インドのDPDPの施行猶予期間は3月に終了しました。どちらの制度も、要求に応じて、特定のユーザーに紐づくすべてのイベントを完全にエクスポートできることを前提としています。
SDKベンダーのシステムが正式な記録元であれば、そのベンダーのエクスポートツールに依存します。自社のFirebaseプロジェクトが正式な記録元であれば、使い慣れたクエリでエクスポートできます。
GDPR・DPDP監査の実際の進み方
規制当局や大手企業の顧客から監査を求められた際、必要になるのは4つの資料です。エンドユーザーデータにアクセスするすべてのサブプロセッサーの一覧、指定されたユーザーの完全なデータエクスポート、削除の証跡、そしてデータ保持期間の説明です。SaaS型SDKでは、1つ目はベンダーの開示資料を読んで作成し、次の2つはチケットを起票して依頼し、4つ目は推測で埋めることになります。
Firebaseネイティブ型の構成なら、4つとも自社で管理するクエリや設定から取得できます。サブプロセッサーは、プロジェクト内のGCPサービス一覧。ユーザーデータのエクスポートは、FirestoreとBigQueryのクエリをそれぞれ1つ実行するだけで、どちらもSDKにテンプレートが付属しています。削除の証跡は、削除対象となった行数を返すCloud Functionsの関数。保持期間は、コンソールで確認できるパーティションの有効期限ポリシーです。監査対応は、2週間の慌ただしい作業から半日で済む業務に変わります。
アトリビューションを維持しながらSaaS型SDKから移行する方法
開発チームが移行を恐れるのは、1回のリリースですべてを切り替えると考えているからです。私たちはその方法を取りません。Firebaseネイティブ型SDKを既存のSaaS型SDKと2〜4週間併用し、新しいパイプラインにデータを書き込みます。その間も、従来のパイプラインは既存のすべてのダッシュボードとMMPへのデータ供給を続けます。
- 1週目：Firebaseネイティブ型SDKをシャドーモードで導入。ユーザー向けの挙動は変えず、BigQueryでイベントデータの一致を検証
- 2週目：アトリビューションのポストバックをFirebaseネイティブ型の経路に切り替え。広告メディエーションは旧SDKで継続
- 3週目：広告メディエーションを切り替え。SaaS型SDKは参照用イベントの送信だけを続け、データに差異が出た際の照合に使用
- 4週目：次のアプリアップデートでSaaS型SDKを削除し、依存関係を完全に解消
それでもSaaS型が適しているケース
チームがFirebaseをまったく使っておらず、今後も導入する予定がないなら、Firebaseネイティブ型SDKの運用負荷は無視できません。リリース後の運用に手をかけたくない開発スタジオや、データの所有権がまだ戦略的な資産になっていないプロトタイプには、SaaS型の広告メディエーションが適しています。これは技術的な判断ではなく、監査証跡を誰に管理させたいかという判断です。
イベントストリームを自社で保有することは、単なるプライバシーへの姿勢表明ではありません。次のベンダー契約で、確かな交渉力を持って臨めるか、スクリーンショットだけを頼りに臨むかの違いです。
今四半期に取り組むべきこと
すでにFirebase Analyticsを使っているなら、Firebaseネイティブ型広告SDKの導入に必要な準備は60%まで進んでいます。そのことに気づいていないだけかもしれません。1スプリントを使って、上記のシャドーモードでの導入を実施し、営業資料ではなくデータの一致状況レポートで判断してください。シャドーモードでの検証を終えたチームの多くは、90日以内に切り替えを決めています。
