注文管理画面には購入があるのに、Google Adsのコンバージョンだけ少ない。
最短の解決策は、Safariのせいと決めつけず、注文と広告レポートの口径をそろえ、Google tag、クリック情報、同意状態、取引IDの順に確認することです。実機のMacは再現性のあるSafari環境として役立ちますが、タグ設定やコンプライアンス設定の代わりにはなりません。
この記事を読むべき担当者
Google Adsの広告運用担当者は、計測漏れを理由に予算や入札を誤って変更しないために利用してください。独立サイトの運営責任者は、注文照合とSafari回帰確認の受け入れ条件を作るために役立ちます。
技術協力担当者は、注文番号を手掛かりに、タグ、リダイレクト、同意管理、重複送信のどこへ調査を渡すべきか判断できます。
最初に分けるべき「注文数」と「コンバージョン数」
注文数とGoogle Adsのコンバージョン数は、同じ日付範囲を指定しただけでは一致しません。タイムゾーン、広告経由の判定、注文の確定条件、コンバージョンアクション、重複除外、レポートへの反映状態が異なるためです。
| 確認対象 | 注文側で記録する項目 | Google Ads側で照合する項目 |
|---|---|---|
| 時間 | 注文作成時刻、確定時刻、店舗のタイムゾーン | レポート期間、アカウントのタイムゾーン |
| 識別子 | 注文番号、金額、通貨、注文状態 | 取引ID、コンバージョンアクション、値 |
| 流入 | ランディングページ、広告クリック情報の有無 | キャンペーン、広告グループ、コンバージョン列 |
| 状態 | 決済成功、保留、キャンセル、返金 | 主要または補助のコンバージョン設定 |
Google Adsでは、主要コンバージョンが入札や「コンバージョン」列に使われ、補助の設定は扱いが異なります。列の意味はアカウント設定に依存するため、コンバージョン列と主要コンバージョンの公式説明を確認し、注文件数との差をそのまま「漏れ」と呼ばないでください。
証拠表を先に作る
最初から全注文を調べる必要はありません。広告経由と判断できる注文を数件選び、次の項目を伏せ字で記録します。
- 注文番号と注文状態
- 注文確認ページへ到達した時刻
- 使用したSafariの環境
- 広告の最終URLとランディングページ
- クリック情報がランディングページに残ったか
- Google tag、購入イベント、取引IDの送信結果
- Google Adsで対象にしたコンバージョンアクション
この表で「イベント未送信」「送信したが識別子不足」「送信済みだが別のアクション」「まだ処理中」を分けます。注文数からコンバージョン数を単純に引く方法では、複数の問題が一つに見えてしまいます。
どの症状から調べるか
Safariの注文確認ページで購入イベントが出ない場合
商品ページと決済ページにGoogle tagが存在していても、注文確認ページで購入イベントが実行されるとは限りません。ページのソースにタグ文字列があるかではなく、実際の画面遷移でタグが読み込まれ、購入イベントが送信されたかを確認します。
Google Tag Managerを使っている場合は、Tag Assistantの公式手順でプレビュー接続を行い、注文確認ページで発火条件、イベント名、金額、通貨、取引IDを確認します。SafariのWeb Inspectorでは、コンソールのエラーとネットワーク要求を同じテスト注文に結び付けて記録してください。
ここでの停止条件は明確です。購入イベントが発火していないなら、広告管理画面の設定を先に変更せず、注文確認ページのテンプレート、決済後のリダイレクト、同意管理の実行順を担当者へ戻します。
クリック情報が途中で消える場合
広告からの遷移が次のような構成になると、クリック情報がどの段階で失われたかを確認する必要があります。
| 経路上の地点 | 見るべき異常 | 担当する確認 |
|---|---|---|
| 広告の最終URL | 自動タグ設定やURLパラメータの扱いが想定と違う | 広告運用 |
| ランディングページ | リダイレクト後にクリック情報が残らない | フロントエンド |
| 地域振り分け | 国別URLや言語URLへ移動した際に情報が消える | サイト運用・開発 |
| 決済ドメイン | 別ドメインへの移動後に計測経路が切れる | 決済・開発 |
| 注文確認ページ | 購入イベントに広告との関連情報が渡らない | 計測担当・開発 |
Google Adsの自動タグ設定は、広告クリックに関する識別情報をランディングページへ渡す仕組みです。まず自動タグ設定とGCLIDの公式説明に沿って、広告URL、リダイレクト、保存処理を確認してください。
別ドメインの決済を使う場合は、実際の購入経路にConversion Linkerとクロスドメイン設定が適用されているかを見ます。ブラウザーの保護機能を回避したり、存在しないクリック情報を作ったりする手順ではありません。計測できない情報を補うために、広告流入を偽装することは検証にも運用にも使えません。
同意状態によって結果が変わる場合
同意管理を導入した後にSafariの注文だけが減ったなら、許可した場合、拒否した場合、まだ選択していない場合を分けて再現します。各状態でタグが読み込まれるか、どの同意シグナルが送られるか、購入イベントがどの条件で制限されるかを記録してください。
Consent Modeは同意状態を計測システムへ伝える仕組みであり、ユーザーの選択を無視して全注文を復元する機能ではありません。enhanced conversionsも、正しく設定されたデータを補助的に利用する仕組みで、すべてのSafari計測差異を埋める保証ではありません。Google Tag ManagerのConsent Mode説明と自社の同意管理サービスの実行順を確認し、地域ごとの法的判断は担当する法務またはコンプライアンス部門に委ねてください。
注意：Safariの追跡防止があるから一定割合で必ず漏れる、という結論は出せません。Webサイトの保存方法、リダイレクト、同意状態、タグ実装によって観測される症状は変わります。Safariの仕様境界はWebKitの追跡防止に関する説明で確認してください。
第一歩から始める実務チェックリスト
次の順番で、一つのテスト注文を最後まで追跡します。各項目で証拠が取れなければ、次へ進まず担当を分けてください。
- [ ] 注文番号、注文時刻、確定状態、通貨、注文金額を記録する
- [ ] 店舗とGoogle Adsでタイムゾーンと比較期間をそろえる
- [ ] 注文が広告経由か、別流入かを確認する
- [ ] 広告の最終URLからランディングページまでの遷移を保存する
- [ ] リダイレクト後のURLでクリック情報が維持されているか確認する
- [ ] 商品ページ、決済ページ、注文確認ページのGoogle tagを確認する
- [ ] Safari Web Inspectorで購入イベントの要求とコンソールエラーを記録する
- [ ] Google Tag ManagerまたはTag Assistantで発火条件とパラメータを確認する
- [ ] 同意を許可、拒否、未選択に分けて結果を比較する
- [ ] Conversion Linkerが実際の決済経路を対象にしているか確認する
- [ ] 取引IDが注文システムから動的に生成され、再読み込みで重複しないことを確認する
- [ ] Google AdsのコンバージョンID、ラベル、アクション、データソースを照合する
- [ ] GA4インポートとGoogle Adsタグを二重に数えていないか確認する
- [ ] 修正後に同じ経路を再実行し、公開、継続観察、ロールバックのいずれかを記録する
Google Adsの管理画面で状態が変わらない場合、タグが動いたかだけで判断しないでください。対象アクション、データの送信先、主要設定、アカウントの所属を確認し、コンバージョン設定の公式手順と照合します。
取引IDと重複送信を切り分ける
イベントが複数回送られている場合は、注文確認ページの再読み込み、戻る操作、決済会社からの再遷移、タグの二重配置を確認します。取引IDが固定値や空欄だと、同一注文の再送信を正しく扱えない可能性があります。
一方、Google AdsとGA4の数値が異なるだけで、直ちに重複とは言えません。両者はイベントや帰属、レポート列の定義が異なるためです。取引IDによる重複除外の公式説明と注文IDを使ったコンバージョン調整の説明を確認し、同じ注文番号を使って送信、処理、帰属を区別します。
実機MacでSafariを再現する方法
Windows上の別ブラウザーで問題が再現しない場合、実際のSafariを使った買い手側の再テストが必要です。ただし、再テストの目的は「Macなら計測が完全になる」と証明することではなく、担当者が同じ条件を再現して証拠を残すことです。
- テスト専用のSafariユーザー環境を用意し、過去のCookieやサイトデータが混ざらない状態にします。
- 既存顧客セッションを想定した環境も別に用意し、新規訪問と再訪問を分けます。
- 同じ広告入口、ランディングページ、地域振り分け、決済経路を順に通過します。
- 同意を許可、拒否、未選択に分け、各状態でイベントとネットワーク要求を保存します。
- 注文確認ページの表示時刻、注文番号、取引ID、コンソール、ネットワーク記録を一つにまとめます。
- Google Adsの対象アクションと店舗注文を後から照合し、送信前、送信後、処理後のどこで差が出たかを記録します。
- macOSとSafariのバージョン、接続拠点、テスト日時を残し、同じ条件で再実行できるようにします。
既存チームにMacがなく、Safariの広告注文を継続的に確認する必要がある場合は、KVMFLUXの海外Mac環境のような、作業期間に合わせて利用できる環境を候補にできます。料金や利用条件は、テスト頻度と保持したい環境の期間を整理したうえで料金案内を確認してください。
よくある切り分け
Safariで支払いが完了しても記録されない理由
支払い成功と購入イベント送信は別の処理です。決済が完了しても注文確認ページへ戻れない、購入イベントの条件に一致しない、同意状態によりタグが制限される、クリック情報が途中で失われると、Google Ads側のコンバージョンが作られないことがあります。
注文数よりGoogle Adsが少ない場合の判断
まず広告経由の注文だけを抽出し、同一タイムゾーン、同じ注文確定条件、同じコンバージョンアクションで比較します。差が残ったら注文番号ごとに未送信、パラメータ不足、別アクション、重複除外、未処理へ分類してください。
クロスドメイン決済で確認すること
決済ドメインへの遷移前後でURLと保存情報を記録し、地域振り分けや中間ページがクリック情報を削除していないかを確認します。注文確認ページが別ドメインにある場合は、実際の経路に合わせてConversion Linkerとクロスドメイン設定を検証します。
Google tagが動いたのに状態が変わらない場合
タグの発火だけでは、正しいGoogle Adsアクションへの送信やレポート計上まで確認できません。ID、ラベル、アクション、データソース、主要設定、GA4インポート、アカウントを一つのテスト注文で追跡します。
Macでの再テストを合格にする条件
Macで注文できたことだけを合格条件にせず、広告入口から注文確認、タグ要求、同意状態、取引ID、管理画面上の対象アクションまで記録できることを条件にします。再現できない場合は、環境情報やテスト日時が不足していないかを先に確認します。
Google Adsの集計差をSafariだけで説明しようとすると、タグ未発火、クリック情報の欠落、同意設定、重複除外を見落とします。現在の環境がWindows中心で、担当者ごとに異なる一時的な端末を使っているなら、同じSafari状態を保てず、修正前後の比較や再発確認にも手間がかかります。
先に計測設定と注文口径を整えたうえで、一定期間だけ保持できる実機Mac環境を用意すると、広告入口から注文確認までの再テストをチームで共有しやすくなります。長期的な高負荷処理や物理機器への接続が必要なら自社Macのほうが適しますが、Safariの広告注文を案件単位で検証する用途なら、KVMFLUXの利用方法を確認し、必要な期間だけMac環境を確保する選択肢があります。