オフラインコンバージョンとは？媒体別の設定方法を解説

｜広告運用ノウハウ公開中！

より詳しく知りたい方は資料をダウンロード！

　

広告の管理画面に並んでいるコンバージョンが、フォーム送信で止まっていないでしょうか。

電話で決まった契約、来店してから買われた商品、3か月後に受注した案件。売上に近い成果ほど、Webサイトの外で確定します。そこを渡さないまま自動入札を回すと、媒体は「フォームを送る人」を探し続けます。

これを解決するのがオフラインコンバージョンです。ただし入れ方は媒体ごとに違い、しかも「クリックIDを返す」方式と「顧客情報で照合する」方式という、性質の異なる2系統に分かれます。ここを混同したまま設計すると、片方の媒体では動いてもう片方では何も入らない、という状態になります。

この記事では、各媒体の公式ドキュメントに沿って、2つの方式の違い、Google広告・Yahoo!広告・Meta広告・LINE広告それぞれの入れ方、そして「アップロードは成功したのに数値が増えない」ときの切り分けまでを解説します。

　

1. オフラインコンバージョンとは｜Web上で完結しない成果を広告に返す

オフラインコンバージョンとは、Webサイトの外で確定した成果を、あとから広告媒体に取り込んで計測する仕組みです。

電話での申し込み、来店しての購入、商談を経た受注。いずれも広告がきっかけで起きているのに、タグでは検知できません。オフラインコンバージョンは、これらを媒体側の成果として後から数えられるようにします。

通常のコンバージョン計測との違い

通常のコンバージョン計測は、ブラウザに置いたタグが発火した瞬間に成果を記録します。成果の発生と記録が同時です。

オフラインコンバージョンは、この2つが分かれます。広告のクリックは今日、成果の確定は3週間後。その間をまたいで両者を結び直す作業が必要になります。結び直すための材料を、クリックの時点で確保しておかなければならない、というのがこの仕組みの本質です。

渡していない成果は、自動入札には存在しない

導入の目的をレポートの見栄えだと捉えると、優先度を見誤ります。本当の効き所は、自動入札に渡す学習データの中身が変わることです。

媒体のアルゴリズムは、渡されたコンバージョンに似た人を探しにいきます。資料請求までしか渡していなければ、資料請求で終わる人が集まります。受注まで渡して初めて、受注する人に寄っていきます。

リード獲得後の商談化率が媒体・キャンペーンで大きく割れている場合、そのばらつきは媒体側からは見えていません。見えていないものは最適化されません。

効果が出やすいのはこの3パターン

• 広告経由で着電が発生する。電話番号を掲載しているLPでは、フォームより電話のほうが成約率が高いことも珍しくありません
• 来店・実店舗での購入がゴールになる。予約と来店、来店と購入がそれぞれ別のタイミングで確定します
• 問い合わせから受注までに時間がかかる。BtoBや高単価商材で、CRM側にしか受注データがないケースです

逆に、ECサイトのようにWeb上で購入まで完結する場合は、通常のコンバージョン計測で足ります。自社の成果がどこで確定しているかを先に確認してください。確定の場所がサイトの中なら、この記事の設定は必要ありません。

2. 入れ方は2方式｜クリックIDで返すか、顧客情報で照合するか

オフラインコンバージョンの実装は、媒体ごとにバラバラに見えて、大きく2つの方式に分かれます。どちらの方式かで、事前に用意すべきものが根本的に変わります。

クリックID方式：広告クリックの証跡を持ち帰る

広告クリック時に遷移先URLへ自動で付与される固有IDを保存しておき、成果が確定したらそのIDとセットで媒体に返す方式です。Google広告・Yahoo!広告・Microsoft広告がこの方式にあたります。

1. クリック時にIDを受け取る。Google広告なら gclid、Yahoo!広告なら yclid がURLに付きます
2. 成果と一緒に保存する。フォーム送信時に隠しフィールドでIDを取得し、リード情報としてCRMに持たせます
3. 確定したら返す。ID・コンバージョン名・日時・値・通貨をファイルまたはAPIでアップロードします

実務で重いのは3ではなく2です。IDを保存していなければ、後からさかのぼって紐づけることはできません。この方式は「思い立った日から始められない」という点を、導入判断の時点で織り込んでおく必要があります。

顧客情報マッチ方式：メールアドレスや電話番号で照合する

クリックIDの代わりに、ハッシュ化したメールアドレスや電話番号を送り、媒体側のユーザーと突き合わせる方式です。Meta広告やLINE広告のように、アプリ内での接触が中心の媒体はこちらになります。

この方式では、クリックIDを保存していなくても、顧客リストさえあれば後から始められます。一方で、照合できるかどうかは媒体側の登録情報と一致するかに依存します。会社のメールアドレスでフォームを送った人が、プライベートのアドレスでSNSに登録していれば、その成果は結びつきません。

なおこの2つは排他ではありません。Google広告は現在、クリックIDに顧客情報を上乗せする形を推奨しており、両方式のハイブリッドに移行しています（3章で後述します）。

媒体別の識別子と「返せる期間」

設計時にいちばん最初に効くのが、成果が確定してからどれくらいの猶予があるかです。ここが商材のリードタイムより短いと、仕組みを作っても入りません。

媒体	方式	識別子	返せる期間
Google広告	クリックID＋顧客情報	gclid / gbraid / wbraid＋ハッシュ化した顧客情報	Google広告ヘルプの規定による
Yahoo!広告	クリックID	yclid	Yahoo!広告ヘルプの規定による
Microsoft広告	クリックID	msclkid	コンバージョン時刻が過去90日以内
Meta広告	顧客情報マッチ	ハッシュ化したメール・電話番号など	イベント時刻は7日前まで／オフライン取引は62日以内
LINE広告	サーバー送信（コンバージョンAPI）	アクセストークンによる送信	公式マニュアルに期間の記載なし

Meta広告だけ桁が違う点に注意してください。Meta公式ドキュメントは、送信するイベントの時刻について「7日より過去のものがデータに含まれていると、リクエスト全体をエラーとして返す」としています。実店舗などのオフライン取引については62日以内のアップロードが案内されていますが、いずれにせよ90日前提で組んだ運用フローをそのままMetaに流用すると弾かれます。

着手前に決めておく3つのこと

媒体の手順に入る前に、この3つが決まっていないと必ず止まります。

1. 自動タグ設定を有効にする。クリックID方式の媒体では、これがオフのままだとURLにIDが付きません。仕組み自体が動かない前提条件です
2. オフライン用のコンバージョンを別に作る。既存のフォーム送信CVに上書きせず、「商談化」「受注」など段階ごとに作ります。あとで入札の対象を切り替えられるようにしておくためです
3. IDの保存先と引き継ぎ経路を用意する。フォームの隠しフィールドに加え、ページ遷移をまたいでもパラメータが引き継がれるかを確認します。LPから別ドメインのフォームに飛ばしている構成では、ここで欠落します

3つ目は見落とされやすい箇所です。タグは正しく入っているのに、フォームに届いた時点でIDが空になっているという事故は、LPとフォームを別々の会社が作っている場合に起きます。

3. 媒体別の入れ方

ここからは媒体ごとの実装です。Microsoft広告については「Microsoft広告とは？始め方とコンバージョン計測を実務ベースで解説」で扱っているため、この章では割愛します。

先に4媒体の作業の入り口を並べます。作業する画面と、事前に必要な権限が媒体ごとに違います。

媒体	作業する場所	送るデータ	着手前に必要なもの
Google広告	管理画面のアップロード／Google Ads API	GCLID＋ハッシュ化した顧客情報	自動タグ設定の有効化、GCLIDと顧客情報の保存
Yahoo!広告	広告管理ツールのコンバージョンインポート	YCLID＋成果データ	自動タグ設定の有効化、YCLIDの保存
Meta広告	イベントマネージャ（データセット）	ハッシュ化した顧客情報	データセットの用意、顧客情報の取得
LINE広告	ビジネスマネージャー＋自社サーバー	サーバーから送信するイベント	組織の管理者による規約同意、アクセストークン

LINE広告だけ、運用担当者の権限では着手できません。ここを見落とすと、実装の手前で止まります。

Google広告｜GCLIDのインポートから「リードの拡張コンバージョン」へ

Google広告のオフラインコンバージョンは、クリック時に付与される gclid を保存し、成果確定後にアップロードするのが従来の形です。iOSアプリをまたぐ場合は gbraid、アプリからWebに遷移する場合は wbraid が使われます。

作業の流れは3ステップです。

1. 自動タグ設定を有効にする。遷移先URLに gclid が付いた状態を作ります
2. フォーム送信時にGCLIDと顧客情報を保存する。メールアドレス・電話番号を成果と同じレコードに持たせます
3. 成果が確定したらアップロードする。管理画面からのファイル、またはAPI経由で送信します

ただしいま新規に設計するなら、GCLIDだけを返す形をそのまま採用すべきではありません。Google公式ドキュメントは次のように案内しています。

最も正確な測定とパフォーマンスを得るには、顧客のメールアドレスや電話番号などのファーストパーティデータを利用する、更新されたオフライン コンバージョンのインポートである リードの拡張コンバージョン から始める（またはアップグレードする）ことをおすすめします

リードの拡張コンバージョンは、GCLIDに加えてハッシュ化した顧客情報を送る形式です。置き換えではなく上乗せで、GCLIDも可能な限り含めることが推奨されています。送信項目とハッシュ化の要否は次のとおりです。

項目	SHA-256でのハッシュ化
メールアドレス	必要（正規化してからハッシュ化）
電話番号	必要（正規化してからハッシュ化）
氏名（姓・名）	必要
住所（番地など）	必要
国・都道府県・市区町村・郵便番号	不要
GCLID	不要（そのまま送信）

API経由で運用している場合は、期限にも注意が必要です。

2026年6月15日以降、開発者トークンがオフライン コンバージョンのアップロードまたはリードの拡張コンバージョンのアップロードのリクエストを以前に送信していない場合、UploadClickConversion リクエストは失敗します。

この記述はGoogle Ads APIの UploadClickConversion と開発者トークンについてのもので、以降はData Manager APIの利用が案内されています。管理画面からのファイルアップロードが停止するとは書かれていませんが、これから自社ツールやCRMからAPI連携を組む場合は、実装先を確認してから着手してください。

ハッシュ化やタグ側の設定手順は「Google拡張コンバージョンとは？設定方法と効果の出し方を解説」で詳しく解説しています。

Yahoo!広告｜YCLIDでのインポート

Yahoo!広告は「コンバージョンのインポート機能」として提供されています。広告クリック時に遷移先URLへ yclid が付与され、これを成果データと関連付けて広告管理ツールに取り込む流れです。

1. 自動タグ設定を有効にする。URLに yclid が付く状態を作ります
2. フォーム送信時にYCLIDを保存する。CRM側に成果と一緒に持たせます
3. 広告管理ツールからインポートする。YCLIDと成果データを関連付けたファイルを取り込みます

考え方はGoogle広告と同じですが、設定をそのまま移植できると考えないでください。同じところと、Yahoo!広告側で個別に確認が要るところを分けて押さえます。

Google広告と同じ考え方でよい点	Yahoo!広告側で個別に確認する点
自動タグ設定の有効化が前提	ファイル形式と必須項目の名称
クリックIDを成果と一緒に保存する	日時のフォーマット
確定後にファイルで取り込む	対象となる広告の種類と期間の制限

特に日時のフォーマットは媒体ごとに異なり、そろえずに流用するとインポート時にエラーになります。具体的な項目名と手順は、Yahoo!広告ヘルプ「コンバージョンのインポート機能とは」および「コンバージョンデータをインポートする」でご確認ください。

Meta広告｜データセットに顧客情報で照合させる

「Meta広告はオフラインコンバージョンを廃止した」という理解は誤りです。Meta公式ヘルプは現役で、オフラインイベントの受け口も存在しています。変わったのは置き場所で、オフラインイベントはデータセットに紐づける形に整理されました。イベントマネージャからPixel（Webイベント）・アプリイベント・オフラインイベント用のAPI・メッセージイベントをまとめて接続する構成です。

1. イベントマネージャでデータセットを用意する。オフラインイベントの接続先を確認します
2. 送る顧客情報をハッシュ化する。項目ごとにハッシュ化の要否が分かれます（下表）
3. 実店舗の取引はイベントの発生源を実店舗として指定する。オンラインの成果と区別されます
4. 注文IDを付けて送信する。Pixelで取れているCVとの二重計上を防ぎます

ハッシュ化して送る	ハッシュ化しない
メールアドレス／電話番号／氏名／生年月日／所在地	モバイル広告ID（IDFA・GAID）／リードID

重複排除の設計も先に決めておきます。Metaは2通りを用意しており、いずれもウィンドウは最大7日です。

排除の方式	照合に使うもの	ウィンドウ
注文IDによる排除	成果1件ごとの注文ID	最大7日
ユーザー単位の排除	送信した顧客情報	最大7日

Pixelで取れているCVと手動アップロードのCVが二重に計上されるのを防ぐため、注文IDを両方に持たせる設計が扱いやすくなります。

LINE広告｜コンバージョンAPIでサーバーから送る

LINE広告には、他媒体のような管理画面からのCSVインポート機能ではなく、自社サーバーが持つデータを直接送信するLINE Conversion APIが用意されています。ブラウザ側の制限を受けにくく、タグ計測との併用が前提の設計です。

利用開始までの流れは、他媒体と毛色が違います。

1. 組織の管理者がコンバージョンAPIの利用規約に同意する。ビジネスマネージャー上での作業で、運用担当者の権限だけでは進められません
2. アクセストークンを発行し、その場でコピーして保管する。公式マニュアルでは、ページを離れると再表示できないと案内されています
3. 自社サーバーからイベントを送信する。タグ計測と併用する前提で実装します

1と2で止まる案件が多いため、社内で誰が同意し、誰がトークンを受け取るかを先に決めておいてください。なお、来店や後日成約といったオフライン成果をこの経路で送る際の要件は、媒体側の仕様として個別に確認が必要です。

4. 反映されないときの切り分け

オフラインコンバージョンのつまずきは、エラーで止まるものより、エラーが出ないまま数値が増えないもののほうが厄介です。順番に切り分けます。

コンバージョン名が一致していない

アップロードするファイルのコンバージョン名は、管理画面で作成した目標名と完全に一致している必要があります。全角と半角、末尾のスペース、「受注」と「受注CV」の差でも一致しません。

Microsoft広告の公式ドキュメントは、名前が一致しない場合について「オフラインコンバージョン目標データは適用されません」としており、アップロード自体は成功したように見えます。最初に疑うべきはここです。

日時のタイムゾーンがずれている

日時の扱いは媒体ごとに規定が異なります。ここを媒体間で使い回すと、成果が数時間ずれた日付に計上されます。

• Google広告（API）：タイムゾーンを含める必要があり、形式は yyyy-mm-dd HH:mm:ss+|-HH:mm。管理画面のレポートと突き合わせる際はアカウントのタイムゾーンを基準にします
• Microsoft広告：コンバージョン時刻をUTCで指定します。日本時間のまま入れると9時間ずれます

日をまたぐ時間帯の成果が前日に寄っている場合、まずタイムゾーンを疑ってください。件数は合っているのに日別の推移が合わないのが、この不具合の特徴です。

作成直後はアップロードできない

コンバージョン目標を作ってすぐにアップロードすると、媒体側の準備が終わっておらず弾かれます。

Microsoft広告では目標の作成後2時間はアップロードできず、レポートへの反映には最大6時間かかります。Google Ads APIでも、コンバージョンアクションの作成から4〜6時間待つことで TOO_RECENT_CONVERSION_ACTION エラーを回避できるとされています。

設定した当日に検証を終わらせる前提でスケジュールを組まないでください。この待ち時間を知らずに設定を作り直すと、原因の切り分けがさらに難しくなります。

同じ成果を二重に入れてしまった／入れたあとに直したい

運用が始まると、同じファイルを2回上げてしまう事故が起きます。媒体側にも重複対策はあり、Microsoft広告では同じクリックIDとコンバージョン時刻の組み合わせは最初の1件だけが取り込まれます。ただし時刻が1秒でも違えば別の成果として扱われます。

金額の誤りや、後からキャンセルになった案件は、消すのではなく調整で処理します。値を修正する調整（Restatement）と、取り消す調整（Retraction）がGoogle広告・Microsoft広告のいずれにも用意されています。取り消しは削除ではなく「取り消しという記録を送る」操作だと理解しておくと、運用ルールを作りやすくなります。

調整を使う場合、照合のキーは注文IDのほうが安定します。Google公式ドキュメントも、クリックIDと日時の組み合わせより注文IDでの識別を推奨しています。運用を始める前に、成果1件ごとに一意のIDを振っておいてください。

5. LPツール側で発生したCVを媒体に返す

ここまでは、CRMや基幹システムに成果がある前提の話でした。LPツールやASP側でCVが発生している場合も、同じ課題が起きます。媒体のタグはLPツール側のCVを知らないため、放置すると自動入札に何も渡らないまま配信が進みます。

LP作成・改善ツールのSquad beyondには、計測したCVを広告媒体へ返すCVポストバックがあります。Meta広告・Google広告・Yahoo!広告・LINE広告・TikTok・X など、この記事で扱った媒体を含む複数の媒体に対応しています。

運用面で効いてくるのは、返す作業が定期実行になる点です。CVデータのスプレッドシートが自動で更新される仕組みのため、担当者が思い出したときに手作業でアップロードする運用から抜けられます。2章で見た「返せる期間」の制限にも引っかかりにくくなります。

Meta広告のようにピクセル計測と併用する媒体では、重複除外の扱いも設定側で用意されています。ポストバックで返したCVとピクセルで取れたCVが二重に計上されないよう、どちらを正とするかを決めたうえで設定してください。

逆方向の広告連携で配信金額を取り込めば、LP単位で「いくら使って、何件取れたか」が同じ画面に揃います。オフラインコンバージョンで成果の定義を受注寄りに引き上げたあと、その成果をどのLPが生んでいるかまで一気に確認できる状態になります。

｜広告運用ノウハウ公開中！

より詳しく知りたい方は資料をダウンロード！

　

6. オフラインコンバージョンについてよくある質問（FAQ）

7. まとめ

オフラインコンバージョンは、レポートを埋めるための機能ではありません。自動入札に「何を成果と見なすか」を教え直す作業です。

• 入れ方はクリックID方式と顧客情報マッチ方式の2系統。前者はクリック時点でのID保存が必須で、後から始められない
• 返せる期間は媒体で桁が違う。Microsoft広告は90日、Meta広告はイベント時刻が7日前まで・オフライン取引は62日以内
• Google広告は「リードの拡張コンバージョン」への移行が推奨。API経由の実装では2026年6月15日以降の要件も確認する
• Meta広告は廃止されていない。データセットにハッシュ化した顧客情報を送る形に整理されている
• 反映されないときは名前の不一致 → 反映待ち → 日時のずれの順に切り分ける。エラーが出ない失敗があることを前提にする

着手の順番としては、媒体の設定より先にフォームです。クリックIDと顧客情報を成果と一緒に保存できているかを確認してください。ここが埋まっていれば、どの媒体にも後から接続できます。

※本記事の仕様は2026年8月時点で各媒体の公式ドキュメント（Google Ads API、Meta for Developers、LINEヤフー for Business）を確認した内容です。仕様は変更される場合があるため、最新の内容は各公式ページでご確認ください。

　

｜広告運用ノウハウ公開中！

より詳しく知りたい方は資料をダウンロード！