集客・購入改善

ECのカゴ落ち原因を診断|チェックアウト離脱の改善手順

記事確認日:

当サイトは広告・アフィリエイトを利用しています。広告掲載について

常温の布小物を20商品ほど扱い、店主1人で運営する国内のオンラインストアを想定します。週に確保できる見直し時間は2時間、今回の改修予算は2万円程度という架空の店舗です。カートに商品は入るものの、そこから先の注文がなかなか伸びない場面を考えます。

こうしたとき、割引クーポンを配ったり購入を促すメールをむやみに送ったりする前に、同じ期間のアクセス記録と実際の注文履歴を見比べます。画面上で「そもそも買えない状態」や「案内のずれ」が起きていないかを点検することが大切です。自店の原因を決めつけず、代表的な1商品を基準にして、どの順番で確認していけばよいかを整理します。

どこからどこまでを、カゴ落ちと数える?

カゴ落ちを調べるときは、まず集計の「期間」「始点と終点」「数値の単位(ユーザー数など)」、そして「開いた経路(オープン)か閉じた経路(クローズド)か」を決めて確認します。

Google アナリティクス 4(GA4)の標準的な購入経路レポートは、session_start(セッション開始)から商品表示、カート追加、購入手続き開始、購入までの5段階を起こした「ユーザー数」を数える経路です。訪問回数(セッション数)や注文件数そのものではなく、各段階を踏んだ人の数を表します。GA4の購入経路は通常、指定順に通った人のみを数える閉じた経路(クローズド)ですが、途中から入った人を含める開いた経路(オープン)へ切り替えることも可能です。

一方、決済情報入力など自店で細かな離脱地点を見たい場合は、GA4 eコマースデータのイベント設定を用いて探索機能で個別に経路を設計します(原因が不明な際はユーザビリティテストも推奨されています)。今回提示する表は、標準の5段階そのものではなく、自店の確認用に組んだ架空の経路です。

例えば、架空の布小物店において、同じ期間の閉じた経路で2,000ユーザーの動きを追った仮の例は次の通りです。

横にスクロールして表全体を確認できます。
段階 到達ユーザー数 前段からの通過率
session_start(セッション開始) 2,000 ―
カート追加 200 10%
購入手続き開始 100 50%
決済情報入力 60 60%
購入完了 30 50%

この表の減少数は、指定した順序で次の段階へ進まなかったユーザーを示したものであり、別の経路や別端末で後から注文した人も含まれ得るため、そのまま実際の未購入者数とは断定できません。すべてのECサイトで同じ順序に画面が遷移するとは限らないため、自店の実際の画面と計測タグの送信条件を照らし合わせて確認します。

架空の同じ期間の閉じた経路で、セッション開始2000ユーザーからカート追加200ユーザーへ10%が進んだ例。図の比例棒はカート追加以降を示し、200人、購入手続き開始100人、決済情報入力60人、購入完了30人。前段からの通過率は順に50%、60%、50%。棒の長さは人数に比例。自店用に組んだ経路でGA4標準購入経路そのものではない。数えているのは人で、注文件数ではない。減少した人が全員未購入とは限らず、注文・決済記録との照合が必要。

数字の離脱は、実際の未購入と一致する?

アクセス解析上の離脱人数と、実際のショップにおける未成立の注文数は必ずしも一致しません。そのため、分析ツールの数値だけでなく、同じ期間の実際の受注記録や支払状態と突き合わせて確認します。

数値に食い違いがある場合、お客さまの心変わりを推測する前に、計測データの送信状態や決済エラーの有無を優先して調べます。GA4側ではpurchaseイベントの送信状態、取引ID(transaction_id)、対象期間を確認し、ショップの管理画面側では注文IDと支払状態を確認します。なお、支払状態の「オーソリ(入金ではなくカード利用枠を押さえた段階)」は入金済みとは異なるため区別して扱います。また、ユーザー数は注文件数とは別の単位です。あわせて、1人が複数回注文した正常な取引と、同じ取引IDが重複送信されたケースを切り分けて整理します(1人1注文は後述の試算上の仮定です)。

Shopifyを利用している場合は、注文管理画面の「チェックアウト離脱」一覧や、各注文の注文タイムラインを確認することで、決済処理のログやエラーの詳細を追跡できます(Shopify決済トラブルシューティング)。新しい離脱管理画面でも、タイムラインから決済イベントの詳細を確認する手順が案内されています(Shopifyチェックアウト離脱移行ガイド)。

主要な決済サービスが有効化されていないと、支払い受付不能のエラーが発生します(Shopify決済トラブルシューティング)。外部決済側の接続設定やテストモードの切り替え忘れも含め、注文記録と照合して事実を確認します。

送料・納期・入力・決済で、買えない所はない?

離脱の原因を推測する前に、そもそも注文手続きが完了できない設定になっていないか、あるいは商品ページの案内と購入画面の条件に食い違いがないかを点検します。確認箇所を広げすぎず、「送料」「納期・在庫」「入力エラー」「決済手段」の4点に絞って実際の画面で確かめます。

Shopify決済トラブルシューティングで案内されている通り、購入手続き画面で送料が正常に計算・表示されない場合、購入者は次の決済段階へ進めなくなります。送料の金額以前に、そもそも送料が表示されず先へ進めない状態になっていないかを、実際の住所条件で画面を開いて確認します。

架空の布小物店であれば、代表的な布ポーチ1商品を選び、国内配送における3つの住所パターンを想定してテストします。

  1. 通常の配送先住所(標準送料が適用される地域)
  2. 離島や遠隔地など、追加送料が設定されている地域
  3. 店舗として配送を受け付けていない「配送対象外地域(店が配送を受け付けない地域)」

これらは架空の試験条件ですが、入力した際に送料が意図通りに表示されるか、配送不可の案内が正しく出るかを確かめます。もし送料が表示されない場合、単なる設定漏れなのか、意図した対象外地域なのかを配送プロファイルと照合します。あわせて、パソコンとスマートフォンの両方の実機で画面を開き、在庫や発送目安の記載に食い違いがないか、住所や郵便番号の入力時に不自然なエラーが出ないか、注文確定ボタンが押しやすい位置にあるかを目視で点検します。

購入者と同じ操作を、安全に試せる?

購入経路の動作をテストする際は、実際の決済請求や外部倉庫への出荷依頼が進んでしまわないよう、自店に適した検証環境や方法を選び、外部連携への影響を公式手順に沿って確認します。

Shopifyでは、有料プラン(2026年10月時点)を選択しているストアであれば、自店で有効な決済方式に応じて「Shopifyテスト決済ゲートウェイ(Bogus Gateway)」や「Shopify Paymentsのテストモード」を利用した公式の試験手順を選べます(Shopifyテスト注文ヘルプ、Shopify Paymentsテスト手順)。これらの模擬注文では実際の請求は確定せず、売上レポートや支払い管理画面にも反映されません。

ただし、Shopify Paymentsのテストモード中であっても、Apple PayやGoogle Payなどのエクスプレス決済ではチェックアウトが完了する場合があり、すべての注文が自動で止まるわけではありません。そのため公式ヘルプでも、本番稼働中のストアで有効にしないよう案内されています。休止枠や告知を設けたとしても公式条件を満たすわけではないため、自店が利用可能な検証環境や公式の手順を確認することが大切です。なお、実際の決済を行って後から返金するテスト方法もありますが、決済手数料等の費用が戻らない場合もあるため、今回の確認では模擬注文の手順を選ぶことを提案します。

テストを進める際の確認点は次の通りです。

  • テスト注文はフルフィルメント(発送処理)を行わない(配送ラベルを購入すると課金が生じるため)。
  • 自動出荷(自動フルフィルメント)アプリを利用している場合は、テスト注文の作成前にアプリを停止し、再開手順や停止中のデータ処理も確認しておく。
  • お客さま、店舗担当者、倉庫、外部連携アプリへの通知や自動処理について、各サービスの公式手順に沿ってテスト除外や保留の条件を確認する。
  • テスト専用のメールアドレスと、試験用の代表商品・テスト用住所を用意して確認する。
  • テスト終了後は速やかにテストモードを解除し、通常通りの決済画面に戻っていることを確認する。

最初に直す一つは、どう選べばいい?

離脱人数が最も多い場所だからといって、いきなり大きな改修を行ったり、予算をすべて投入したりする必要はありません。実際に自分で操作して再現できた不具合や案内の食い違いの中から、手持ちの工数で確実に修正できるものを1つ選びます。

原因を数字の大きさだけで判断し、粗利益の試算がないまま全品送料無料化や大幅な値引きを行うと採算を崩す原因になります。週2時間と追加予算2万円という条件なら、「商品ページと購入画面の送料説明を、実際の配送設定と一致させる」といった、表示の食い違いを正す作業が現実的な候補になります。

ここで、前述の架空店の数値をもとに仮の感度計算を行ってみます。なお、通過率55%という数値は感度を見るための仮定に過ぎず、改修による効果を保証するものではありません。

決済情報入力に進んだ60人のうち購入に至った人が30人(通過率50%)だった段階において、仮に通過率が5ポイント改善して55%になったとします。

  • 改善後の仮の購入者数:60人 × 55% = 33人(1人1注文と仮定して+3注文)
  • 平均客単価5,000円と仮定した場合の売上増:3注文 × 5,000円 = 15,000円

この15,000円は、今回の追加改修予算(2万円)や、商品の仕入れ・製造原価、決済手数料、配送料、梱包資材費、作業人件費、固定費、各種税金を差し引く前の売上増の試算であり、利益ではありません。

回収メールは、何を確認してから使う?

購入手続きを途中でやめたお客さまに向けたカゴ落ち回収メール(購入再開案内)は、購入経路の不具合や案内の矛盾を点検・解消した上で、配信条件や対象者を正しく把握してから活用します。

Shopifyでは、Shopify Messagingのマーケティングオートメーションにおいて、「商品閲覧後」「カート追加後(購入手続き前)」「購入手続き開始後(未注文)」という3つの異なる離脱段階に応じた配信機能が分かれています。

チェックアウト離脱に対する新しいオートメーション機能では、次の仕様を確認しておきます(Shopifyチェックアウト離脱移行ガイド)。

  • 対象チャネルは「オンラインストア」および「購入ボタン」経由の離脱に限定され、POSやShopアプリ、外部連携チャネルからの離脱には送信されません。
  • 通常の宛先設定では「メールマーケティングの配信に同意している登録者」が送信対象となります。利用中のオートメーションで宛先設定、配信資格、未配信理由を確認します。
  • 未配信となる条件として、過去に購入履歴がない未登録者である場合、メール送信前に既に別の注文を完了した場合、カート内の商品が在庫切れで購入不可になった場合、あるいは決済不正リスクによりブロックされた場合などが定められています。
  • アプリから最近のアクティビティや実行結果を確認できますが、離脱一覧には一部ボットによる試行が含まれる場合があり、3か月を超えた離脱データは自動的に削除されます。
  • 過去の旧機能(Shopifyレガシー離脱ヘルプ)では「10分経過後に離脱と判定する」といった固定ルールが案内されていましたが、これはレガシー機能専用の設定です。新しいオートメーションへ一度オプトイン(移行)すると、旧機能へ戻すことはできません。

架空の布小物店で導入を検討する場合も、全チャネルや全離脱者に届くわけではない点に留意し、代表商品の布ポーチでテスト配信を行います。記載された復帰リンクが正しいカート画面を開くか、割引条件が正しく反映されるか、在庫が連動しているかを専用のテストアドレス宛てに送信して確認します。

変更の効果を、同じ条件でどう確かめる?

修正後に数値が動いたときは、変更を実施した日時、変更箇所、元の設定内容を記録し、比較条件をできる限りそろえて効果を確かめます。

期間の長さだけでなく、曜日、端末比率、流入経路やキャンペーンの有無などの条件をそろえ、ツールのパーセンテージとあわせて実際の確定注文数や改修にかかった費用を照合します。注文数が限られる場合は数件の差で率が上下するため、自店の取引規模に応じた観察期間を設けて確認します。

あわせて、変更後に注文不能や送料の誤計算などの問題が生じた場合に備え、元の状態へ戻す切戻し手順を決めておきます(不可逆な機能移行を除く)。

次に行うべきアクションは、自店の現状を整理した1枚の診断チェック表を作成し、週2時間で確かめる変更を1つ選んで比較記録をつけることです。


関連記事

※本稿に記載の公式仕様・ヘルプの確認日は2026年10月9日時点のものです。

この記事の確認範囲

確認に使った公式資料

料金や記載の誤りを知らせる

CORRECTION

公式ページの変更や計算ミスを見つけた場合にお知らせください。氏名は不要です。個人情報や注文情報は入力しないでください。

送信内容は記載確認のためCloudflare D1へ保存します。保存項目・期間・削除依頼はプライバシーポリシーをご確認ください。