「コンバージョン数がここ2年、じわじわ減っている——設定は何も変えていないのに」。心当たりがあるなら、原因は設定ではなく、ブラウザそのものかもしれません。
サードパーティCookieは消えつつあります。SafariとFirefoxはすでにブロックしています。Chromeも大幅に制限しました。あらゆる広告プラットフォームの計測は——程度の差はあれ——ブラウザが段階的に排除しているCookieに依存しています。結果：コンバージョン数がじわじわ下がり、アトリビューションのギャップが広がり、スマート入札に渡されるデータが減っていきます。
対策は1つの設定変更ではありません。戦略の転換です。ブラウザが管理するCookieへの依存から、ファーストパーティデータ——サイトがユーザーから直接収集する情報——の活用へ。このガイドでは、何が壊れるか、何が代替するか、計測が維持されているかの検証方法を解説します。
1. サードパーティCookieが消えると何が壊れるか
サードパーティCookieは、ユーザーが訪問しているドメイン以外のドメインによってセットされるCookieです。広告プラットフォームはこれを使って：
- サイトをまたいだユーザー追跡——サイトAでの広告クリックをサイトBでのコンバージョンに接続
- コンバージョンのアトリビューション——コンバージョンを発生させた広告に紐づけ
- リマーケティング——再訪ユーザーの認識とオーディエンスターゲティング
これらのCookieがブロックされると：
| 従来の動作 | 壊れること |
|---|---|
| Google広告Cookieが広告クリックとCVを接続 | gclidのURLパラメータのみに依存（ストリップされる場合あり） |
| Meta Pixel Cookieが訪問間でユーザーを識別 | Pixelは発火するが、広告インタラクションとの紐づけ不可 |
| クロスサイトのリマーケティングオーディエンス | オーディエンスプールが縮小（サイト間でユーザー識別不可） |
| ビュースルーコンバージョン | ほぼ消滅——広告閲覧と後のサイト訪問を接続するCookieがない |
プラットフォームごとの影響度：
- Google広告： 最も影響が少ない。Google自体が検索エンジンと広告ネットワークを所有し、ファーストパーティの文脈がある
- Meta： 大きく影響を受ける。アトリビューションがクロスサイトCookieマッチングに依存（CAPIを強く推進する理由）
- 小規模な広告プラットフォーム： 最も影響が大きく、補うインフラも最も少ない
2. ファーストパーティデータのツールキット
ファーストパーティデータとは、ウェブサイトが直接収集する情報です：フォーム送信、購入取引、メールアドレス、電話番号、ログイン状態など。自社ドメインで収集されるため、サードパーティCookieの制限に影響されません。
コンバージョン計測を維持するためにファーストパーティデータを使うツール群を紹介します。
拡張コンバージョン（Google）
コンバージョンタグとともに、ハッシュ化されたファーストパーティデータ（メール、電話番号、氏名、住所）を送信。GoogleがGoogle自身のユーザーデータと照合し、アトリビューション精度を向上させます。
解決する問題： gclidのCookieが失われた場合のギャップを埋める（クロスデバイス、ITPによるCookie削除、長いコンバージョンウィンドウ）。
検証方法： 拡張コンバージョンの確認を参照。
Conversions API / CAPI（Meta）
コンバージョンイベントをサーバーからMetaのAPIに直接送信し、ブラウザを完全にバイパス。イベントにはマッチング用のハッシュ化ユーザーデータ（メール、電話番号、IP、ユーザーエージェント）が含まれます。
解決する問題： Pixelが広告ブロッカー、ITP、Cookie制限でブロックされても、コンバージョンデータがMetaに届く。
検証方法： Meta Conversions APIの検証を参照。
サーバーサイドタギング（Google Tag Manager）
タグ処理をユーザーのブラウザから、自社管理のサーバーに移行。サーバーサイドGTMコンテナがブラウザからイベントを受信・処理し、広告プラットフォームに転送します。
解決する問題：
- サーバーが設定するファーストパーティCookie（ITP下のJavaScript設定Cookieより長寿命）
- 広告ブロッカー回避（リクエストが自社ドメインに向かい、
googleadservices.comには向かわない） - データ制御の向上（サーバーから何を送るか自社で決定）
検証方法： サーバーサイドGTMの検証を参照。
Googleタグゲートウェイ
Googleタグゲートウェイは、Googleのトラッキングスクリプトとデータ収集エンドポイントを自社ドメイン（例：analytics.yourdomain.com、googletagmanager.comの代わり）から配信します。サーバーサイドGTMコンテナの前段に配置されます。
解決する問題：
- トラッキングリクエストがブラウザや広告ブロッカーからはファーストパーティのトラフィックに見える
- ゲートウェイ経由で設定されたCookieはファーストパーティCookieとして扱われ、寿命が長い
- Google Cloud（GCP）でのワンクリックセットアップ、またはCloudflare・Akamaiなど他のCDN経由で利用可能
計測への影響： Googleタグゲートウェイを導入した広告主は、計測されるコンバージョンが9〜18%増加したと報告しています。主に広告ブロッカーとITPのCookie制限で失われていたシグナルの回復によるものです。
サーバーサイドGTMとの関係： タグゲートウェイはサーバーサイドGTMの代替ではなく、リクエストを自社ドメイン経由でサーバーサイドGTMコンテナにルーティングするネットワークレイヤーです。サーバーサイド設定をブラウザから見えなくする「玄関口」と考えてください。
Google・Meta以外のプラットフォームのサーバーサイドAPI
拡張コンバージョン（Google）とCAPI（Meta）に加え、他のプラットフォームにも同等のサーバーサイドソリューションがあります：
- TikTok Events API： サーバー間でコンバージョンイベントを送信。ハッシュ化メール/電話番号でマッチング。広告ブロッカー使用率が高いオーディエンスのTikTokキャンペーンには必須。
- LinkedIn Conversions API： LinkedIn Insight Tagのサーバーサイド代替。オフラインコンバージョンと拡張マッチングをサポート。2023年にローンチされ、現在はInsight Tagとの併用が推奨。
- Pinterest API for Conversions： Pinterestキャンペーン向けのサーバーサイドイベント。Pinterest Tagとの重複排除に対応。
パターンは共通です：すべての主要広告プラットフォームがサーバーサイドイベント経路を提供しています。ファーストパーティデータインフラを構築する際は、GoogleとMetaだけでなくマルチプラットフォームのサーバーサイド対応を計画してください。
カスタマーマッチ / カスタムオーディエンス
顧客リスト（ハッシュ化メール、電話番号）を広告プラットフォームに直接アップロードし、ターゲティングと計測に使用。完全にファーストパーティデータベースのアプローチで、Cookieは一切関与しません。
解決する問題： Cookie依存なしでリマーケティングとオーディエンスベースの計測を実現。
同意モードとモデリング
ユーザーがCookieを拒否した場合、同意モードはGoogleタグにCookieなしのpingを送信するよう指示。Googleはこのpingと、同意したユーザーのデータを組み合わせ、非同意グループのコンバージョン推定数をモデル化します。
解決する問題： Cookieを拒否したユーザーからの失われたコンバージョンデータの一部を、ユーザーの選択に違反することなく回復。
制限： モデル化されたコンバージョンは推定値であり、計測値ではありません。精度は、信頼できるモデルを構築するのに十分な同意ユーザーがいるかに依存します。
3. ファーストパーティデータ戦略の構築
ファーストパーティデータへのシフトは、1つのツールの導入ではありません。複数のシグナルを重ねることで、ブラウザが次に何をしようと計測が強靱になる仕組みを作ることです。
優先度1：コンバージョン時にユーザー識別子を取得
コンバージョンの瞬間（フォーム送信、購入）に、マッチングに使える識別子を少なくとも1つ取得：
- メールアドレス（最も信頼性が高い。拡張CV、CAPI、カスタマーマッチで使用）
- 電話番号（補助的。CAPIと拡張CVに有用）
- gclid / fbclid / その他クリックID（存在する場合は有用だが、唯一のシグナルにはできない）
優先度2：サーバーサイド経路を実装
最も重要なコンバージョン計測をサーバーサイドに移行：
- Google広告： 拡張コンバージョン（最も簡単）またはサーバーサイドGTM（より細かな制御）
- Meta： Pixelと併用してConversions API（Metaは両方を推奨——「重複」イベントは重複排除される）
- GA4： GA4サーバーサイドクライアントを使ったサーバーサイドGTM
優先度3：サーバーからファーストパーティCookieを設定
JavaScript設定のCookieはブラウザからますます厳しい制限を受けています：
| ブラウザ | JavaScript設定Cookieの寿命 | サーバー設定Cookieの寿命 |
|---|---|---|
| Safari（ITP） | 標準で7日間。トラッカーと分類されたドメイン（主にリダイレクト目的のドメインなど）は24時間 | 設定した有効期限まで（例：1〜2年） |
| Firefox（ETP） | 制限あり。クロスサイトCookieはデフォルトでブロック | サーバー設定のファーストパーティCookieは影響なし |
| Chrome | サードパーティCookieは制限。ファーストパーティのJavaScript Cookieは現時点では制限なし | サーバー設定のファーストパーティCookieは影響なし |
Safariの24時間制限は特にダメージが大きい：ユーザーが今日広告をクリックして明日コンバージョンした場合、Cookieはすでに消えています。サーバー設定Cookie（HTTPレスポンスヘッダーまたはGoogleタグゲートウェイ経由）はこの制限をバイパスします。Safariが真のファーストパーティデータとして扱うためです。
サーバーサイドGTMまたはGoogleタグゲートウェイを使えば、セッションをまたいで保持されるファーストパーティCookieを自社ドメインに設定でき、コンバージョンウィンドウ全体にわたるユーザーの同一性を維持できます。
ファーストパーティデータツールの定量的な影響
これらのツールでどの程度回復できるか？業界データに基づくと：
| ツール | 典型的なコンバージョン回復率 |
|---|---|
| 拡張コンバージョン（Google） | アトリビューション済みCVが5〜15%増加 |
| Conversions API（Meta） | Pixel単独比でCVが15〜30%増加 |
| サーバーサイドGTM＋タグゲートウェイ | 計測CVが9〜18%増加 |
| 同意モード＋モデリング | 同意率に応じて5〜20%回復 |
これらは単純加算ではありません——重複があります。しかし、ファーストパーティデータスタックを完全に実装（拡張CV＋CAPI＋サーバーサイドタギング＋同意モード）すれば、Cookie制限や広告ブロッカーで失われるコンバージョンの20〜35%を一般的に回復できます。
優先度4：同意インフラ
ファーストパーティデータ戦略でも同意は必要です。以下を満たす同意管理プラットフォーム（CMP）を実装：
- ユーザーの同意選択を取得
- Google同意モードと統合（
ad_storageとanalytics_storageパラメータを設定） - 同意されたファーストパーティデータを活用しつつ、拒否を尊重
4. 実際にどう動くか
適切に実装されたファーストパーティデータ設定が、異なるユーザーシナリオをどう処理するか：
| シナリオ | 何が起きるか | データ品質 |
|---|---|---|
| Cookie同意して成約 | タグが通常発火、gclid＋Cookie＋拡張CVデータすべて利用可能 | 完全なアトリビューション |
| Cookie拒否して成約 | タグが制限モードで発火（同意モード）、拡張CVデータ（ハッシュ化メール）は送信、CAPIがサーバーサイドイベント送信 | 部分的——ただしメールマッチングでほとんどのアトリビューションを回復 |
| 広告ブロッカーで全ブロック | クライアントサイドタグは完全にブロック | CAPI（サーバーサイド）がイベントを送信。クライアントサイドは失われる |
| クロスデバイス：スマホで広告クリック、PCで成約 | Cookieが2デバイス間を接続できない | 拡張コンバージョンがメールでデバイス間マッチ |
| 長いCVウィンドウ（今日クリック、30日後に成約） | ITPが7日後にCookieを削除した可能性 | URLパラメータのgclid＋拡張CVメールでマッチ回復 |
ファーストパーティデータツールなしでは、シナリオ2〜5はすべてコンバージョンの損失になります。ツールがあれば、ほとんどのデータが回復できます。
5. ファーストパーティデータ戦略が機能しているかの検証
チェック1：拡張コンバージョンの診断
Google広告 → 目標 → コンバージョン → 診断で、拡張コンバージョンのステータスを確認：
- マッチ率（拡張データでマッチされたコンバージョンの割合）
- 各フィールド（メール、電話番号、氏名、住所）のデータ品質指標
マッチ率がほぼゼロなら、拡張コンバージョンデータが送信されていないか、マッチしていません。
チェック2：CAPIイベントマッチ品質（Meta）
Metaイベントマネージャで、CAPIイベントのイベントマッチ品質スコアを確認。Metaは1〜10でスコアリング：
- 7〜10： 良好——信頼性の高いマッチングに十分なパラメータ
- 4〜6： 中程度——パラメータの追加が必要（メール、電話番号、IP）
- 1〜3： 不十分——イベントは届いているがMetaがユーザーにマッチできない
チェック3：ブラウザサイド vs サーバーサイドのイベント数比較
クライアントサイドとサーバーサイドの両方を運用している場合（Meta推奨）、イベント数を比較：
- サーバーサイドがクライアントサイドを大幅に上回る場合、広告ブロッカーやITPでクライアントサイドがブロックされている
- ほぼ同数なら、ほとんどのユーザーが両方を通過——ただしサーバーサイド経路がレジリエンスを提供
チェック4：Cookie寿命の監査
ファーストパーティCookieが実際にどれくらい保持されるか確認：
- DevTools → Application → Cookiesで有効期限を確認
- SafariのJavaScript設定Cookieは7日間（またはそれ以下）の期限を表示
- サーバー設定Cookieは設定した値に応じた長い期限を表示すべき
チェック5：同意モードの検証
3つの同意状態でテストコンバージョンを送信：
- 同意あり： タグがフル発火、すべてのデータ送信
- 同意拒否： タグが制限モードで発火（Cookie なし、限定データ）
- 同意選択未了： デフォルト設定に依存（タグが発火するか確認）
各状態で、DevToolsのNetworkタブを使ってどのデータが広告プラットフォームに届くかを確認。
6. モデリングの問題：モデル化されたコンバージョンは信頼できるか
Googleのモデル化されたコンバージョンは、Cookieが制限されていなければ計測されたであろうコンバージョンを推定します。計測されたコンバージョンと並んでレポートに表示されます——明確な区別なしに。
信頼できるとき：
- 同意率が約30%以上（信頼できるモデルを構築するのに十分な実データ）
- モデル化された数値がバックエンドデータと方向的に一致
- トレンド分析と入札最適化に使用する場合（正確なカウントではなく）
注意すべきとき：
- 同意率が非常に低い（約10%未満）場合——モデルが動作するには少なすぎるデータ
- ビジネスの変化がないのにモデル化CVが急増・急減した場合
- プラットフォーム報告のCVを正確なバックエンド取引件数と比較する場合
実務的なアプローチ：入札と最適化にはモデル化＋計測コンバージョンを使い（プラットフォームはそのために設計されている）、売上レポートにはバックエンドデータをソースオブトゥルースとして使う。
よくある質問
Q. サーバーサイドトラッキングがあれば、コンバージョンタグはもう不要ですか？ A. いいえ、両方を運用してください。クライアントサイドタグはリアルタイムシグナルを提供し、ダイナミックリマーケティングなどの機能をサポートします。サーバーサイドはレジリエンスを提供します。ほとんどのプラットフォームは冗長実装を推奨——重複排除されるため二重計上にはなりません。
Q. サーバーサイドタギングで広告ブロッカーを完全に回避できますか？ A. ほぼ可能ですが、完全ではありません。サーバーサイドタギングはリクエストを自社ドメイン経由にするため、標準的な広告ブロッカーはブロックしません。ただし、DNSレベルですべてのサードパーティ通信をブロックする積極的なプライバシーツールは干渉する可能性があります。
Q. サーバーサイドタギングのコストはどのくらいですか？ A. 主なコストはサーバーインフラ（GoogleのサーバーサイドGTM用のCloud RunまたはApp Engineインスタンス）。一般的なコスト：月額5,000〜30,000円程度（トラフィック量による）。実装コスト（開発者のセットアップ・保守時間）はホスティングコストより大きいことが多いです。
Q. 同意率が非常に低いです。何ができますか？ A. まず同意バナーを見直してください——デザイン、タイミング、明瞭さがオプトイン率に大きく影響します。適切に設計されたバナーは通常30〜50%の同意を達成します。次に、同意したユーザーから取得するデータを最大化（拡張CV＋CAPIを実装）。最後に、モデル化されたコンバージョンでギャップを埋めつつ、バックエンドデータをソースオブトゥルースとして使用。
まとめ：ファーストパーティデータはプロジェクトではなく、新しい基盤
Cookie依存型からファーストパーティデータベースのコンバージョン計測への移行は、選択肢ではありません。ブラウザがあなたに代わって決断しています。問題は、これらのツールを採用するかどうかではなく、どれだけ速く、どれだけ完全に採用するかです。
良いニュースは、ツールは存在し成熟していることです。拡張コンバージョン、CAPI、サーバーサイドタギング、モデリング付き同意モードが、トラッキングシナリオの大半をカバーします。必要なのは実装と検証——設定し、ユーザーが遭遇するすべてのシナリオで実際に機能するかを確認することです。
ConversionOKは、サイトが送信するコンバージョンシグナル——クライアントサイドタグ、拡張コンバージョンデータ、サーバーサイドイベントのいずれであれ——が実際に広告プラットフォームに届いているかを検証します。計測環境がファーストパーティデータに移行する中、検証の重要性は減るのではなく増しています。データが移動する経路が増え、静かに失敗するポイントも増えるからです。