Shopifyのチェックアウト拡張機能のイベントをGA4×BigQueryで分析する

はじめに：チェックアウト過程が見えないという悩み

「Shopifyの売上は管理画面で見えるのに、購入直前にどこで離脱しているのかがわからない」。EC運営をしていると、この壁に必ずぶつかります。

Shopify管理画面のアナリティクスでは、訪問数やコンバージョン率といった集計値は確認できます。しかし、チェックアウトの中、つまり「カートに入れた人のうち何割が住所入力まで進んだのか」「支払い情報の入力で何人が脱落したのか」といった、ステップ単位の歩留まりまでは追い切れません。

ここが見えないままだと、改善の打ち手が「とりあえず送料を見直す」「ボタンの色を変える」といった当てずっぽうになりがちです。逆に、どのステップで何%が落ちているのかが数字でわかれば、優先順位は一気に明確になります。

本記事では、Shopifyのチェックアウト拡張機能（Checkout Extensibility）に対応した正規の計測経路であるカスタムピクセル（Customer Events）から、チェックアウト系イベントをGA4へ送り、最終的にBigQueryでファネルを分析するところまでの設計を解説します。

本記事で扱うShopifyの管理画面メニュー名・イベント名・スキーマ、およびGA4のエクスポート仕様は変更されることがあります。実装時は必ず最新の公式ドキュメント（Shopify Help Center / shopify.dev / GA4ヘルプ）で名称と仕様を確認してください。

Shopifyのチェックアウト拡張機能と計測の関係

かつてのShopifyでは、checkout.liquid や注文ステータスページの「Additional scripts」に計測コードを直接書き込めました。しかしCheckout Extensibility（チェックアウト拡張機能）への移行に伴い、これらの方法は順次廃止されています。

チェックアウト拡張機能は、決済まわりのカスタマイズをLiquidの直接編集ではなく、Shopifyが用意した安全な仕組みの上で行う方向への転換です。決済ページの安全性とパフォーマンスを守るための変更であり、任意のスクリプトをチェックアウトのHTMLへ差し込むことは基本的にできません。

そのため、チェックアウト過程を計測したい場合は、Shopifyが提供する正規のイベント経路を使うことになります。それがカスタムピクセル（Customer Events）です。

Customer Events（チェックアウト系イベント）の中身

カスタムピクセルは、Shopifyの「設定 → カスタマーイベント（Customer events）」から追加できる、独自のJavaScriptを安全に動かす仕組みです。ストア本体とは隔離されたサンドボックス内で動作し、analytics.subscribe を通じてShopifyが発行するイベントを購読します。

Shopifyが標準で発行するイベント（Standard events）のうち、チェックアウトの歩留まりを見るうえで重要なのは次のあたりです。

product_added_to_cart … カート追加
checkout_started … チェックアウト開始
checkout_shipping_info_submitted … 配送情報の入力完了
payment_info_submitted … 支払い情報の入力完了
checkout_completed … 購入完了（GA4の purchase に対応）

この一連のイベントを並べると、そのままチェックアウトのファネルになります。「開始 → 配送情報 → 支払い情報 → 完了」という流れの各段で人数を数えれば、どこで離脱が起きているかが見えるわけです。

各イベントには checkout オブジェクトなどのデータが付いており、注文金額・通貨・商品情報・チェックアウトを識別するトークンなどを取り出せます。ただし取得できるフィールドの正確な構造は更新されることがあるため、実装前に標準イベントのスキーマを公式ドキュメントで確認してください。

イベントを購読する

カスタムピクセル内では、次のように必要なイベントを購読します。サンドボックスである点に注意し、受け取ったデータは自前でGA4側へ転送する設計にします。

// Customer events（カスタムピクセル）内
const events = [
  "checkout_started",
  "checkout_shipping_info_submitted",
  "payment_info_submitted",
  "checkout_completed",
];

events.forEach((name) => {
  analytics.subscribe(name, (event) => {
    const checkout = event.data?.checkout;
    sendToGa4(name, {
      checkout_token: checkout?.token,
      value: checkout?.totalPrice?.amount,
      currency: checkout?.currencyCode,
    });
  });
});

checkout_token のように、同一チェックアウトを通して一貫する識別子を一緒に送っておくと、後段のBigQueryでステップ間をつなげて分析しやすくなります。

GA4へ送る設計

カスタムピクセルはサンドボックスのため、ストア本体に入れたGA4タグやGTMコンテナとはメモリ空間が別です。したがって「ピクセル内で受け取ったイベントを、ピクセル内から直接GA4へ送る」という形にします。

送り方は大きく2通りあります。

ピクセル内にGTMコンテナを読み込み、dataLayer 経由でGA4へ送る
Measurement Protocol などを使い、サーバー側または計測エンドポイント経由でGA4へ送る

どちらの場合も、ファネル分析のために意識したいのは「イベント名とパラメータの設計を、後から集計しやすい形にそろえておく」ことです。具体的には次の方針が扱いやすいです。

チェックアウトの各ステップを、判別しやすい一貫したイベント名でGA4へ送る
checkout_token（または同等の識別子）をイベントパラメータとして必ず付与する
金額は value、通貨は currency として送り、purchase のみ受注として扱う

GA4とBigQueryをリンクしておけば、これらのイベントは日次（または必要に応じてストリーミング）でBigQueryへエクスポートされます。あとはSQLでファネルを組み立てるだけです。

GA4へカスタムイベントやカスタムパラメータを送る際は、GA4側でカスタムディメンションとして登録しておかないと、レポートやBigQueryでの扱いに制約が出る場合があります。送信前にパラメータ名を決め、命名を統一しておくことをおすすめします。

BigQueryで各ステップの離脱・完了を分析する

ここからが本題です。GA4のBigQueryエクスポート（events_* テーブル）には、event_name とネストされた event_params が入っています。チェックアウト系イベントを横に並べ、各ステップに到達したセッション（またはチェックアウト単位）の数を数えれば、ファネルが描けます。

まず、チェックアウトを識別するパラメータを取り出す例です。

-- 各チェックアウトが到達した最終ステップを判定する
WITH checkout_events AS (
  SELECT
    (SELECT value.string_value
       FROM UNNEST(event_params)
      WHERE key = 'checkout_token') AS checkout_token,
    event_name,
    event_timestamp
  FROM `your_project.analytics_XXXXXXXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20260831'
    AND event_name IN (
      'checkout_started',
      'checkout_shipping_info_submitted',
      'payment_info_submitted',
      'purchase'
    )
)

SELECT
  checkout_token,
  MAX(IF(event_name = 'checkout_started', 1, 0))                     AS step_started,
  MAX(IF(event_name = 'checkout_shipping_info_submitted', 1, 0))     AS step_shipping,
  MAX(IF(event_name = 'payment_info_submitted', 1, 0))              AS step_payment,
  MAX(IF(event_name = 'purchase', 1, 0))                            AS step_completed
FROM checkout_events
WHERE checkout_token IS NOT NULL
GROUP BY checkout_token

チェックアウト単位でフラグを立てたら、ステップごとの到達数と歩留まりを集計します。

-- ステップ別の到達数と完了率を集計する
WITH per_checkout AS (
  -- 上のクエリの結果をそのまま利用する想定
  SELECT * FROM `your_project.your_dataset.checkout_steps`
)

SELECT
  COUNTIF(step_started = 1)   AS started,
  COUNTIF(step_shipping = 1)  AS shipping,
  COUNTIF(step_payment = 1)   AS payment,
  COUNTIF(step_completed = 1) AS completed,
  SAFE_DIVIDE(COUNTIF(step_shipping = 1),  COUNTIF(step_started = 1))  AS rate_to_shipping,
  SAFE_DIVIDE(COUNTIF(step_payment = 1),   COUNTIF(step_shipping = 1)) AS rate_to_payment,
  SAFE_DIVIDE(COUNTIF(step_completed = 1), COUNTIF(step_payment = 1))  AS rate_to_completed
FROM per_checkout

このように rate_to_shipping や rate_to_payment を並べると、「開始から配送情報入力まで」「支払い情報入力から完了まで」のどこが弱いのかが一目でわかります。たとえば支払い情報入力から完了への率が極端に低ければ、決済手段の選択肢や手数料表示まわりを疑う、といった具合に仮説を絞れます。

さらに離脱面を深掘りするなら、「あるステップに到達したのに次に進まなかったチェックアウト」を抽出して、デバイスや流入元と掛け合わせる分析も有効です。

-- 支払い情報まで進んだのに完了しなかったチェックアウトを抽出する
SELECT checkout_token
FROM `your_project.your_dataset.checkout_steps`
WHERE step_payment = 1
  AND step_completed = 0

ここで得たトークンを、流入チャネルや端末などのディメンションと結合すれば、「スマホの特定チャネルで支払い直前の離脱が多い」といった具体的な発見につながります。

取得できるイベントやその付帯データ（スキーマ）、そしてどのイベントまで利用できるかは、Shopifyのプランや設定、さらにバージョンによって異なります。上記のSQLはあくまで設計の型です。実際のパラメータ名やイベント名は、必ず自分のGA4エクスポートテーブルの中身と最新の公式ドキュメントで確認してから組んでください。

まとめ

Shopifyのチェックアウト拡張機能への移行で、チェックアウトに直接スクリプトを差し込む計測はできなくなりました。代わりに使うのが、正規経路であるカスタムピクセル（Customer Events）です。

checkout_started から checkout_completed までのチェックアウト系イベントをGA4へ送り、BigQueryへエクスポートして横に並べれば、これまで管理画面では見えなかったステップ単位の歩留まりが数字で見えるようになります。どのステップで離脱が起きているかがわかれば、改善の優先順位は当てずっぽうではなくなります。

実装にあたっては、イベント名とパラメータの命名を最初にそろえておくこと、そして取得できるイベント・スキーマはプランや最新仕様に依存するため必ず公式ドキュメントで確認することが、後段の分析をスムーズにするコツです。

カスタムピクセルからGTM/GA4へ高精度に送る実装の詳細は Shopify×GTM×GA4でカスタムピクセルを使った高精度eコマース計測を実装するを、GTMを使ったeコマース計測の全体像は ShopifyのeコマースをGTM×GA4で計測する基本を、それぞれ参照してください。