Article by: Kyle Tryon
本ブログの内容
- リアルな顧客インサイトのために Session Replay を有効化する
- チェックアウト離脱とカート放棄の原因を診断する
- Session Replay を使って放棄カートを Sentry で確認する
- 自分のショップを次のステップへ
小売店が長年にわたってショッピング体験の測定と改善のために頼ってきた秘密兵器… それが「シークレット・ショッパー」です。
彼らは一般の客を装い、顧客体験を評価します。たとえば見つけにくい商品の特定、接客品質の評価、チェックアウトプロセスのスムーズさなど、摩擦が生じる箇所を見つけ出します。彼らが収集するデータは、偏りのない実践的なフィードバックの代理として機能し、店舗運営者はそれを基に顧客体験を改善し、コンバージョン率を高め、平均注文額を増やします。
しかし、eコマースでは小規模なサンプルや代理顧客に頼る必要はありません。Session Replay （セッションリプレイ）のようなツールを使えば、実際の購買者の行動を大規模に分析できるのです。さらに、ユーザーのセッションを「再生」して、彼らが実際に見たものをクリックごとに正確に確認することもできます。
リアルな顧客インサイトのために Session Replay を有効化する
Session Replay は、ユーザー体験をまるで動画のように再現し、その時に発生したログ、エラー、トレースなどの関連情報をすべて紐づけて記録します。これにより、ユーザーが実際にどのような体験をしているのかを、当時のコンソールログなどと突き合わせながら確認することができます。
これは、ユーザー自身に報告を依頼せずに問題を診断できる非常に優れた方法です。詳細な説明やスクリーンショット、動画を求める代わりに、実際に何が起きたのかをそのまま見ることができるのです。
しかも、これは単なるエラーデバッグツールにとどまりません。「どこで迷い、どこで操作フローが途切れ、デザイン上の選択が体験にどう影響しているか」といったユーザーの行動パターンを可視化することもできます。
導入をするには、まず自分のオンラインストアのフロントエンドフレームワークに対応する正しい SDK を選び、Replays 機能を有効化した状態で Sentry を追加します。もし Shopify の Hydrogen を使ってアプリを開発している場合は、React Router SDK を利用することができます。
以下は、ご自身のアプリに簡単に組み込めるシンプルな React のセットアップ例となります。
エラー発生時や通常のセッションなど、状況に応じて Session Replay のキャプチャ率（録画割合）を個別に設定 することができます。たとえば、エラーが起きた場合はより多くのリプレイを取得するように設定し、一般的なセッションでは低めに抑えるといった調整が可能です。
設定やデバッグを行う段階では、キャプチャ率を一時的に 1.0（100%） に設定しておくと確認がしやすく便利です。ただし、本番環境では月間上限（monthly cap）への負荷を減らすために、キャプチャ率を適切に下げて運用することをおすすめします。
Sentry の設定が完了したら、テレメトリーデータの収集 を開始できます。一部のフレームワーク SDK（たとえば Next.js）では、アプリの多くの部分でエラートラッキングやスパン（処理区間）の計測が自動的に行われます。もちろん、必要に応じてアプリ内の任意の箇所に手動でスパンやメタデータを追加することも可能です。
チェックアウト離脱とカート放棄の原因を診断する
多くのECプラットフォームでは、カート放棄率を追跡し、「商品をカートに入れたものの、チェックアウトを完了しなかった」購買者の数を表示します。チェックアウトのコンバージョン率を把握することは確かに有用ですが、顧客がなぜカートを放棄したのかを知ることこそが、カートからチェックアウトへのコンバージョンギャップを埋めるために必要な知見です。
アプリケーションの中でも特に重要な体験については、常にオブザーバビリティ（可観測性）を最大化することを目指すべきです。オンラインストアにおいて、チェックアウト体験は最も重要なポイントであり、ユーザーがチェックアウトできなければ、販売は成立しません。
Shopify や WooCommerce（WordPress 経由）を利用している場合でも、あるいは独自のカスタムチェックアウトフローを構築している場合でも、包括的なオブザーバビリティを実装することが可能です。
チェックアウトへのオブザーバビリティ（可観測性）の追加
Sentry.startSpan メソッドは、メトリクスを収集したいコードを配置するコールバック関数を受け取ります。
この中で実行されるコードのうち、Sentry のスパンを持つ処理はすべてこの「親スパン（parent span）」の「子スパン（child span）」として記録され、Sentry の Trace Explorer で簡単に読み取れるイベントフローを構築します。
スパンを収集し始めると、自動的に多くのメトリクスが取得されます。たとえば、処理にかかった時間、ユーザーが利用しているウェブブラウザなどです。
さらに、カスタム属性（custom attributes）を追加することもでき、たとえば「カートの合計金額」などを付与できます。将来的に、「平均より高い金額のカート」を抽出するクエリを実行したい場合に役立ちます。
ここでは例として、一般的な React アプリを構築していると仮定します。あなたの「cart」ページは .tsx コンポーネントとして構築されており、useEffect フックを使って Sentry を初期化し、再実行されないようにしています。
まず最初に setUser を呼び出し、ユーザー ID を含むオブジェクトを渡します。もし Shopify の Hydrogen を使ってアプリを開発している場合は、Customer Account API を通じてログイン中のユーザー情報を取得できます。
カート放棄の追跡
前述のとおり、多くのプラットフォームには放棄されたカートを特定・追跡するための何らかの仕組みが組み込まれています。ただし、「カート放棄」の定義はプラットフォームによって異なります。自分でアプリを構築し、プラットフォームのAPIを利用している場合は、任意の基準でカート放棄を定義し、追跡することができます。
Shopify には「放棄されたチェックアウト」を追跡する機能がありますが、これは 外部のチェックアウトページに紐づいているため、可視性が失われ、得られる情報の有用性が下がってしまいます。
さらに Shopify では、ユーザーがチェックアウトページに到達し、メールアドレスを入力した状態で離脱した場合にのみ カートが「放棄」としてカウントされます。しかし、独自アプリを開発している場合には、放棄の定義を別の形で設定したいこともあるでしょう。
自前のカートおよびチェックアウトページを持つアプリであれば、顧客がどのように操作しているかを把握する必要があります。そのため、カスタムアプリにはカスタムソリューションが必要になります。
サーバーサイドでカート情報を保存し、一時的な customer Id としてセッションIDを利用すれば、ユーザーがチェックアウトを完了する前の行動パターンも記録・分析することが可能です。また、カート放棄を「単一セッションを超えて長期間チェックアウトされていないカート」と定義する場合にも、この方法は必要になります。
どのように放棄カートを定義・追跡するにしても、最終的な目的は、カート放棄した顧客ID（customerId）の一覧を取得し、Sentry上でそれらのユーザーのセッションを調査できるようにすることです。
サーバーサイドのコードは、次のような形になります。
このデータを使えば、特定のユーザーセッションを Sentry 上で検索し、チェックアウトプロセス中に実際に何が起きたのかを正確に確認できます。
Session Replay を使って放棄カートを Sentry で確認する
これで、どのユーザー（仮ユーザーであっても）が「放棄されたカート」を持っているのかを、あなたが定義した基準に基づいて把握できました。さらに、Sentry のスパン内で setUser によって設定した 顧客ID（customer ID） と一致するユーザーIDも分かっています。
次に、Trace Explorer に移動し、以下の条件を含むスパンを検索します。
- 該当ユーザーの ID
- カートページ
- セッションリプレイ（Session Replay）が含まれていること
これで、放棄カートを持つユーザーのセッションを特定し、クリック単位で実際の行動を再生しながら確認することができます。
放棄カート一覧にある実際の customerId で guest の部分を置き換えます。
このクエリでは、以下の条件を満たすすべてのトレースが表示されます。
- ユーザーID が放棄カートを持つ顧客の ID と一致していること
- スパンがカートページ（`/cart`）を含んでいること
- Session Replay が添付されていること（`has:replayId`）
「Traces Samples（トレースサンプル）」タブを開くと、結果をトレース単位で集計して表示することができます。ここでは、ユーザーが /cart ページにアクセスした 4つの異なるイベント が発生していることが確認できます。
これらのトレースのいずれかをクリックすると、そのトランザクション内で記録されたすべてのスパンを確認することができます。
「See Full Replay（フルリプレイを見る）」ボタンをクリックすると、対象ユーザーのセッション全体を再生できます。
ここで、ユーザーがカートを放棄した理由につながる可能性のある体験上の問題を確認していきましょう。たとえば、読み込みの遅さ、レイアウトのズレ、エラーの発生などに注目する必要があります。
Session Replay を使った放棄カートのレビュー
ここからが最も重要な部分です。実際にユーザーがカートを放棄するまでにどんな体験をしたのかを再現して確認します。
Session Replay をクリックすると、顧客が何を見て、どのように感じ、どこでつまずいたのかを正確に確認できます。Session Replay は動画そのものではありませんが、ユーザーの DOM（ページ構造）を動画のように再生する体験を提供します。画面右側のパネルには、いくつかのタブ──errors（エラー）、network（ネットワーク）、console（コンソール）、breadcrumbs（ブレッドクラム）──が表示されます。
Errors は Sentry の主力機能であり、通常はユーザー体験をデバッグする際に最初に確認する場所です。ただし今回のケースでは、ユーザーはエラーを体験していません。少なくとも、Sentry が記録した範囲ではエラーは発生していません。
プレイヤー下部には再生ボタンがあり、タイムライン上には小さな点が表示されています。それぞれの点は、ページ上のイベント（クリックやエラーの発生など─）に対応しています。点の色はイベントの種類を示しており、カーソルを合わせると詳細が表示されます。また、これらのイベントは Breadcrumbs（パンくずリスト）タブ 内でもより詳細に確認することができます。
このケースでは、ユーザーが離脱した原因はエラーや読み込みの遅さではなかったと考えられます。実際のところ、どんなメトリクスを計測しても、この問題を検知することはできなかったでしょう。
リプレイを確認すると、ユーザーはカートページに移動し、配送先の国と郵便番号を入力して送料を計算しています。
すると、合計金額が $4.99 から $13.98 に変化。その直後、カーソルが画面の上部へすばやく移動し、セッションが終了しています。
この内容から判断すると、ユーザーは本来購入を完了するつもりだったものの、送料による価格の3.5倍の上昇に納得できず、離脱した可能性が高いと考えられます。
自分のショップを次のステップへ
カート放棄は、アナリティクスのダッシュボード上の単なる数字ではありません。それは、顧客体験の反映であり、潜在的な収益が漏れ出しているポイントでもあります。
人間の行動は、必ずしもメトリクスで定量化できるものではありません。しかし、テレメトリーデータから推測を立てることは可能であり、アンケートやサポートチケットを通じて限定的なフィードバックを得ることもできます。とはいえ、そうした代理データは、実際にその瞬間に何が起きたのかを観察することに比べれば、本質を明らかにするものではありません。
Session Replay を使えば、推測の域を超えることができます。あらゆるクリック、スクロール、ためらいの一つひとつを、それを形作ったスパンやイベントと直接結びつけて可視化できるのです。
Session Replay は、すべての Web アプリケーションに対応しており、さらに iOS や Android アプリでも利用可能です。顧客体験を完全に可視化できるよう、ぜひ導入を検討してください。Session Replay の設定方法や多彩なオプションについては、Sentry のドキュメントで詳しく確認できます。
ダッシュボードや数字だけでは人間の行動を説明しきれないとき、最後に必要なのは「見ること」そのものかもしれません。
Original Page: Session Replay: Becoming your own digital secret shopper
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
