セッションリプレイでカゴ落ちを調べる方法｜送料・ログイン・決済前の操作を確認

カートには商品が入っているのに、注文が増えない。

送料を見てやめたのか、ログインに失敗したのか、決済の途中で画面が止まったのか。

セッションリプレイは、購入に至るまでの操作をたどり、次に調べる箇所を絞るために使います。

ただし、録画の終わりが、そのまま買い物の終わりとは限りません。

別の端末で購入した場合や、外部決済のあとに完了画面へ戻らなかった場合は、自社ページの記録だけでは結果が分からないためです。

この記事では、カート追加・購入手続き・注文成立を分け、送料、会員登録、決済前のエラーを順に調べます。

最後に、担当者へ渡せる「カゴ落ち調査の分岐表」を掲載します。

手順は公開されている公式資料をもとに整理したもので、架空の店舗例を実際の改善実績として紹介するものではありません。

カゴ落ち調査で対象の工程を決める

カゴ落ちという言葉だけで集計を始めると、商品を保存した人と、決済を試した人が混ざります。

最初に「どこから始めて、何をもって完了とするか」を決めましょう。

カート追加と購入開始を分ける

GA4の推奨イベントでは、カートへの追加を add_to_cart、購入手続きの開始を begin_checkout、購入を purchase として区別します（参考：Googleのeコマース計測）。

これらは、GA4のタグを置くだけで、どの店舗でも正しく自動収集されるという意味ではありません。

カートの連携機能やサイトの実装を確認し、それぞれがどの処理の成功時に送られるかを点検します。

例えば、追加ボタンを押して在庫エラーになった場合と、商品が実際にカートへ入った場合を同じ成功として扱うと、出発点から数がずれます。

調査用には、次のように対象を分けると整理できます。

調査する範囲	開始の例	完了の例	知りたいこと
カート追加後	商品がカートに入った	対象の注文が成立した	比較・保存から購入へ進む過程
購入手続き中	チェックアウトを開始した	対象の注文が成立した	入力・配送・決済の障害
決済の操作	支払い処理を開始した	決済側で結果が確定した	認証・エラー・戻り先の状態

ここでは、同じ訪問の中でチェックアウトを開始した記録を、最初の調査対象にする例で進めます。

後日の再訪や別端末の購入まで追う場合は、別の集計として識別方法と判定期間を設計してください。

カートの商品金額を足しただけで「すべて失った売上」とする計算も避けます。

比較用に入れた商品、重複したカート、購入する予定のなかった商品まで含む可能性があります。

記録できる範囲を確認する

商品ページ、カート、ログイン、配送設定、決済、完了画面を紙に並べます。

各画面について、URLの管理者と、録画・イベント・注文情報のどれを確認できるかを記入してください。

同じデザインに見える購入画面でも、外部サービスへ移動している場合があります。

自社の録画タグを設置していない他社の画面まで、連続して観察できるとは考えません。

例えばClarityの公式資料では、購入に関する機能はShopifyサイト、Checkout AbandonmentはShopify Plusサイトが対象とされています（参考：ClarityのE-Commerce Insights）。

専用カードが見当たらなくても、直ちにタグの不具合とは判断できません。

契約やサイト構成が、その機能の対象に入るかを先に確認します。

見えない工程は「離脱した」ではなく「この記録では確認できない」と残すことが大切です。

その欄には、注文管理、決済管理、エラーログなど、補足に使う情報も書き添えます。

カゴ落ちしたセッションを抽出する

調べたい工程が決まったら、対象の記録を選びます。

未購入らしく見える録画を大量に再生する前に、注文結果と比較条件をそろえましょう。

購入済みの訪問と分ける

まず、調査期間の注文記録にテスト注文や取り消し、支払い待ちが含まれるかを確認します。

注文受付を完了とするのか、支払いの確定まで必要なのかも、店舗の運用に合わせて決めます。

銀行振込などの支払い待ちを、カード決済の失敗と同じ分類へ入れないためです。

録画の時刻だけで注文を照合すると、同時に買い物をした別の人を取り違えるおそれがあります。

個別に結び付ける場合は、権限のある社内環境で、あらかじめ設計した識別子と時刻の条件を使います。

住所、メールアドレス、カード情報を録画のタグへ追加して照合する方法にはしません。

安全に照合できない場合は、個別の購入有無を「未確認」とし、注文全体の集計とは分けて報告します。

Clarityには、注文完了画面がセッションに含まれない場合、完了ボタンを押していても離脱と扱うという説明があります（参考：Clarityの購入・離脱に関するFAQ）。

そのため、ツールの離脱表示を、そのまま注文管理の未購入件数に置き換えないでください。

GA4のファネル探索を併用するなら、「探索」からファネルデータ探索を開き、設定済みの開始イベントと購入イベントを工程に置きます。

途中参加を含むオープンファネルか、最初の工程から始まるクローズドファネルかでも対象が変わります（参考：GA4のファネルデータ探索）。

録画側と集計側で、ユーザー・セッション・注文のどれを数えているかが違う場合、数値が一致しない理由も先に記録します。

端末と流入条件をそろえる

まずは、同じ購入画面、同じ公開版、同じ期間の記録を選びます。

スマートフォンで画面が隠れる問題を探しているなら、PCの購入成功と直接比較するより、スマートフォン同士で比べる方が確認しやすくなります。

Clarityでは期間に加え、Device、Browser、Operating system、訪問URL、UTMなどのフィルターを組み合わせられます（参考：Clarityのフィルター）。

調査対象の購入画面を通ったかを選ぶときは、入口を表すEntry URLと、訪問したページを表すVisited URLを取り違えないようにします。

さらに、送料の条件が同じか、商品が予約品か、セール中だったかも確認してください。

送料無料の商品と大型配送の商品では、表示すべき説明も購入判断も変わります。

条件を細かくしすぎて記録が数件になった場合は、発生割合を決めず、問題を再現する手がかりとして扱います。

成功した記録も同じ条件で選び、「この操作は未購入の訪問だけで起きたのか」を比べます。

広告の比較を続けたい場合は、調査のためだけに新しいキャンペーンへ分けず、既存の配信条件と流入情報を残して見直せます。

送料や配送条件の確認操作を追う

送料や配送日程を見直すときは、金額の大小だけでなく、いつ知ることができたかを追います。

情報の不足と、提示された条件が合わなかったことを分けて考えましょう。

追加費用を知るタイミングを見る

再生する前に、自分でも商品ページからカートまで進み、商品代、送料、手数料、割引後の金額が表示される場所を確認します。

配送先などを選ぶまで確定しない費用は、確定する条件と、先に分かる目安を記録します。

録画では、合計欄が表示された前後、配送説明への移動、商品ページへの戻りを見ます。

「合計金額の近くで止まった」という事実だけなら、送料への不満まで断定はできません。

商品の数量を変更していた、別の配送方法を選ぼうとしていた、画面を開いたまま別の作業をしていた可能性も残ります。

Baymardは、予想していなかった費用が遅い段階で分かる問題を挙げ、カートで費用の全体像を示すことを提案しています（参考：Baymardのカゴ落ち改善に関する調査）。

自社で試す場合は、この考え方を「送料を必ず無料にする」という結論へ飛ばさず、説明の時期と内容の仮説に落とします。

例えば「配送先を選ぶまで送料が変わることをカートで説明する」という案なら、表示の有無と、金額確定後の戻り方を比べられます。

記録には、金額を見たと推測した場所ではなく、実際に画面へ出た表示と操作を書きます。

到着日を確認する動きを見る

「出荷までの日数」と「手元へ届く日」は、同じ意味ではありません。

注文の締め時刻、休業日、配送先、予約商品が含まれるかによって、利用者が知りたい答えは変わります。

録画では、配送案内、カレンダー、FAQ、問い合わせの順に移動していないかを確認します。

そこで戻った人を「納期が遅いと感じた」と分類せず、「到着日の説明を探した可能性」として残します。

例えば、架空のギフト店で、購入画面から配送FAQへ移り、カートへ戻って日付選択を開いた場面を考えます。

この記録から分かるのは、配送情報の確認を挟んで、日付の選択へ戻ったことまでです。

「希望日に間に合わないから購入をやめた」という結論には、問い合わせやユーザーテストなど別の確認が必要です。

改善案は、配送方法の横に到着予定の範囲を示す、対象外地域の条件を先に出す、といった形に分けます。

実現できない到着日を表示すれば、購入後の問い合わせやキャンセルを増やす可能性があります。

説明を変更する前に、倉庫や配送担当へ、表示できる条件と例外を確認しましょう。

ログインと会員登録の操作を調べる

ログイン画面で終わった録画には、会員登録を避けた人だけでなく、既存会員として入れなかった人も含まれます。

選べる経路と、認証処理の状態を分けて調べます。

購入前の必須操作を確認する

画面上に「ログイン」「新規登録」「ゲスト購入」のどれがあるかを確認します。

ゲスト購入を用意している場合は、スマートフォンでも最初に見つけられる位置にあるか、文言で違いが伝わるかを点検してください。

選択肢が存在することと、利用者が選べると分かることは別です。

録画では、登録フォームを開いたあとに戻る、ログインと新規登録を往復する、ゲスト購入の案内より下へ進まない、といった操作を記録します。

ただし、その経路を選んだ理由を映像だけで決めることはできません。

ゲスト購入を目立たせる案を試すなら、「未ログインで購入を始めた訪問」を対象にし、既存会員のログイン成功率も合わせて確認します。

会員限定商品や継続購入など、本人確認や契約上の条件が必要な買い物もあります。

その場合は、必要な認証を取り除くのではなく、何のために登録が必要なのかを、購入前に分かるようにします。

ボタンの説明を変える案と、購入の仕組みを変える案は、担当者も確認範囲も分けてください。

認証エラーの前後を見る

認証エラーを調べるときは、入力された秘密情報ではなく、画面に出た案内と次の操作を見ます。

コードの期限切れ、再送、パスワード再設定、元のカートへの戻りなど、どの段階で進めなくなったかを記録します。

W3Cの認証に関する解説では、パスワード管理機能の利用や認証コードの貼り付けなど、記憶や転記だけに頼らない方法が示されています（参考：W3Cのアクセシブルな認証）。

担当者のテストでは、自動入力や貼り付けが使えるか、別の認証手段があるかも確認できます。

利用者のコードやパスワードを知る必要はありません。

Clarityは入力欄などをマスクする設計ですが、確認画面やエラー文に表示された個人情報も別途点検します（参考：Clarityのマスキング）。

調査のためにマスキングを外し、実際の顧客の入力を読めるようにする進め方にはしません。

架空のテスト情報を使い、認証の成功、失敗、再試行、キャンセルでカートが維持されるかを確認します。

「ログインできなかった」と「ログイン後に購入画面へ戻れなかった」は、修正箇所が異なるので別の課題として残します。

決済前の操作とエラーを照合する

決済前の調査は、録画とシステムの結果を合わせて行います。

ボタンが押されたこと、処理が受け付けられたこと、支払いが確定したことを分けてください。

入力補助とエラー表示を確認する

入力欄を行き来していても、マスクされた内容から、住所やカード番号のどこを間違えたかは分かりません。

そこで見るのは、エラーが表示された位置、修正先への案内、再送信したあとの状態です。

送信ボタンから離れた場所にだけエラーが出ると、スマートフォンでは見えていない場合があります。

キーボードや固定ボタンに説明が隠れていないかも、テスト端末で確かめます。

W3Cは、エラーを分かりやすく示し、該当項目や直し方を伝えること、送信成功も知らせることを説明しています（参考：W3Cのフォーム結果通知）。

調査票には「赤い表示あり」だけでなく、表示された案内と、その後に修正できたかを書きます。

決済画面を実際に再現する際は、提供元のテスト環境とテスト用の支払い情報を使い、本物のカード情報を記録しないようにします。

JavaScriptエラーが同時に出ていても、支払いを止めた原因とは限りません。

開発者へは、画面の版、端末、再現する操作、期待する結果、実際の結果を渡し、エラーの関係を調べてもらいます。

整理の例は、セッションリプレイでJavaScriptエラーを調べる手順でも紹介しています。

外部決済からの戻りを調べる

外部決済へ進んだあと、自社ページへ戻る前に録画が終わった場合は、まず決済・注文側の状態を確認します。

Stripeの公式資料でも、支払い成功後に通信が切れるなど、利用者が戻り先へ必ず到達するとは限らないことが説明されています（参考：Stripeの注文処理と支払い結果の確認）。

そのため、戻り先の画面だけを支払い完了の根拠にする設計では、成功した注文を見落とすことがあります。

担当者は、サーバーへ届く支払い通知と、注文管理の状態を確認してください。

結果の確定が後になる支払い方法は、処理中と失敗も分けます。

ここでの調査は、決済の安全確認を省いたり、利用者の承認を代行したりするものではありません。

次の表のように、購入結果と画面の問題を別々の欄へ記録します。

注文・決済の結果	録画で見えること	次に調べること
成立を確認	完了画面へ戻っていない	戻り先、通信、案内の不足
処理中	外部画面への移動後に終了	確定までの扱いと後続通知
失敗を確認	再試行の案内が見当たらない	エラー表示と復帰経路
照合できない	購入ボタンを押して終了	計測範囲と識別方法

購入が成立しているのに完了の案内が見えないケースでは、二重注文の不安や問い合わせにつながる可能性を別に調べます。

「売上がない問題」と「購入結果が伝わらない問題」を、一つの離脱として処理しないことが大切です。

カゴ落ち対策の優先順位を決める

調査の終わりには、録画の感想ではなく、確認する担当者と次の行動を決めます。

以下の分岐表は、架空のギフト店を想定した記入例です。

不具合と説明改善を分ける

カゴ落ち調査の分岐表

観察できたこと	まだ分からないこと	次の確認先	対応の候補
送料表示後に配送FAQへ移動	料金への不満か、条件の確認か	テスト購入・問い合わせ傾向	送料が決まる条件を先に説明
ゲスト購入の案内まで進まず戻る	選択肢を見落としたか	スマホの表示・ユーザーテスト	選択肢の配置と言葉を見直す
認証後にカートが空になる	特定環境だけの不具合か	認証担当・再現テスト	カートの引き継ぎを修正
送信後に進まずエラーが出る	決済処理が受け付けられたか	開発・決済担当	状態確認と再試行の案内
録画は終了したが注文成立	戻り先で何が起きたか	注文管理・通信の記録	完了案内と計測を点検

各行に、対象期間、端末、画面の版、確認した記録数、再現の有無を追記します。

認証後にカートが失われる問題など、購入操作を妨げる不具合が再現できた場合は、影響を受ける条件の確認を優先します。

送料の表示順のような案は、説明を変えたときの効果を検証する課題として扱います。

「簡単に直せるから」という理由だけで、影響の小さい見た目の変更を先に進めないようにしてください。

反対に、録画が一件しかなくても、注文できない重大な不具合が再現すれば対応の根拠になります。

発生割合が分からないことと、修正する必要がないことは別です。

共有する録画は必要な範囲と閲覧権限を確認し、説明用の資料へ顧客の個人情報を転記しない形にします。

変更後の購入率を再確認する

変更前に、評価する数字と、変えない条件を決めます。

例えば「同じ訪問内でチェックアウトを開始したセッションのうち、対象注文の成立を確認できたセッションの割合」と定義します。

分母も分子も同じ条件で照合できる場合に限って計算してください。

架空の例として、対象100セッションのうち30セッションで注文成立を確認できれば、その定義での購入率は30%です。

注文数を100で割る計算とは違い、一つのセッションで複数注文があっても、この例の分子は一件として数えます。

開始後に別の訪問で買う人を含める場合は、セッション内の率とは別の指標にします。

変更前後で、商品価格、在庫、送料、クーポン、広告の配信条件が変わったかも残します。

購入率が上がっても、同じ日に大きな割引を始めていれば、画面の変更だけが理由だとは判断できません。

キャンセル、問い合わせ、決済エラー、購入までの時間も確認すると、注文数だけでは見えない影響を把握しやすくなります。

少ない記録から効果を急いで決めず、必要ならヒートマップを使ったA/Bテストの進め方を参考に、比較の条件を設計してください。

最初の一歩は、同じ条件の購入成功と未完了の記録を選び、分岐表を一行埋めることです。

「どの場面で止まったか」と「何を確かめれば判断できるか」がそろえば、送料、認証、決済のどの担当へ相談するかが明確になります。