Google広告 Data Manager API移行｜オフラインCVを止めない設定と確認方法

CRMでは商談や受注が増えているのに、Google広告へ戻るオフラインコンバージョンが急に減った。連携ツールには成功と表示されるのに、広告管理画面の入札へ反映されない。この状態を放置すると、Google広告は本当に価値のある問い合わせを学習できず、フォーム送信数だけを増やす方向へ予算を使うおそれがあります。

確認すべきなのは入札戦略より先に、CRMや自社システムからGoogle広告へ成果を返す経路です。Googleは2026年6月15日以降、オフラインコンバージョンとリードの拡張コンバージョンのアップロードをData Manager APIへ移行し、条件に該当するGoogle Ads APIの送信を制限しています。従来の仕組みが一時的に動いていても、今後の継続を前提にするなら移行準備が必要です。

Data Manager APIへの移行は、URLだけを差し替える作業ではありません。Google Cloud側でAPIを有効にし、認証方法とGoogle広告アカウントへのアクセスを整え、送信先のコンバージョンアクション、イベント時刻、クリックIDやユーザー提供データを新しいリクエストへ対応させます。受付後の診断と広告管理画面の反映も確認して、初めて移行完了と言えます。

この記事では、現在の送信経路の調べ方、Google CloudとGoogle広告の権限設定、イベント送信時に必要な項目、重複を避ける設計、移行後の照合方法を初心者にも追える順番で説明します。既存のGoogle広告オフラインコンバージョンの実務で紹介した営業データの戻し方を、2026年のAPI変更に合わせて止めずに運用するための技術・運用編です。

2026年の変更で何が止まる可能性があるのか

Googleの公式情報では、2026年6月15日以降、オフラインコンバージョンのインポートとリードの拡張コンバージョンのアップロードはData Manager APIへ移行されます。Google Ads APIを使う従来経路のうち、一定期間に送信実績がない開発者トークンでは、`UploadClickConversions` が許可されずエラーになると案内されています。既存利用者に猶予がある場合でも、新規構築や改修を旧方式で始める理由はありません。

影響を受けやすいのは、自社のCRMや基幹システムからGoogle Ads APIへ直接送っている構成です。社内でPythonやPHPの定期処理を動かしている、外部ツールが古いGoogle Ads APIのオフラインCV機能を使っている、代理店が独自のアップロード基盤を持っている場合は経路を確認してください。Google広告の画面からCSVを手動アップロードする運用や、Googleタグでウェブコンバージョンを測る運用とは確認点が異なります。

連携サービスを使っている場合、利用者側がAPIコードを変更しなくても、サービス提供会社が裏側を移行することがあります。ただし『何もしなくてよい』と推測してはいけません。サービス名、使っているアクション、移行予定、利用者に必要な再認証、過去データの扱いをサポートへ確認し、回答を運用記録へ残します。送信件数が減ってから問い合わせるより、正常時の件数を把握しておくほうが復旧が早くなります。

この変更は、広告画面に表示されるすべてのコンバージョンが一斉に消えるという意味ではありません。フォーム完了をGoogleタグで測るコンバージョンは別経路です。今回の中心は、問い合わせ後に判明した有効商談・契約・売上などをサーバーやCRMから戻す処理です。まずどの成果がどの経路で届いているかを分けてください。

Google広告ヘルプ：オフライン コンバージョンのインポートについて

移行前に送信元・経路・担当を棚卸しする

最初の作業はコード修正ではなく、現在のデータ経路を一枚にすることです。問い合わせが入った時点で保存する情報、営業が有効商談へ変更する場所、アップロード対象を抽出する条件、Googleへ送る処理、広告管理画面で確認するコンバージョン名を順番に書き出します。『CRM連携』という一語で済ませると、どこで件数が減ったか分かりません。

管理画面やサーバーで、実際に使われている認証情報とAPIを確認します。Google Ads APIの開発者トークン、OAuthクライアント、サービスアカウント、定期実行ジョブ、利用ライブラリのバージョンを一覧にします。秘密鍵やトークン自体を共有表へ貼らず、保管場所と管理者だけを記録してください。個人アカウントの退職や権限変更で止まる構成も、この段階で見つけられます。

送信する成果の定義も見直します。フォーム送信、電話問い合わせ、有効リード、商談化、受注を全部同じ価値で送ると、APIが正常でも自動入札は混ざった信号から学習します。広告の最適化に使うメイン成果と、状況確認だけに使うサブ成果を分け、Google広告のコンバージョンアクション名とCRMのステージ名を対応させます。

移行担当は開発者だけでは足りません。開発担当は認証と送信、広告担当はコンバージョンアクションと入札、営業担当はステージ定義と確定日時を確認します。テスト用の問い合わせを誰が作り、誰が商談化し、誰が広告画面で確認するかまで決めてください。担当が分かれていても、同じテストIDを見られる状態が必要です。

Google CloudとGoogle広告のアクセスを準備する

Data Manager APIを使うには、Google Cloudプロジェクトと必要な権限を持つGoogleアカウントを準備します。Google Cloud Consoleで対象プロジェクトを選び、APIとサービスのライブラリからData Manager APIを有効にします。既存プロジェクトを使う場合は、誰が所有者か、請求先や監査ログの管理方針が社内ルールに合うかも確認してください。

認証方法は、担当者が手元で試すユーザーアカウントと、定期処理を動かすサービスアカウントを分けて考えます。本番の自動送信では、人のログイン状態に依存しないサービスアカウントが運用しやすい場合があります。一方、Google OAuthの同意画面や審査が関係する構成もあるため、既存システムの認証方式を無理に変えず、Google公式のセットアップ手順に沿って選びます。

Google Cloudで認証情報を作っただけでは、Google広告の送信先へ書き込めません。利用するユーザーまたはサービスアカウントのメールアドレスを、対象のGoogle広告アカウント、またはアクセス権を持つ親MCCへ追加します。権限を最小限にする方針と、コンバージョンデータを送るために必要な操作権限の両方を確認してください。

ここで混同しやすいのが、Cloudプロジェクトの権限とGoogle広告アカウントの権限です。Cloud側でAPIを有効化できても、広告アカウントへアクセスできなければ送信は失敗します。反対に広告管理者でも、Cloud側でAPIを有効にする権限がなければ準備できません。エラーが出たときは両方を分けて確認します。

設定日、CloudプロジェクトID、認証方式、Google広告の顧客ID、権限を付与したアカウント、確認者を記録します。鍵ファイルやアクセストークンは記事や共有ドキュメントへ貼らず、会社の秘密情報管理ルールに従って保管します。テスト環境と本番環境で同じ秘密鍵を使い回さないことも大切です。

Google Developers：Data Manager APIのアクセス設定

Data Manager APIへイベントを送る実務手順

本番データを一括送信する前に、一件の検証用イベントでリクエストを組み立てます。送信先には、データを受け取るGoogle広告アカウントとコンバージョンアクションを指定します。MCC経由で操作する場合は、ログインに使うアカウントと実際の送信先を混同しないようにします。顧客IDやアクションIDは表示名ではなく、管理画面またはAPIで確認した値を使います。

イベントには、成果が起きた日時、通貨と価値を使う場合の金額、イベントソース、照合に使う識別子を含めます。オフラインコンバージョンやリードの拡張コンバージョンでは、GCLID・GBRAID・WBRAIDなどの広告識別子、セッション属性、ユーザー提供データなど、用途に合う識別情報が必要です。メールアドレスや電話番号を扱う場合は、正規化、ハッシュ化、同意、保管期間を含むデータ管理を確認します。

同じ成果をタグとAPIの両方から送る構成では、重複計上を避ける設計が欠かせません。Googleの送信ガイドでは、同じコンバージョンアクション内で`transactionId`を使って重複を排除する仕組みが案内されています。注文番号や商談IDを使う場合は、再送時も同じIDになるようにし、個人情報をそのままIDへ入れないでください。

最初は検証用の送信、または小さな件数で始めます。HTTP応答が成功でも、各レコードが最終的に処理されたとは限りません。受付時のリクエストIDや診断情報を保存し、処理結果を確認できるようにします。失敗レコードだけを再送できる設計にすると、全件を繰り返して重複させる事故を減らせます。

イベント時刻は、APIを実行した時刻ではなく、商談化や受注が確定した時刻を使います。タイムゾーンとRFC 3339形式を確認し、未来時刻や古すぎるデータが混ざらないようにします。CRMで日付だけを持っている場合は、どの時刻を補うかを運用ルールとして決め、担当者ごとに違う値を作らないようにします。

Google Developers：Data Manager APIでイベントを送信する

診断結果を見て移行できたか判断する

移行判定を『エラーが出なかった』だけで終わらせないでください。CRMで送信対象になった件数、アプリケーションが組み立てた件数、Data Manager APIが受け付けた件数、処理後に有効になった件数、Google広告で確認できた件数を分けて記録します。差が出た段階が、そのまま調査の出発点になります。

認証エラーなら、アクセストークンのスコープ、サービスアカウントのGoogle広告アクセス、対象アカウントを確認します。リクエスト形式のエラーなら、必須項目、日時形式、送信先ID、イベントソースを確認します。受付後の不一致が大きい場合は、識別子の欠損、正規化、ハッシュ化、成果日時、同意、クリックから成果までの期間を見ます。

Google広告の管理画面では、対象コンバージョンアクションの診断とステータスを確認します。反映には時間差があるため、API送信直後に同数にならなくても失敗とは限りません。テストID、送信日時、成果日時、件数を記録し、同じ条件で翌日も確認します。画面の総数だけを見ず、可能ならコンバージョンの日時別列も使ってCRMの成果日と照合します。

旧方式と新方式を短期間だけ並行稼働する場合は、同一成果の二重計上を防ぐ仕組みが必要です。別々のコンバージョンアクションで比較するのか、同一アクションへ同じtransactionIdを送るのかを事前に決めます。判断できないまま両方を本番へ流すより、検証用アクションや限定データで確認してください。

一致率だけでなく、広告運用への影響も見ます。移行前後で有効リード数、商談化率、受注率、インポートまでの日数が変わっていないかを確認します。APIの受付率が高くても、営業が確定する前の浅い成果ばかり送っていれば、広告の改善にはつながりません。

失敗しやすい移行パターンと対策

最も多いのは、旧処理がまだ動いているため移行を先送りすることです。猶予対象のトークンや外部ツールでは、すぐ停止しない場合があります。しかし、障害やアカウント変更をきっかけに再構築が必要になると、短期間で新方式へ切り替えなければなりません。正常なうちに経路と件数を記録し、検証環境を用意してください。

次に、開発担当だけで移行を完了させるパターンです。APIが200を返しても、広告のコンバージョンアクションがサブ扱い、価値が誤っている、営業のステージと違う、といった問題はコードだけでは判断できません。広告担当と営業担当が同じテスト成果を確認する時間を、公開手順へ含めます。

個人情報の扱いを後回しにすることも避けてください。メールや電話番号を照合に使う場合、利用目的、取得時の案内、正規化・ハッシュ化、アクセス権、ログへの露出、保存期間を確認します。デバッグのために生の個人情報をログ出力すると、計測精度とは別の重大な問題になります。テストには専用データを使い、本番ログを必要最小限にします。

件数の差をすべてAPI障害と決めつけるのも危険です。広告側はクリック日に計上される指標と成果日に計上される指標があり、CRMは商談確定日で集計していることがあります。比較する期間と日付軸をそろえないと、正常でも差が出ます。移行前の基準値と同じ集計方法で比較してください。

最後に、公開と同時に旧処理を削除しないでください。まず新方式の送信、診断、広告反映、営業成果を確認し、戻せる期間を設けます。旧処理を停止する日、停止担当、再開条件、監視期間を決めます。削除は、運用記録と必要なコードの保管を済ませてから行います。

移行後の週次チェックリスト

移行後の最初の4週間は、毎週同じ曜日に件数を照合します。CRMの確定件数、送信対象、API受付、処理成功、Google広告反映、有効商談、受注を一行へ並べます。前週比だけでなく、どの段階の比率が変わったかを見ると、広告の季節変動と連携障害を分けやすくなります。

アラートは、ジョブの失敗だけでなく、送信件数がゼロ、通常より大きく減少、失敗率上昇、最終成功時刻の遅延にも設定します。処理が正常終了しても、抽出条件の変更で対象がゼロならデータは届きません。営業日や月末処理など、件数が自然に変わる日を考慮した閾値にします。

広告担当は、コンバージョンアクションが入札に含まれているか、価値と通貨が意図どおりか、重複がないかを確認します。営業担当は、送信後にステージを修正した成果やキャンセルがどう扱われるかを確認します。訂正が必要な運用なら、修正・再送・除外のルールも決めてください。

Web制作やフォーム改修の際は、クリックIDやユーザー提供データを受け渡す項目が消えていないかを公開前に確認します。フォームの見た目が変わらなくても、hidden項目、Cookie、セッション保存、CRMマッピングが変わることがあります。GA4フォーム送信計測と合わせ、オンラインの成功送信とオフラインの商談成果を一本のテストで追える状態を維持してください。

よくある質問