商品をカートに入れたことは、関心を示したサインです。しかし、今すぐ購入する意思が固まったとは限りません。送料を確かめるために入れる場合も、ほかの商品と比較したり、後で買うために保存したりする場合もあります。
そのため私は、カート離脱を見るときにまず、購入をためらった人と、購入しようとして先へ進めなかった人を区別できるデータがあるかを確認します。前者は価格・条件・購入時期の問題かもしれず、後者は入力・認証・決済エラーの問題かもしれません。離脱率だけでは、この2つを区別できません。
カートへの追加回数と、離脱した人数は違う
GA4のadd_to_cartは商品をカートに追加する行動、begin_checkoutは購入手続きを始める行動、purchaseは購入を完了する行動を測るためのイベントです。カート追加を収集していても、ほかの行動まで自動的に正確に収集されるわけではありません。サイトが実際の流れに合ったイベントを送っているかを、先に確認します。GA4のeコマース計測ガイド
1人が商品を何度も追加すると、カート追加の回数は増えます。同じ期間の購入件数をその回数で割っただけでは、「カートに入れた人の何パーセントが離脱したか」とは言えません。分子が注文数で、分母がボタンのクリック回数なら、異なる単位を比較しているからです。
簡単な例で考えてみます。1人が3回商品を追加し、1回注文した場合、追加イベントは3回、注文は1件となり得ます。ここから3人中2人が離脱したと解釈してはいけません。また、カートを通らない直接購入や簡易決済の経路があれば、カートのファネル外でも正常な注文が発生します。
最初は「カートに追加したユーザーのうち、決めた期間内に購入手続きの開始と購入完了まで進んだユーザー」を見るなど、問いを絞ってみてください。ユーザー単位かセッション単位か、何日以内の購入までを対象にするかも記録します。
まず自分のスマートフォンで購入直前まで進んでみる
離脱グラフを詳しく見る前に、実際のモバイル画面を確認すると、すぐに見つかる問題があります。ただし、運営者のアカウントではログインや住所入力が済んでいるかもしれないため、新規顧客が通る画面も別に確認します。実際の決済が発生しない範囲か、用意されたテスト環境で試してください。
私なら、見た目の良さを評価するより、次の操作を順に試します。
- カートでオプションと数量を変え、最終的な支払額がどう変わるかを確認します。
- 会員登録なしで次へ進めるか、登録が必要ならいつそのことが分かるかを確認します。
- 住所や連絡先に誤った値を入れたとき、どの項目を直せばよいか分かるかを確認します。
- 支払方法を選んで前の段階に戻ったとき、カートや入力内容が残っているかを確認します。
- モバイルのキーボード、下部バナー、チャット画面が、エラーの案内や次へ進むボタンを隠していないかを確認します。
観察内容は「決済が不便」ではなく、「住所のエラー案内が画面上部にあり、現在の入力位置からは見えない」のように記します。端末・ブラウザー・操作順を残すと、ほかの人も再現できます。1回試して見つからなかったからといって、すべての顧客環境で問題がないとは限りません。
送料と会員登録の条件が、いつ分かるかを確認する
価格を十分に理解したつもりでも、購入直前に送料や追加料金が現れると、顧客は条件を判断し直す必要があります。配送を急ぐ顧客には、総額と同じくらい到着時期も重要です。商品ページでは良い条件に見えても、選んだオプションや配送地域によって別の条件が適用されないか、確認する必要があります。
Baymardによる米国のオンライン購入者調査では、追加費用、配送の遅さ、会員登録の要求、複雑な購入手続きなどが離脱理由に挙がっています。一方、まだ購入する準備ができておらず、見ていただけの場合もあります。この調査は、考えられる原因を探す資料として役立ちます。自社ECサイトの原因別の割合や改善効果を示す数値ではありません。Baymardのカート・決済離脱に関する研究
送料が問題かを確認することは、すぐに送料無料へ変えるという意味ではありません。まず、購入を判断する前に、必要な条件が分かるかを見ます。送料無料になる購入金額、一部地域の追加料金、到着予定日を分かりやすく示すことと、実際の価格方針を変えることは、分けて検討する必要があります。
ゲスト購入も、機能の有無だけでは不十分です。機能があっても、ログイン画面の下に小さな文字で隠れていれば、顧客は登録が必須だと思うかもしれません。Baymardのユーザビリティ研究でも、ゲスト購入の選択肢に気付かない場面を取り上げています。新規顧客の画面で、その選択肢を簡単に見つけられるか、実際に確認してください。Baymardのゲスト購入の選択肢に関する研究
決済を試みた後の失敗は、決済記録で確認する
顧客が決済段階まで進んだなら、何が起きたのかを、より具体的な記録で調べられます。決済ボタンを押したのか、カード会社の認証へ移動したのか、承認を拒否されたのか、承認後に注文状態が正常に反映されたのかを分けます。購入完了イベントがないだけでは、どこで止まったのか分かりません。
ECサイトの管理画面や決済代行会社の記録で、失敗した時刻、支払方法、エラーメッセージを確認してください。例えばShopifyでは、未完了のチェックアウトのタイムラインで、決済の試行に関するイベントやメッセージを確認できます。カードの拒否、認証失敗、在庫や割引コードの問題では、対応する担当者も異なる場合があります。Shopifyの未完了チェックアウト・決済イベントのガイド
このとき、GA4とEC管理画面の「離脱」数が同じだとは考えません。Shopifyの未完了チェックアウトには、メールアドレスの提供後、一定時間完了していないチェックアウトなど、独自の収集基準があります。カートに追加して離れたすべてのユーザーの一覧ではありません。
決済代行会社に承認記録があるのに、ECサイトの注文状態やGA4の購入記録がないなら、購入意思の不足より、システム間の連携を先に確認します。外部決済画面からの戻り先URL、決済結果の通知、購入イベントの送信タイミングをそれぞれ調べます。決済情報や個人を特定できる情報を、そのまま分析レポートや画面キャプチャに貼らず、エラーの種類と発生条件を中心に整理してください。
ファネルで減少する段階を絞り込む
イベントが正常に収集されていることを確認したら、カート追加→購入手続き開始→購入完了の順にファネルを作ってみます。GA4のファネルデータ探索には、最初の段階から入ったユーザーだけを見るクローズドファネルと、途中からの参加も認めるオープンファネルがあります。同じ名前のファネルでも、設定が違えば人数は変わります。GA4のファネルデータ探索ガイド
基本の分析では、途中にページビューなどの別の行動を認めるか、次の段階までどれだけ時間を認めるかも決めます。商品によって検討時間は違うため、すべての購入が短い1回の訪問で終わる条件にすると、正常な再訪購入を見落とす可能性があります。
次に端末や流入別に分けますが、最初から細かく分けすぎない方がよいでしょう。モバイルで購入手続き開始後の進行が特に低いなら、その環境の決済画面とエラー記録を先に見ます。カート追加から手続き開始までが低いなら、総額・配送条件・登録画面など、その間に出会う項目を確認します。これは確認箇所を絞るための解釈であり、ファネルだけで原因を確定する方法ではありません。
GA4のユーザーファネルを端末別に分けても、各段階で実際に使った端末を必ず表すわけではありません。最初に該当した端末でユーザーが分類される場合があるため、特定のモバイルブラウザーのエラーを主張するには、その環境での再現や決済ログが別途必要です。
修正するときは、仮説と確認する結果を一緒に決める
確認した問題を「現象→考えられる理由→変更内容→確認する結果」で記すと、実行しやすくなります。例えば配送条件を見つけにくいという観察があれば、購入直前にしか分からなかった条件を、もっと早い画面で示す変更を検討できます。このとき確認するのは、ボタンのクリックだけでなく、購入手続きの開始・完了、注文あたりの収益、配送に関する問い合わせの変化です。
実際に決済を妨げるエラーは、原因が分かったら優先して修正します。画面構成や文言の影響など、まだ仮説の段階にある変更は、可能なら比較実験で検討します。実験が難しければ、変更日とともに広告流入・割引・品切れなど、ほかの変化も記録します。修正前後で注文が増えたという事実だけで、その増加分のすべてを修正の効果と断定しないようにします。
購入手続きを改善する目的は、離脱率をただ下げることではありません。購入したい人が条件を理解し、必要な情報を入力して、決済を完了できるようにすることです。まず今日のモバイル画面で見つけた障害を1つと、その問題がどの程度起きているかを確認する資料を1つ、結び付けてみてください。