ECサイトでカートに入るのに注文が少ないとき、購入手続きをどう見直すか

カートに商品を入れてもらえているのに、注文が少ない。そんなときは、すぐに送料や入力欄を変える前に、同じ商品・配送先で、購入者が総額と条件をいつ確認できるかをたどり、注文記録と計測の範囲を分けて見ることから始めます。

この記事は、小さな物販のネットショップを担当する人が、商品ページから注文完了までを見直すための手順です。アクセスを増やす方法や購入後の再購入施策ではなく、購入手続きの途中に絞ります。数値だけで離れた理由は分からないため、画面で見える事実、注文記録、理由の仮説を別々に扱います。

注文が少ないときは何から確かめる？

まず、商品ページで購入条件が分かるか、カートから最終確認まで同じ条件を追えるかを見ます。その後、注文の受付記録と、計測ツールが記録した操作を照らし合わせます。画面の表示、受付された注文、訪問者の操作は別の情報です。どれか一つだけで、購入者が迷った理由まで決めることはできません。

手順は、商品を選ぶ、商品ページとカートで条件を見る、配送・支払を入力する、注文前に内容を確認する、注文管理で受付を確かめる、の順です。画面で読める条件、注文管理に残る受付、アクセス解析に記録された操作は別々に確認します。この順序は調査の進め方であり、実際に購入が成立した証拠ではありません。

例えば、カート操作が記録されていても、決済が途中で止まったのか、別の日に買ったのか、そもそも必要な操作が記録されていないのかは、その数字だけでは分かりません。まず「何を確認できて、何がまだ分からないか」を分けると、見当違いの修正を減らせます。

同じ商品と配送先で、画面をたどる

確認する商品・数量・配送先の条件を固定すると、画面ごとの金額や説明を比較できます。スマートフォンで商品ページから進み、商品を一つ選び、配送先を指定した後、注文確定の直前まで同じ条件で見ます。実注文を作らない方法が用意されていない場合は、確定ボタンを押さずに止めます。

以下は説明用の架空例です。税込2,400円の商品を1点、送料600円の地域へ送ると、値引きや追加手数料がない場合の支払総額は3,000円です。この条件は計算のために置いたもので、実在する店舗や注文、確認結果を示しません。

図では商品代2,400円と送料600円の関係を同じ商品で追い、最終確認の3,000円と対応させています。商品ページで送料が確定しない場合は「配送先によって変わる」ことと確認できる場所を示し、配送先を選んだ後には、その条件での送料と総額が分かるようにします。総額が見えることと、購入者がそれを納得したことは別です。

各画面では、次の順に内容と操作を見ていきます。

1. 商品ページ：商品内容、税込価格、配送費が変わる条件、返品条件への入口を見る。送料が未確定なら、いつ確定するかを示し、額を推測しない。
2. カート：商品・数量・小計、数量の変更や削除、配送費の確認先を見る。数量変更後に小計が更新されるか確認する。
3. 配送・支払入力：対象の配送先、送料、選べる支払方法、必須欄と誤入力時の案内を見る。どの欄をどう直せばよいか分からなければ、表示と操作を記録する。
4. 注文前の最終確認：数量、価格、送料を含む総額、配送・支払、返品等の条件、訂正方法を見る。条件が読めない・戻って直せない場合は、その画面と対象条件を残す。
5. 完了表示と受付：完了表示の意味と、実際の注文をどの記録で確かめるかを見る。表示だけで入金や発送まで完了したとは判断しない。

たとえば送料のリンクが商品ページの下部にしかない場合、「商品ページで見つけにくい」という画面上の事実は残せます。一方、「送料を見て離れた」とは、画面だけからは言えません。購入者への確認や操作テストで、仮説を確かめる必要があります。

通信販売の申込みでは、対象となる契約について最終確認画面の表示や、申込み内容を容易に確認・訂正できる措置が重要です。購入率の改善を理由に、必要な条件表示や訂正の機会を削らないでください。対象取引や具体的な表示は、消費者庁の通信販売ガイドラインで確認します。

カートの操作と注文完了はどう読み分ける？

注文管理画面の受付件数と、アクセス解析に記録された操作は、同じものとして足し引きしません。受付件数は注文管理の記録、アクセス解析は設定された操作の記録です。注文が受付済みでも、決済・入金・発送がどうなったかは別の状態を確認します。

カート追加はアクセス解析に設定された操作イベント、注文受付は注文管理に残る取引記録です。両方の記録を同じ利用者や注文として結び付けられるかは、計測設定や注文管理の仕様を確かめないと分かりません。件数が違う場合も、差だけで不具合や離脱理由とは判断できません。

Google アナリティクス4（GA4）は、サイト上の操作をイベントとして記録する仕組みです。例えば「商品を見る」「カートに追加」「購入手続きを開始」「購入」を測れますが、必要なイベントが設定されているかはサイトやサービスの構成によって異なります。未取得の欄は未確認であり、実際の行動がなかったという意味ではありません。

GA4の購入経路レポートは、既定では「クローズド型」です。これは決められた順番で各段階を通った利用者を数える方法です。Googleの公式説明では、レポート上部のスイッチで、途中の段階から入った利用者も含む「オープン型」へ切り替えられます。一方、標準レポートに並ぶ段階や条件自体は変更できません。別の段階を調べる場合は、別途ファネルデータ探索やカスタムレポートを作ります。入口と順序の違いで集計対象は変わるため、同じ期間でも数字を単純には比べられません。購入経路レポートの公式説明と、ファネルデータ探索の説明で、対象と条件を確かめてください。

実際に調べるときは、次の順で進めると、画面の問題と計測の不足を分けやすくなります。

1. GA4の「レポート」からライフサイクル内の「収益化」→「購入経路」を開き、期間とクローズド型・オープン型の設定を決めます。表示されない場合は、編集者以上の権限を持つ担当者にレポートの追加を依頼します。
2. 購入手続きの開始と購入を表す begin_checkout と purchase が取得される構成か、サイトの計測担当者に確かめます。ECイベントは構成によって追加設定が必要で、一部サービスでは自動設定される場合もあります。GoogleのECイベント設定方法
3. 承認されたテスト環境やテスト注文で一連の操作を行います。自分の端末はGoogle Tag Assistantのプレビューモードでデバッグを有効にし、GA4の「管理」→「データの表示」→「DebugView」でイベントを確認します。イベントが見えない場合は、計測設定や同意の条件も調べ、未確認のまま扱います。
4. 注文管理と見比べる際は、期間やキャンセルの扱いをそろえます。注文件数とGA4の利用者数は単位が違うため、差だけで離脱や不具合とは判断しません。

購入率をセッション（サイトを訪れて操作する一連の時間）単位で見る場合は、購入が記録されたセッション数 ÷ 対象の全セッション数 × 100で求めます。例えば同じ条件の架空の200セッションのうち、purchase が記録されたセッションが4なら2％です。同じセッション内の購入イベントが複数回でも、分子は1セッションとして数えます。購入イベントが取れていなければ、この割合は算出できません。GA4のセッションのキーイベント率も、キーイベントが発生したセッションを分子にする考え方です。これは注文件数や利用者数を分子にした割合とは異なり、上の購入経路レポートの利用者数をそのまま使って計算するものでもありません。

変更前後の比較では、例えば変更前の7日間と変更後の7日間を取り、対象、購入イベント、セッションの定義をそろえます。曜日構成や広告・セールの有無も見て、条件が大きく違う場合や件数が少ない場合は判断を保留します。割合が変わっても、変更だけが原因とは限りません。

架空の例で、対象期間内に「購入手続き開始→購入」の順を同じ利用者について数えるクローズド型の探索を作り、「開始100人、次の購入段階60人」と表示されたとします。この条件・期間で次段階が記録されなかったのは40人ですが、「40人が送料を嫌って離れた」とは言えません。別の日に戻る人、途中から入る人、記録されない操作が含まれる可能性もあるからです。これは読み方を説明する例であり、実績や一般的な割合ではありません。

数字を比較する前に、期間、対象商品、利用者か操作回数か、入口と順序、別セッションの扱い、イベントの設定をそろえます。注文管理とGA4の購入記録が一致しない場合は、注文記録とGA4の購入記録を比べる方法で、記録の違いを先に整理できます。原因の仮説には、担当者による実画面確認や利用者テストを組み合わせます。

改善は一か所を選び、同じ条件で見直す

確認した事実から、購入者が判断しにくい箇所を一つ選びます。商品、対象期間、変更した表示、確認する記録を決めてから改善すると、何を比べたか説明しやすくなります。

例えば、送料の確認先が見つけにくいと画面で確かめた場合は、商品ページの価格付近に「送料は配送先によって異なります」と案内へのリンクを置く方法があります。変更前後とも同じ商品・配送先で注文前までたどり、送料と総額、訂正方法が見えるかを比べます。これは確認方法の例であり、購入率が上がった結果ではありません。

1. 事実を分ける。 「商品ページに送料の確認先が見つからなかった」は画面で確かめた事実です。「送料が原因で離れた」は未検証の仮説です。
2. 変更を一つ選ぶ。 例えば商品ページの価格の近くに、配送先で送料が変わる旨と送料案内へのリンクを置きます。最終確認の総額や返品条件は残します。
3. 同じ条件で操作する。 同じ商品1点・同じ配送先で、リンク先と総額、数量変更、戻って訂正する操作を確認します。実注文を行わない場合は注文完了を確認したとは記録しません。
4. 実際に取れる記録を比べる。 同じ定義の注文受付と、取得できているイベントを対象期間ごとに見ます。期間が短い、イベントが未設定、注文記録の範囲が違う場合は結果を保留します。
5. 次の判断を選ぶ。 表示やリンクの不備が解消したことを確認できれば、その表示を維持します。操作しにくさが残れば見直し、購入への影響が判断できないなら観測を続けます。数字が増減しただけで変更の効果と断定しません。

他にも、支払方法が選べない、入力を直す場所が分からない、エラー後に内容が消える、といった場合があります。原因が特定できていなければ、すべてを同時に直す前に、まず実際に再現できる一つの問題を選びます。海外のEC利用者テストでも、配送日や入力時のエラーを理解できることが購入手続き上の課題として報告されています。ただし、他社の調査結果から自店の原因や改善幅を決めることはできません。Baymard Instituteの購入手続き調査は、確認箇所を考える参考として使います。

まとめ：購入条件と記録を分け、一つ改善する

注文が少ないときは、同じ商品・数量・配送先で画面をたどり、総額・送料・支払・返品と訂正方法を確認します。次に、注文管理の受付と、設定された操作イベントを別々に見ます。記録されていない項目や、数字だけでは分からない購入者の理由は未確認のままにします。

最初の一歩は、商品を一つ選び、商品ページから注文確定の直前までスマートフォンで進むことです。条件が見つかりにくい箇所を一つ選び、修正後も同じ条件で画面と記録を見直してください。比較条件が揃わなければ成果は保留し、改善を次の仮説へつなげます。

CVR（コンバージョン率）は、訪問などの対象に対して購入や申込みに至った割合です。分母と成果の定義をどうそろえるかは、CVRの基本と改善の進め方で詳しく説明しています。

購入までの導線や改善の進め方を自社だけで整理しにくい場合は、DREEXYのマーケティング支援を確認し、相談窓口から相談できます。現在の購入手続き、確認できる注文記録、見直したい箇所を、分かる範囲で伝えてください。具体的な支援範囲と費用は相談時に確認します。

出典とこの記事の範囲

本記事の金額・人数・画面は説明用の架空例です。実際のサイト操作、注文、売上、改善効果を示すものではありません。制度や機能は、対象取引や利用環境によって異なります。

• 消費者庁：通信販売のガイドライン — 申込み段階の表示と確認・訂正に関する説明。
• Google：購入経路レポート — 利用者の集計対象、クローズド型とオープン型。
• Google：eコマースデータ探索 — 別セッションの例と、理由が不明な場合の確認方法。
• Baymard Institute：購入手続きのユーザビリティ調査 — 購入画面の情報や操作に関する海外の調査。