【完全ガイド】Google広告のオフラインコンバージョンインポートのやり方

「広告→問い合わせ（or来店）→受注」の間にオフラインの成果が挟まると、オンラインだけの計測では真のCPAやLTVが見えません。
オフラインコンバージョンインポート（OCI）は、CRMやPOSの成約データをGoogle広告へ戻し、入札とレポートに反映させる仕組みです。本記事は最新の実務フローに沿って、GCLID/GBRAID/WBRAIDでのクリック連動型と、拡張コンバージョン for リード（ECL）による個人情報ハッシュ照合型の両輪で、初期設定→日次運用→高度な品質管理まで“迷いなく”進められるよう、テンプレート・チェックリスト・エラー対処を網羅した決定版です。
リンクは挿入せず、この記事だけで完結できるように書いています。

1. オフラインコンバージョンの2方式：どちらを使うべきか
1. A. クリック連動型（GCLID/GBRAID/WBRAID）
2. B. 拡張コンバージョン for リード（ECL）
2. 事前準備（必須）
3. クリック連動型（GCLID/GBRAID/WBRAID）でのインポート手順
4. 拡張コンバージョン for リード（ECL）でのインポート手順
5. データ仕様（実務で詰まりやすいポイント）
6. よくあるエラーと解決チェックシート
7. 日次運用テンプレ（頻度・SLA・QA）
8. 効果最大化テクニック
9. 付録
まとめ

1. オフラインコンバージョンの2方式：どちらを使うべきか

A. クリック連動型（GCLID/GBRAID/WBRAID）

仕組み：広告クリック時に付与されるID（GCLID/GBRAID/WBRAID）をフォーム送信時に取得→CRMへ保存→成約時にIDと成約情報をGoogle広告へインポート。
適合ケース：Webフォーム起点、問い合わせ→商談→受注のBtoB/BtoCリード獲得、iOSを含むクロスデバイス流入。
強み：クリックと成果が直接ひも付くためマッチ率が高い。
注意：IDの保管とデータ保持期限（一般に90日以内目安）を厳守。

B. 拡張コンバージョン for リード（ECL）

仕組み：ユーザーのハッシュ化したファーストパーティ情報（メール、電話、住所等）で照合し、コンバージョンを帰属。
適合ケース：GCLID等を取りづらい/欠損が多い、複数接点（電話、対面）や長期検討、iOS比率が高い商材。
強み：ID欠損に強く、照合カバレッジを拡大。
注意：SHA-256での前処理（正規化→ハッシュ）、同意取得、プライバシー運用の厳格化が必須。

実務ではAを主軸に、欠損補完としてBを併用する「ハイブリッド構成」が定石です。

2. 事前準備（必須）

コンバージョンアクションの設計
- 最終目標（受注/成約/来店売上）と、中間指標（MQL、SQL、初回訪問など）を分けて定義。
- スマート入札に反映させる対象（“コンバージョンに含める”）は、まずは受注などビジネス価値の高い指標から。
ID/個人情報の取得体制
- GCLID/GBRAID/WBRAIDをフォームのhiddenに埋め込み→CRM保存。
- ECL併用ならメール/電話/氏名/住所のうち照合できる項目をフォーム→CRMで正規化して保持。
データガバナンス
- 時刻はアカウントのタイムゾーン（例：Asia/Tokyo）で統一。
- 通貨はアカウント通貨（例：JPY）。
- Order ID（外部ID）で重複排除・再計上の制御を可能に。

3. クリック連動型（GCLID/GBRAID/WBRAID）でのインポート手順

Step 1. 設置 & 保管

LP/フォームにクリックID格納用hiddenを設置
- 例：gclid, wbraid, gBraid をCookie/URLから取得→hiddenへ格納
送信時、CRMのリード/取引テーブルに以下を保存
- click_id（GCLID/GBRAID/WBRAIDのいずれか）
- lead_time（問い合わせ日時）
- deal_time（成約日時）
- value（税込/税抜の扱いを決めて統一）
- currency（例：JPY）
- order_id（外部の一意ID）

Step 2. Google広告側の準備

コンバージョンアクションを作成（タイプ：インポート/オフライン → クリック経由）
値の扱い：案件ごとに動的値（成約金額）を渡す場合は「値を使用する」を選択。
帰属期間/計測設定をビジネスに合わせて設定。

Step 3. ファイル作成（CSV/Sheets）

最小列（例）

Google Click ID, Conversion Name, Conversion Time, Conversion Value, Conversion Currency, Order ID

Google Click ID：GCLID/GBRAID/WBRAIDのいずれか
Conversion Name：Google広告のコンバージョンアクション名と完全一致
Conversion Time：YYYY-MM-DD hh:mm:ss（アカウントTZ）
Conversion Value：数値（例：120000）
Conversion Currency：JPY など
Order ID：重複排除用の外部一意ID

Step 4. インポート（UI/自動化）

UI：コンバージョン→インポート→ファイルを選択→プレビュー→アップロード。
自動化：Google広告API or スプレッドシート連携で日次/時間単位にバッチ投入。
検証：初回はサンプル10件でプレビュー→取り込み結果（成功/警告/エラー）を確認。

4. 拡張コンバージョン for リード（ECL）でのインポート手順

Step 1. 取得 & 正規化

フォームで取得したメール/電話/氏名/住所を正規化
- メール：前後空白削除→小文字化
- 電話：国番号付きで数字のみ（ハイフン削除）
- 氏名：全角/半角統一、不要スペース除去
- 住所：都道府県→市区町村→番地→建物の順で正規化

Step 2. ハッシュ化（SHA-256）

すべて正規化後にSHA-256でハッシュ化（ソルトなし）
ハッシュ値のみをCSVへ出力（生データは保持・アクセス権を厳格管理）

最小列（例）

Email, Phone, First Name, Last Name, Country, Postal Code, Conversion Name, Conversion Time, Conversion Value, Conversion Currency, Order ID

個人情報列はハッシュ済みを格納。使える列だけでOK（複数入れるとマッチ率向上）。
CountryはJPなどのISOコード。Postal Codeは数字のみ推奨。

Step 3. アクション紐づけ & アップロード

コンバージョンアクションはリードのオフラインインポート/ECL対応で作成。
CSV/Sheetsでアップロード→プレビュー→反映。
GCLIDがない案件もECLで帰属が可能になり、カバレッジが拡大。

5. データ仕様（実務で詰まりやすいポイント）

タイムゾーン：アカウントTZで統一。異なるTZならISO8601のオフセット付きで明示。
通貨：アカウント通貨（例：JPY）。混在はNG。
保持期限：クリックからのインポート期限は目安90日以内を厳守（長期検討はECLで補完）。
重複排除：Order IDを必ず付与。二重登録は自動拒否/上書き。
部分返金/キャンセル：コンバージョン調整（Restatement/Retraction）で再アップロード。
- 参照キー：Order ID（推奨）またはClick ID + Conversion Time
- 調整値は正/負どちらも可（返金は減額）。

6. よくあるエラーと解決チェックシート

(1) 「Conversion Nameが一致しない」

余計なスペース/全角半角/大文字小文字の差異を除去。
管理画面の名称と完全一致で再出力。

(2) 「Click IDの無効/期限切れ」

保存漏れ：フォーム→CRMのhidden保存ログを点検。
期限超過：ECLで補完または連携頻度を短縮（毎日→毎時）。

(3) 「時刻/通貨が不正」

TZを統一（Asia/Tokyo）。フォーマットをYYYY-MM-DD hh:mm:ssに固定。
通貨列を欠かさず、数値は.小数点で。

(4) 「重複インポート」

Order IDを必須化。
アップロード前に当日分のCSVをIDでユニーク化。

(5) 「ハッシュ形式が不正（ECL）」

正規化→SHA-256。メールは小文字、電話は数字のみ。
ハッシュ済みかをダブルチェック（生値で出していないか）。

7. 日次運用テンプレ（頻度・SLA・QA）

頻度設計（推奨）

最低：毎日 1回（営業時間後）
重要商材/高CVR：毎時または3時間ごと
調整/キャンセル：発生当日処理

SLA

CRM登録→インポートまで24時間以内
エラー率<1%で安定運用

QAチェック（毎日/毎週）

成功件数・警告・エラー件数の推移
マッチ率（クリック連動 vs ECL）
キャンペーン別CPA/ROASの改善度
入札戦略の学習状態（制限/学習中の解消速度）

8. 効果最大化テクニック

価値連動（Value-based Bidding）
- 受注金額や見込粗利をConversion Valueとして送る。高価値案件に入札を寄せる。
二段階コンバージョン
- MQL/SQL/受注の3階層を別アクションで持ち、学習初期は中間CVも“含める”→安定後は受注重視に絞る。
調整で真価を反映
- キャンセル/返金/Upsellを調整インポートで反映し、ROASやtROASの学習を淀みなく。
ハイブリッド帰属
- クリックID主軸 + ECL補完でマッチ率と偏りを同時に改善。iOSや長期検討に強くなる。
除外の設計
- 社内テスト/重複リード/取引NGリストはOrder IDベースで除外。学習を汚さない。

9. 付録

9-1. クリック連動型：CSVひな形

Google Click ID,Conversion Name,Conversion Time,Conversion Value,Conversion Currency,Order ID
EAIaIQobChMIabcdEFg,受注,2025-09-18 16:30:00,120000,JPY,ORD-20250918-0001

9-2. ECL：CSVひな形（ハッシュ済み）

Email,Phone,First Name,Last Name,Country,Postal Code,Conversion Name,Conversion Time,Conversion Value,Conversion Currency,Order ID
<sha256_email>,<sha256_phone>,<sha256_fname>,<sha256_lname>,JP,1500001,受注,2025-09-18 16:30:00,120000,JPY,ORD-20250918-0001

9-3. Apps ScriptでのSHA-256ハッシュ（例）

function sha256Normalized(str) {
  if (str == null) return '';
  const normalized = String(str).trim().toLowerCase();
  const digest = Utilities.computeDigest(Utilities.DigestAlgorithm.SHA_256, normalized);
  return digest.map(b => ('0' + (b & 0xff).toString(16)).slice(-2)).join('');
}