Shopifyの購入手続き画面で購入が計測できない理由と、GTMのまま解決する方法

執筆／葉井貴秋

公開 2026.09.24

#Google Analytics #GTM

Shopifyでは、テーマに通常設置したGTMを、購入手続き画面以降までそのまま動かすことはできません。

商品ページやカートまでは正しく計測できているのに購入完了だけが計測できない。

広告の管理画面を見ると、実際の受注件数よりコンバージョンが明らかに少ない。

こうした場合にGTMの設定を見直しても、間違いは見つかりません。

これは設定ミスではなく、Shopifyの仕様によるものです。実際にいただくご相談も、ほとんどが次の3つに集約されます。

購入手続き画面にタグを入れられず、購入が計測できない
購入手続き画面の前後でセッションが切れて、広告の成果が「ダイレクト」になってしまう
広告媒体の管理画面で、購入コンバージョンが実際より少なく見える

この記事では、なぜこれが起きるのか、公式の解決策であるカスタムピクセルにGTMを入れるだけではなぜ足りないのか、そして月曜日のトラがどう解決しているのかを順に説明します。

購入手続き画面でGTMが動かない理由

購入手続き画面の前後でセッションが途切れている状態と、つながっている状態を比べた図。上段は広告クリックから購入手続き画面の手前で線が切れ、購入完了が別のセッションとして記録される様子、下段は購入完了まで1本の線でつながる様子を示す

Shopifyの購入手続き画面は決済情報を扱うため、テーマ側に設置したGTMがそのまま動作しません。

かつては checkout.liquid や Additional Scripts、Script Tags を使って、Thank youページや注文状況ページに独自の計測コードを設置できました。

しかしShopifyは、これらの旧方式から Checkout Extensibility への移行を進めてきました。

checkout.liquid は、住所・配送・支払いなどの購入手続きステップではすでに非サポートです。Thank youページ・注文状況ページにおける checkout.liquid と Additional Scripts も、旧方式として廃止されています。Script Tags は、Shopify Plus では2025年8月28日に、Plus以外では2026年8月26日に、注文状況ページでの実行が終了しました。

Shopifyがここまで強い制限を敷いたのは、決済ページに任意のスクリプトを入れられる状態が、カード情報窃取などの攻撃の入口になり得たこと、Cookie同意への対応をプラットフォーム側で強制するため、アプリのスクリプトが積み重なって購入手続き画面が遅くなるのを防ぐため、そしてShopify側が購入手続き画面を「壊さずに」改修し続けられるようにするためです。

その結果、現在の仕様は次のとおりです。

項目	現在の仕様
タグの設置手段	checkout.liquid・Additional Scripts・Script Tags は廃止。購入手続き画面の計測は Web Pixels（アプリピクセル／カスタムピクセル）のみ
実行環境	ピクセルは Web Worker / iframe のサンドボックス内で実行。ページ本体のDOMやCookieへの直接アクセスは遮断され、公式APIを経由した限定的なアクセスのみ
URL・デバッグ	ピクセルから見えるURLはサンドボックス内部のもの。GTMプレビュー（Tag Assistant）は動作しない
同意との連動	訪問者の同意ステータスに応じて、イベントの配信自体がプラットフォーム側で自動制御される

Shopify公式の解決策は「カスタムピクセル」

購入手続き画面まで独自の分析・広告計測を行う場合は、ShopifyのWeb Pixelsを使うのが現在の基本的な仕組みです。Web Pixelsには、アプリから提供される App Pixel と、独自コードを実装できる Custom Pixel（カスタムピクセル）があり、GTMもカスタムピクセルの中で動作させることができます。

ただし、カスタムピクセルにGTMのスニペットを貼るだけでは、冒頭の3つの悩みは解決しません。

カスタムピクセルにGTMを入れるだけでは解決しない理由

カスタムピクセルはサンドボックスの中で動くため、通常のページと同じつもりでGTMを置くと、次のことが起きます。

サンドボックスの制約	起きること	冒頭の悩みとの関係
別オリジン扱いのため、GA4が新しいClient IDを発行する	購入手続き画面の前後でユーザー・セッションが分断される	広告の成果が「ダイレクト」になる
媒体のベースタグがサンドボックス内で正しく動かない	購入コンバージョン（CV）が媒体に届かない	媒体の購入CVが少なく見える
ストアフロントとサンドボックスの両方がpage_viewを送る	ページビューが二重に計上される	GA4の数字が合わない
取得できるURLがサンドボックス内部のものになる	計測のページ情報が汚れる	GA4の数字が合わない
標準のCookieアクセスが遮断される	ストアフロントで確立したIDを読めない	セッション分断の原因になる
GTMプレビュー（Tag Assistant）が使えない	何が起きているのかを自分で確かめられない	原因の特定ができない

「カスタムピクセルにGTMを入れたのに、まだ数字が合わない」という場合、原因はほとんどこの表のどこかにあります。

1つのGTMコンテナを2つの実行環境で動かすハイブリッド構成

ストアフロント側と購入手続き画面側の両方を、同じGTMコンテナが覆っている全体像。購入手続き画面側はShopifyが管理する領域であることを破線の枠で示している

月曜日のトラの Shopify GTM計測導入サービス では、1つのGTMコンテナを、テーマ側の通常の実行環境と、購入手続き画面を含むWeb Pixelsのサンドボックスの両方で動かします。コンテナは自分がどちらの環境で動いているかを判定し、役割を出し分けます。

1つのGTMコンテナが、ストアフロント側と購入手続き画面側の2つの実行環境で動く構成図。ストアフロント側がpage_viewを送ってClient ID・セッションIDを確立し、購入手続き画面側がそのIDを引き継いでeコマースイベントを送る関係を示す

どちらの環境で何を扱うかは、次のように切り分けています。

項目	ストアフロント側（テーマ）	購入手続き画面側（サンドボックス）
page_view	こちらだけが送る（全ストアフロントページ）	送らない（二重計上防止）
eコマースイベント	送らない	view_item 〜 purchase をこちらだけが送る
Client ID／セッション	ファーストパーティCookieとして確立（発生源）	確立済みIDを読み取り・明示指定（新規発行を抑止）
媒体ベースタグ	トップフレームで正常動作	置かない（誤動作するため）

先ほどの制約には、それぞれ次のように対応しています。

購入手続き画面側の制約	本構成での対応
標準のCookieアクセスが遮断される	公式に提供される読み取り経路へ切り替え、GA4のIDを取得
取得できるURLがサンドボックス内部のものになる	トップフレーム側の正規URLを参照するよう統一
GA4が新しいClient IDを発行し、セッションが分断される	確立済みIDをイベント送信時に明示指定。 Shop Pay などのクロスドメイン遷移には、IDを注文に同伴させる引き継ぎ設計で対応
GTMプレビューが使えない	GA4 DebugView・実購入テスト・検証チェックリストによる検証プロセスで代替

Shopify GTM計測導入サービスを導入すると何が変わるか

観点	導入前	導入後
購入の計測	購入手続き画面にタグを設置できない	購入完了を含む一連のeコマースイベントをGTMで計測
広告成果	広告経由の購入が「ダイレクト」になってしまう	広告クリックから購入までの識別情報を可能な範囲で引き継ぎ、流入元別の売上やROASをより正確に把握できる
媒体CV	管理画面のCVが実際より少ない	購入CVが媒体に届き、自動入札の学習が回る
タグ管理	媒体追加のたびに開発・改修を依頼	購入手続き画面を含む全ページをGTMで一元管理

1. 購入が計測できるようになる

購入手続き開始から購入完了まで、GA4のeコマース標準に沿ったイベントを計測します。購入完了には、注文ID・金額・商品明細・クーポン・割引が付きます。

2. 広告の成果が「ダイレクト」になりにくくなる

広告クリックから購入完了までを、1人のユーザー・1つのセッションとしてつなぐ設計にしています。

参照元が「ダイレクト」や「不明」になりにくくなり、流入元別の売上・ROASがより正確に出る
GA4のユーザー数・セッション数が二重にならない

3. 媒体の管理画面に購入CVが届く

購入完了を各広告媒体のCVとして計測できる状態を作ります。クリックIDの引き継ぎに加え、拡張コンバージョン／CAPI用のハッシュ化済みデータの下準備まで行います。

対応する広告媒体6種(Google広告・Meta・X・Yahoo!広告・Microsoft広告・Criteo)を並べた図。いずれもクリックIDの引き継ぎに対応していることを示す

対応媒体は Google広告／Meta／X／Yahoo!広告／Microsoft広告／Criteo の6種です。媒体の管理画面で購入CVが正しく見えるようになると、自動入札の学習が回り、広告の費用対効果が改善しやすくなります。

さらに：以後のタグ運用がGTMだけで完結する

ストア側への設置（計測基盤の組み込み）は導入時の1回のみ
以後のタグの追加・変更・停止はGTM管理画面だけで完結
広告媒体の追加もGTM上の操作だけで、ストア側の追加開発は不要
既存のGTMコンテナ・タグ・トリガー・運用ノウハウをそのまま流用できる
特定の計測アプリへのロックインなし・月額費用なし

Shopify GTM計測導入サービスで計測できるイベント

タイミング	計測内容
商品を見る	商品一覧表示／商品詳細表示（view_item_list / view_item）
カート	カート追加／カート削除／カート表示（add_to_cart / remove_from_cart / view_cart）
購入手続き	購入手続き開始／配送情報入力／支払い情報入力（begin_checkout / add_shipping_info / add_payment_info）
購入	購入完了（purchase。注文ID・金額・商品明細・クーポン・割引つき）
行動補足	購入手続き画面内のクリック・フォーム送信（カスタム計測）

あわせて、精度と安全のための機能を標準で備えています。

二重計上防止 — ページビューやイベントが重複しない構成で設計し、納品前の検証で確認
広告向けの純額売上 — 送料・税を除いた商品純額でコンバージョン値を送信（ROAS計算に適した値）
個人情報の保護 — GA4に個人情報（メール・住所等）が送られない構成を、チェックリストで検証

Shopify購入手続き画面側の処理フロー（詳細）

ここからは少しマニアックな話になるので、興味のある方はご覧ください。

ストアフロント側では、テーマに組み込んだGTMが page_view の送信と同時に GA4 の Client ID・セッションIDをファーストパーティCookieとして確立し、そのIDを注文情報に同伴させる下準備までを担います。購入手続き画面側では、次の順序で処理します。

計測スクリプトが、GTM読み込みより前に実行環境フラグを宣言します。コンテナは、自分がサンドボックス側で動いていることを初期化時点から判定できます
確立済みの Client ID・セッションIDを、2つの経路から復元します。注文に同伴させたID（優先。クロスドメイン対応）と、公式経路でのCookie読み取りです
GA4の設定処理は、初期化時ではなく最初のeコマースイベント到達後まで遅延実行します。IDが揃った状態で設定を打つことで、GA4による新規ID発行（＝セッション分断）を防ぎます
このとき page_view は送らない設定に切り替えます。ストアフロント側の送信と衝突せず、二重計上が構成上起きません
各イベントは、設定処理の先行実行を保証する順序制御の上で送信し、イベント間で購買データが持ち越されないよう毎回リセットします

purchase イベントは、送料・税を除いた純額のコンバージョン値、注文レベル割引、正規化＋SHA-256ハッシュ済みユーザーデータ、主要媒体のクリックID類（存在するもののみ・独自永続化なし）まで拡充した状態で納品します。

タグ・トリガー・変数の具体的な構成、キー名、コードは本記事には掲載していません。詳細をお知りになりたい方はお問い合わせください。その際にご説明いたします。