ShopifyでGA4・Google広告の購入計測を変更後に検証する｜欠損・二重計上を広告改善前に止めるテスト注文台帳

テーマ更新、アプリ追加、Customer eventsの設定変更、同意バナーの切り替えをした直後は、広告予算や入札戦略を変える前に購入計測を確認します。この順番が必要なのは、購入が送られていない「欠損」と、同じ購入が複数回送られる「二重計上」では、取るべき対応が反対になるためです。

たとえば欠損した状態でCPAだけを見ると、広告の成果を過小評価するおそれがあります。一方、二重計上した状態で自動入札に購入を渡すと、実際より多いコンバージョンを学習させることになります。

ここで目指すのは、Shopify、GA4、Google広告の売上額や件数を完全一致させることではありません。計測対象、同意、アトリビューション、集計時刻が異なるためです。変更後に確認すべき合格条件は、テストした同一注文について、必要なイベントが、意図した送信元から、意図した回数だけ送られたことです。

調査資料の確認時点は2026年8月27日です。画面名や機能は変更される場合があるため、作業時にはリンク先の公式資料も確認してください。

最初に決める：照合基準と「異常」の定義

計測検証では、Shopify管理画面の注文を事実確認の起点にします。ただし、これはShopifyの注文数をGA4やGoogle広告へそのまま転記する、という意味ではありません。

1件のテスト注文ごとに、少なくとも次を記録します。

GA4のWebデータストリームでは、同じtransaction_idを持つpurchaseイベントを重複排除する仕組みがあります。ただし、これは「実装上の重複を放置してよい」という意味ではありません。Googleは、transaction_idを注文ごとに一意にし、空文字にしないよう案内しています。送信元が複数残れば、GA4以外のツールやGoogle広告側を含め、調査しにくい構成になります。

次の状態は、媒体間の差異ではなく、公開前に止めるべき異常として扱います。

• Shopifyで成立したテスト注文に対応するpurchaseがGA4 DebugViewで確認できない
• 同じテスト注文に対し、異なるtransaction_idで複数のpurchaseが送られる
• Google & YouTubeアプリを使う構成なのに、テーマ、追加スクリプト、カスタムピクセルなど別経路から同じGoogleタグが発火する
• 同意設定上は送信を待つ想定なのに、同意前に対象ピクセルが送信される、または同意後も送信されない

一方で、Google広告の管理画面で見えるコンバージョン件数とShopify注文数の差だけでは異常と判断しません。広告クリックへの帰属条件や計測対象が異なるためです。まず注文単位の発火を確認し、その後に媒体レポートの差を用途別に説明できる状態にします。

変更前後の送信元を棚卸しする

検証を始める前に、「どこが何を送っているか」を1枚にします。ここを飛ばすと、テストでイベントが見つかっても、それが意図した実装によるものか判定できません。

Shopifyの公式資料では、手動ピクセルから移行した後に差異があれば、イベントが期待どおり発火するか、実装ロジック、イベントが1回だけ追跡されているか、プライバシー設定と同意取得を確認するよう案内しています。テーマ、アプリ、Customer eventsに以前の実装が残っていないかを確認する工程です。

送信元台帳の項目

Google & YouTubeアプリでGA4またはGoogle広告の計測を設定する場合、Googleはストアフロントやカスタムピクセルに重複するタグがないかを確認し、移行後は旧タグを削除するよう案内しています。

ここでの注意点は、「テーマ内にGoogleタグらしいコードがない」だけで完了にしないことです。確認対象には、次も含めます。

• Shopify管理画面のCustomer eventsにあるカスタムピクセルとアプリピクセル
• テーマのレイアウト、注文状況ページ関連の既存設定、追加スクリプト
• タグ管理ツールを読み込むコードと、その配下のGA4・Google広告タグ
• 導入中アプリの計測設定
• Google & YouTubeアプリの接続先Googleタグ、GA4プロパティ、広告アカウント

削除が難しい既存実装は、いきなり本番で消さず、ステージングテーマや公開時間帯、切り戻し方法を含めて変更単位を分けます。計測を直す変更と、テーマの大規模改修を同時に行うほど、原因の特定コストは上がります。

テスト注文は「同意あり・なし」と導線で分ける

1回のテスト注文だけで「計測できた」と結論づけないようにします。最低限、変更内容に応じて同意状態と購入導線を分け、結果を台帳に残します。

Shopify Pixel Helperでは、カスタムピクセルが受信したイベントをリアルタイムで確認できます。Shopifyは商品閲覧、カート追加、チェックアウト開始、配送情報入力、チェックアウト完了までをテスト対象として案内しており、同意待ち状態や同意同期の不具合も確認対象です。

テストケースの作り方

決済手段やテスト注文の可否はストアの契約・設定に依存します。実購入を避ける必要がある場合は、ストアで利用可能なテスト方法を先に確認してください。注文をキャンセル・返金した場合も、台帳には「テスト注文」「キャンセル等の後処理」を残します。購入計測の検証と、返金イベントまでの要件確認は別作業として扱うと混乱を減らせます。

3つの確認画面で、イベントと送信元を突き合わせる

ブラウザの発火、Shopifyの受信、GA4の受信は、同じ画面では確認できません。役割を分けて確認します。

Shopify Pixel Helper：Customer events側の受信を確認する

Shopify Pixel Helperを開き、テスト導線を進めます。カスタムピクセルを使っている場合は、イベントの受信状況をリアルタイムで見ます。

確認する項目は次のとおりです。

• 商品閲覧からチェックアウト完了まで、期待したイベントが順に表示されるか
• 同じ操作で同じイベントが繰り返し出ていないか
• ピクセルが同意待ちになっていないか、同意後に状態が変わるか
• エラーや警告が表示されていないか

これはShopify側のイベント確認です。GA4やGoogle広告への送信結果まで、Pixel Helperだけで合格にしません。

Google Tag Assistant：Googleタグの重複発火を確認する

Google & YouTubeアプリを利用する構成では、Google Tag Assistantでテスト購入を確認します。Googleの案内でも、アプリ以外からタグが発火していないこと、ストアフロントまたはカスタムピクセルとの重複がないことを確認対象としています。

特に確認したいのは、購入完了時に複数のGoogleタグや複数のpurchase送信経路が見つからないかです。見つかった場合は、タグIDだけでなく、そのタグを読み込んだ送信元を送信元台帳へ戻って特定します。「同じIDだから問題ない」とは判断せず、意図した実装が1つかを確認します。

GA4 DebugView：purchaseの内容を注文単位で確認する

GA4のDebugViewで、テスト操作中のイベントを確認します。GA4の公式資料では、ECイベントのリアルタイム検証にDebugViewを使え、通常レポートへの反映には最大24時間かかる場合があると案内されています。そのため、公開直後に通常レポートだけを見て欠損と結論づけないようにします。

purchaseを開き、少なくとも以下を台帳へ転記または証跡として保存します。

• イベント名がpurchaseであること
• transaction_idが空ではなく、当該テスト注文に対応づけられること
• valueとcurrencyが意図した値であること
• 商品情報が必要な粒度で渡っていること
• 同一のテスト注文について、同じまたは異なるtransaction_idの購入イベントが複数ないこと

Shopifyの注文番号とGA4のtransaction_idが必ず同一の文字列になるかは、採用している実装に依存します。文字列の一致を前提にせず、テスト時点では両方の値を台帳に記録し、「どの注文に対応するイベントか」を人が追える状態にします。

テスト注文台帳で欠損と二重計上を切り分ける

検証結果をチャットや口頭だけで残すと、数週間後に広告数値の変化が起きた際、どの変更が原因か追えません。変更ごと・テスト注文ごとに、次のような台帳を残します。

欠損時の確認順

1. Shopifyでテスト注文が成立しているかを確認する
2. Shopify Pixel Helperで、チェックアウト完了までのイベント受信と同意状態を確認する
3. Google Tag Assistantで、Googleタグが発火しているか、ブロックされていないかを確認する
4. GA4 DebugViewでpurchaseと必須パラメータを確認する
5. 送信元台帳に戻り、テーマ・アプリ・カスタムピクセル・同意設定のうち、変更した箇所を比較する

二重計上時の確認順

1. 同じShopify注文に紐づくpurchaseの回数とtransaction_idを確認する
2. 注文完了ページの再読み込みや再訪で再送していないかを確認する
3. Google & YouTubeアプリ、テーマコード、カスタムピクセル、タグ管理ツール、アプリの送信元を照合する
4. 正とする送信元を決め、旧実装を削除または無効化する
5. 新しいブラウザセッションで同じテストを再実施し、修正前後の証跡を残す

GA4の重複排除に期待して広告判断を進めるのではなく、重複を発生させた実装を取り除くのが基本です。GoogleもGoogle & YouTubeアプリへの移行後、重複タグを削除し、テスト購入で確認するよう案内しています。

Google広告の主要コンバージョンを切り替える公開基準

Google広告の購入コンバージョンを主要コンバージョンにすると、その値は入札やレポート上の重要な判断に使われます。したがって、設定画面でコンバージョンアクションが作成できたことだけを公開基準にしません。

Google & YouTubeアプリ経由のGoogle広告コンバージョン設定について、GoogleはTag Assistantでの検証、重複タグ確認、旧タグの削除を行い、新しいコンバージョンを主要コンバージョンに設定する前に確認するよう案内しています。

公開判定は、次のチェックをすべて満たしてから行います。

• 変更内容、公開日時、送信元の一覧が台帳にある
• 同意ありのテスト注文で、Shopify注文、Pixel Helper、Tag Assistant、GA4 DebugViewの結果を保存している
• 必要な場合、同意なしの挙動も自社の設定どおりであることを確認している
• 同じ注文の再読み込み・再訪で、意図しないpurchase再送がない
• 旧テーマコード、旧タグ、旧カスタムピクセルなど、重複経路を削除または停止した
• GA4のtransaction_idが空でなく、注文単位で追跡できる
• Google広告で主要コンバージョンにする対象と、残す補助コンバージョンの役割を決めた
• 不具合時の切り戻し手順と担当者を記録した

この確認を通過した後に、広告予算、目標CPA、入札戦略、クリエイティブの評価へ進みます。計測変更の直後は、通常レポート反映の時間差も考慮し、テストのリアルタイム証跡と後続レポートを分けて保管すると判断根拠が明確になります。

参考情報

• Shopify Help Center：Migrating pixels
• Shopify Help Center：Testing custom pixels
• Google Analytics Help：Shopify: Set up your Google tag
• Google Analytics Help：Remove duplicate tags after migrating to the Google & YouTube app on Shopify
• Google Analytics Help：Set up ecommerce events
• Google Analytics Help：Minimize duplicate key events with transaction IDs
• Google Ads Help：Set up conversion tracking with the Google & YouTube app on Shopify