カゴ落ち対策の前に「どこで離脱したか」を確定する｜Shopify・BASE・カラーミーショップの購入ファネル計測と切り分け台帳
ON THIS PAGE▼
カゴ落ちの原因分析では、先に「対策」を選ばないことが重要です。商品説明を変える、送料無料の条件を変える、決済を追加する、リマインドメールを送るといった施策は、購入ファネルのどこに問題があるかによって優先順位が変わります。
たとえば、商品ページからカートに入る割合が低い状態で、チェックアウト用の施策だけを増やしても、検証対象となる注文候補が増えません。反対に、カートからチェックアウトへ進んでいるにもかかわらず購入完了が少ないなら、商品ページの改修だけでは解決しない可能性があります。
本記事では、カゴ落ちを一つの率として扱わず、次の4区分に分けます。仕様・画面構成によって観測できない区間を、推測で埋めないための設計です。確認日：2026年9月11日。
- 商品閲覧後、カートに入らない
- カート投入後、チェックアウトに到達しない
- チェックアウト到達後、購入完了しない
- 実際には進んでいるが、計測イベントが欠損・重複している
まず「カゴ落ち」の範囲を3区間に分ける
GA4では、購入行動の確認にadd_to_cart、begin_checkout、purchaseを使えます。ただし、GA4のeコマースデータは自動ですべて収集されるものではなく、必要なイベントを送信して初めて取得されます。イベント名を設定しているだけで、各画面から期待どおり送信されているとは限りません。
分析の単位は、可能なら同じセッションを連続して通過したかでそろえます。add_to_cartの総イベント数は、同一セッションで複数商品をカートに入れた場合にも増えます。そのため、add_to_cartイベント数とpurchaseイベント数をそのまま割って「カゴ落ち率」とするのは、実務上は避けたほうが安全です。
確認したいのは、少なくとも以下の3区間です。
| 区間 | 確認する行動 | 主な判断 |
|---|---|---|
| 商品閲覧→カート投入 | 商品詳細を見た後にadd_to_cartしたか | 商品情報、価格、バリエーション選択、在庫表示、購入導線を点検する |
| カート投入→チェックアウト到達 | add_to_cart後にbegin_checkoutしたか | 送料・配送条件の見え方、カート画面、クーポン、購入ボタンを点検する |
| チェックアウト到達→購入完了 | begin_checkout後にpurchaseしたか | 決済、配送先入力、エラー、認証、注文完了計測を点検する |
率を出す場合は、分母と分子の対象期間、対象チャネル、除外条件を台帳に記録します。たとえば「カート投入セッションのうちチェックアウト到達セッション」のように、分子・分母の定義を文章で残します。期間比較をする際も、広告配信、在庫切れ、価格改定、送料改定、テーマ変更を同じ表で確認できるようにしておくと、数字だけで原因を断定しにくくなります。
カゴ投入後の離脱だけをカゴ落ちと呼ぶ運用でも構いません。ただし改善の優先順位を決める資料では、商品閲覧からカートに入らない区間を別に置くと、商品ページの課題と購入手続きの課題を混ぜずに済みます。
計測前に決める、ファネルの比較単位と対象条件
最初に、レポート間で一致しないことを「異常」と決めつけないための基準を作ります。Shopifyの標準レポートはセッションを基礎にした購入ファネルを示します。一方、GA4でイベント数を見ると、同じ利用者・同じセッション内の複数回操作が反映され得ます。ShopifyとGA4の数字を比べるなら、同じ値になることではなく、各ツールが何を数えているかを確認してください。
台帳に固定する項目
分析を始める前に、以下を1行目に記録します。
- 集計期間とタイムゾーン
- 対象ストア、対象ドメイン、対象通貨
- 対象チャネル（全体、広告別、自然検索別など）
- 除外するアクセス（社内IP、テスト注文、開発環境など）
- 比較単位（セッション、ユーザー、GA4イベント数）
- カート・チェックアウトの方式、テーマ・アプリの変更日
- 計測の確認担当者と確認日
チャネル別に見る際は、流入元ごとに購入意図が異なる点にも注意が必要です。広告、メール、再訪問では商品閲覧からの進み方が違うことがあります。全チャネルを合算した値だけで商品ページや決済の問題と決めず、まず同一チャネル内で区間別の変化を見ます。
3区間の算式は、分母を一つ前の段階に置く
セッション単位で取得できる場合の基本形は次のとおりです。
カート投入到達率 = カート投入セッション ÷ 商品詳細閲覧セッション
チェックアウト到達率 = チェックアウト到達セッション ÷ カート投入セッション
購入完了率 = 購入完了セッション ÷ チェックアウト到達セッション
ここで大切なのは、率の高低だけでは原因を確定しないことです。たとえばチェックアウト到達率が変わった日には、送料無料条件、クーポン表示、カートアプリ、在庫・販売条件の変更がなかったかを照合します。購入完了率が急に変化した場合は、先にpurchaseの欠損や重複、注文管理画面の実注文との不整合を確認します。
GA4はイベントの有無をテスト注文で先に検証する
GA4の通常レポートや探索への反映には、最大24時間かかる場合があります。改善施策の開始直後に標準レポートだけを見て、イベントが壊れた・効果が出たと判断しないでください。設定確認にはDebugViewを使い、公開環境でテスト操作を行います。
最低限のテストシナリオ
本番ストアでテスト注文を許容できる手段を確認したうえで、次の操作を1件ずつ実施します。テスト用の商品、時刻、ブラウザ、操作担当者を控えます。
- 商品詳細ページを開く
- 商品を1点だけカートに追加する
- カート画面を開き、チェックアウトへ進む
- 購入完了まで進められる場合は完了する
- GA4 DebugViewで
add_to_cart、begin_checkout、purchaseの順序と発火回数を確認する - 後からGA4のレポート・探索と注文管理画面を確認し、テスト注文として除外できるようにする
合格条件は「3イベントが見える」だけではありません。期待した画面遷移で、各イベントが一度ずつ発火し、購入完了イベントがテスト注文に対応していることまで確認します。商品を追加していないのにadd_to_cartが出る、チェックアウトに進んでいないのにbegin_checkoutが出る、購入後に画面更新するとpurchaseが重複する、といった状態では、ファネルを施策判断に使えません。
購入完了までテストできない場合は、どの地点まで確認済みかを台帳に残します。この場合、チェックアウト到達後の離脱を決済や入力フォームの問題と断定せず、「購入完了イベントは未検証」として扱います。
Shopify・BASE・カラーミーショップで先に確認する仕様
プラットフォームごとに、カート・レジ画面へどのタグが反映されるかは異なります。商品ページで見えるタグを根拠に、チェックアウトまで同じように計測できると考えないでください。
Shopify：標準の行動レポートとGA4を役割分担する
Shopifyの行動レポートでは、全セッション、カート追加セッション、チェックアウト到達セッション、購入完了セッションから購入ファネルを確認できます。閉じたファネルでは、段階を順番どおりに通過したセッションだけが後続段階に計上されます。
まずはShopifyの行動レポートで、ストア全体のどの区間が落ちているかを確認し、GA4では流入元、ランディングページ、デバイスなどの切り口を補う、という分担が実務的です。
ただし、Shopifyの当該レポートにはBuy Buttonやサードパーティアプリ経由の一部データが含まれません。購入導線にこれらを使っている場合、レポートの数字をストア全体の完全な実績とみなさず、含まれない導線を台帳に明記します。
BASE：GA4タグとカスタムタグを混同しない
BASEのHTMLタグ管理 Appでは、GA4タグをショップごとに1つ設定でき、カート画面を含む全ページのheadへ反映されます。一方、カスタムタグはカート・レジ画面には反映されません。
したがって、カート以降の行動を測る目的でカスタムタグだけを追加する設計は避けます。また、同じタグを複数の経路で入れると、正確な計測を妨げる場合があります。すでにテーマ、外部タグ管理、HTMLタグ管理 AppのいずれかからGA4タグを入れているなら、追加前に設置箇所を棚卸ししてください。
確認順は次のとおりです。
- HTMLタグ管理 AppでGA4タグの設定有無を確認する
- テーマや外部ツールにも同じGA4タグがないか確認する
- 商品詳細、カート、レジの各画面でテスト操作を行う
- DebugViewでイベントの重複・欠損を確認する
カラーミーショップ：プランとカート種別を確認してから設定する
カラーミーショップのGA4対応は、利用中のプランとショッピングカートの条件を確認して進めます。公式ヘルプでは、レギュラー、ラージ、プラチナ、プレミアムプランで新しいショッピングカートを利用する場合のeコマース設定が案内されています。
このため、設定担当者へ「カラーミーショップだからGA4計測できる」とだけ伝えるのでは不十分です。管理画面で現在のプラン、利用中のカート種別、公式の設定対象に該当するかを確認し、該当しない場合は同じファネルを無理に比較しません。カート切替やプラン変更には表示・決済・周辺連携への影響確認が必要になるため、計測だけを目的に先行させず、移行コストと改善判断への必要性を分けて検討します。
数字を見た後の購入ファネル切り分け台帳
計測が確認できたら、率を見てすぐ実装に進まず、仮説・確認画面・変更影響を一枚にまとめます。以下の形式をスプレッドシートなどで使えます。
| 判定区分 | 先に確認する証拠 | 点検候補 | 変更時の注意 | 次の判断 |
|---|---|---|---|---|
| 商品閲覧→カート投入が弱い | 商品詳細閲覧とadd_to_cart、商品別・流入別の差 | 価格、送料の事前表示、在庫、バリエーション、商品説明、購入ボタン | テーマ改修は表示崩れや計測タグへの影響を確認 | 商品詳細のテストを優先する |
| カート→チェックアウトが弱い | add_to_cart後のbegin_checkout、カート画面の操作確認 | 送料・配送条件、クーポン欄、カート内の価格表示、チェックアウト導線 | 送料無料・値引きは粗利、配送条件、既存施策との整合を確認 | カート画面の確認と条件表示の見直し |
| チェックアウト→購入が弱い | begin_checkout後のpurchase、実注文、テスト操作 | 決済手段、配送先入力、エラー表示、認証、必須項目 | 決済・配送の変更は運用、契約、顧客案内への影響を確認 | 計測検証後に決済・入力導線を点検 |
| イベント欠損・重複の疑い | DebugView、テスト注文、注文管理画面 | タグ二重設置、発火条件、購入完了ページの実装 | 計測修正とUI変更を同時に行わない | 先に計測を直し、比較可能な期間を作る |
台帳には、各行に「変更しない理由」も残してください。たとえば、送料を変更しない理由が粗利への影響であれば、施策を放置したのではなく、判断材料を確認したうえで保留にした記録になります。
施策を始める条件と、いったん止める条件
カゴ落ち対策を始める条件は、特定区間の数字が低いことだけではありません。少なくとも、対象画面でイベントが取れていること、重複していないこと、比較する期間とチャネルがそろっていることを確認します。そのうえで、一度に変更する要素を絞ります。
たとえばカート画面の改善を検証するなら、同じ期間に送料無料条件、クーポン、決済、テーマをまとめて変更しないほうが、結果の解釈がしやすくなります。注文数が少なく、短期間の率が大きく動く場合も、単日の数値で決めず、確認期間をあらかじめ決めます。
反対に、次の場合は施策より計測・運用確認を優先します。
- テストで
purchaseが確認できない、または重複する - GA4と注文管理画面の対象範囲がそろっていない
- BASEでカスタムタグにカート・レジ計測を任せようとしている
- カラーミーショップでプラン・カート種別を確認していない
- ShopifyでBuy Buttonや外部アプリ経由の購入を、標準レポートの対象外と認識していない
カゴ落ち原因分析の成果は、施策の数ではなく、「次に変えるべき画面」と「今は変えない理由」を説明できる状態を作ることです。まず計測の範囲を確定し、商品詳細、カート、チェックアウト、計測不備のどれを扱うかを分けてから、変更の影響を比較できる形で進めてください。
参考情報
この課題、もっと詳しく相談したい方へ
記事では答えきれない個別の状況にもお応えします。