リテール・ECを取り巻く環境の変化
世界的に猛威を奮っているパンデミックは、個人の生活スタイルやワークスタイル、ビジネスに大きな影響を及ぼしています。中でもリテール・ECに関しては著しく変化をした業態の一つです。リモートワークや外出自粛もあり、物販系のオンラインショッピングの利用者が増え、また従来実店舗のみでビジネスをしていた企業のEC参入なども起こりました。このような動きは一時的なものではなく、むしろデジタル化が加速されたことによって競争相手が増える結果となり、今後は既存ユーザーの維持や新たなユーザーの獲得がますます重要な課題になると言えるでしょう。
ユーザー体験の重要性
ユーザーの維持・拡大にあたっては良い商品やマーケティングが大事であることはいうまでもないですが、オンラインショッピングにおけるユーザー体験の向上も非常に重要な要素です。システム障害によってサイトにアクセスできない、決済時にエラーが発生して購入できない、セールの時に負荷が集中して表示に時間がかかる、このような悪い体験は誰しもされたことはあるのではないでしょうか。このような問題は短期的なビジネス上の機会損失になるだけでなく、悪い体験をしたユーザーがサイトの利用をやめたり、競合のECサイトやECプラットフォームに移るなどして中長期的な損失にも繋がります。実際、サイトのページ表示時間が遅くなるとサイトの離脱率が上がることや、表示性能の悪化が売上低下に繋がるというレポートも出ています。EC事業者も、実店舗と同様に買い物の場の提供者です。快適に買えるデジタルな売り場を作り、ユーザーにより良い体験を提供することがユーザーの維持・拡大に必要不可欠になっていることは言うまでもないかもしれません。
快適にモノが買える場の実現に向けて
では、ECサイトを快適にモノが買える場とするためには何をしないといけないでしょうか。漫然と運用しているだけでは見えてきませんが、ユーザー体験を以下のような観点で分類すると課題が見えてきます。
1. サイトにアクセスできるか？（可用性）
そもそもサイトの利用を開始できないと話になりません。バックエンドシステムのダウン、CDNの障害、モバイルアプリのクラッシュなど、ユーザーがサイトを利用できない要因は様々ありますが、このような状態に陥った場合は最優先での回復が必要になります。
2. トラブルなく購入できるか？（機能性）
ログインしてから商品を検索し、カートに入れて、購入する。このような購入までのプロセスにおいて、例えばカートに入れる際にエラーになる、もしくは、決済時のエラーで購入できない、など、サイトは動いていても一部の機能的な不具合によって購入を中断せざるをえない事象が発生していないかを把握する必要があります。
3. 快適な速度で利用できるか？（応答性）
冒頭で言及したように、画面の表示が遅ければサイトからの離脱率が上がってしまいますし、ユーザーのフラストレーションも溜まります。いくらダウンせずに動いているシステムであっても、性能が伴っておらず購入フローの中でユーザーにストレスをかけるシステムでは良いユーザー体験を提供しているとはいえませんので、期待される速度で利用できているかも把握する必要があります。
ユーザー体験に影響する指標とその収集方法（例）
上で挙げた観点でユーザー体験を把握するためにはどのような指標を見るのが良いか、その一例を示します。
「1. サイトにアクセスできるか？（可用性）」を測る指標
稼働率
ユーザーの視点からサイトに対してアクセスできるかを定常的に監視し、サイトダウンや稼働率の低下を早期に検出します。
ユーザーから見た稼働率は、外形監視（Synthetics）を設定し、稼働状態を継続的にチェックするモニターを稼働させることで計測できます。外形監視の概要や設定方法についてはこちらのブログを参照ください。
スループット
スループットの急激な低下は何らかの異常が発生しているサインです。サイトダウンや過負荷によってサイトへのアクセスができない状態に陥るとスループットが低下しますのでこれを監視し、異常の兆候を早期に捉えます。
クライアントサイドのスループットはBrowserエージェントやMobileエージェントが、サーバーサイドのスループットはAPMエージェントやLambdaレイヤーを活用することで計測できます。例えばブラウザからのアクセスのはBrowser UI上の以下のようなチャートで確認できます。
バックエンドトランザクションのスループットはAPMのUI上、以下のようなチャートで確認できます。
なお、スループットの急激な低下を検知する場合、静的な閾値チェックによってアラート通知するだけでなく、普段の振る舞いとは異なる異常な振る舞いを検知する、所謂アノマリ検知を使ったアラート通知が有効です。
モバイルアプリのクラッシュ率、起動数
モバイルアプリのバグ等によるクラッシュ増加や起動数の低下もユーザーの利用ができていないことを表しますので、クラッシュ率や起動数の低下を監視して問題を早期に検知します。
クラッシュや起動数はMobileエージェントによって計測され、MobileのUI上、以下のようなチャートで確認できます。（サンプルサイトのためクラッシュ率は高めです）
「2. トラブルなく購入できるか？」を測る指標
ユーザー操作フローのエラー
機能追加などを契機に作り込まれたバグによって、元々あるユーザー操作フローが破壊されて正しく動作しなくなるということは起こり得ます。もちろんリリース前に刈り取れることがベストですが、万一リリースされてしまっても顕在化したり被害が広まる前に自分達で把握できるようにしておくことで致命傷になることを防げます。
外形監視（Synthetics）を活用して、画面遷移やボタンクリックなどのユーザー操作フローを模倣して正しく動作することをチェックすることが可能です。Syntheticsが提供する何種類かのチェックのうち、ScriptedBrowserがこれに該当します。実態は、ユーザー操作フローが実装されたスクリプトを定期的に実行することで操作フローのバリデーションを行います。スクリプトを一から作るのが難しい方もいらっしゃるかと思いますが、外部ツールを使って容易に実装することもできます。詳細はドキュメントを参照してください。
以下の画像はScriptedBrowserのチェック結果のスクリーンショットですが、ホームページへのアクセスからログイン、カートのうちか、決済までの一連のフローが正しく動いていること、および各ページの画面表示時間などが詳細に記録されます。
処理エラー（JavaScriptエラー、通信エラー、アプリケーションエラー）
フロントエンド、バックエンドにかかわらずバグや想定外の問題によってエラーが発生し、購入が継続できない状況が発生した場合は、それをいち早く検知する必要があります。
クライアントサイドはBrowserエージェントやMobileエージェントが、JavaScriptエラー、通信エラー、モバイルアプリのエラーを捕捉します。また、バックエンドは、APMエージェントやLambdaレイヤーがアプリケーションで発生した例外を捕捉します。
UI（ErrorsInbox画面）上では、システム内で発生したエラーをフロントエンドからバックエンドまでE2Eで確認することが可能です。どこのレイヤーでどのようなエラーがどのような頻度で発生しているかを捉え、急増しているエラーや初めて検出されたようなエラーを優先的に対処してくことができます。
「3. 快適な速度で利用できるか？（応答性）」を測る指標
ページロード時間、Web Vitals
画面のロードの遅れや操作に対する反応の遅れがあるとユーザーのフラストレーションが溜まりますし、遅延して描画がずれると誤操作の原因にもなります。ページロード時間やCore Web Vitals (Largest Contentful Paint、First Input Delay、Cumulative Layout Shift）と呼ばれる指標を計測し、ブラウザアクセス時にユーザーが体感している性能を把握します。
New Relicにおいては、Browserエージェントによりページロード時間やCore Web Vitalsが計測され、例えばページロードに関してはUI上、どのページが遅延しているかなど把握することが可能です。Core Web Vitalsの詳細に関してはこちらのブログを参照してください。
なお、Browserエージェントはブラウザで実行されるAjaxリクエストのパフォーマンスも計測します。ページロードやCore Web Vitalsのスコアが悪い場合は、その中で呼び出されているAjaxリクエストのパフォーマンスの影響を確認しましょう。
モバイルアプリのインタラクション時間、httpリクエスト応答性能
ブラウザ同様、モバイルアプリの画面の読み込みの遅延もユーザー体験の悪化につながります。画面描画時間や描画時のhttpリクエストの応答性能を監視し、画面描画の遅延を検知します。画面の読み込み時間はUI上以下のチャートで画面毎に確認できます。
バックエンドアプリ応答性能
ブラウザの画面表示やAjax応答性能、モバイルのhttpリクエスト応答性能のいずれにおいてもバックエドのパフォーマンスの影響を受けますので、バックエンドのアプリケーションの応答性能も計測し、トランザクションの性能劣化を検知します。
APMエージェントがバックグラウンドのトランザクション性能を計測し、UI上は以下のチャートでトランザクション種別毎の応答性能を把握することができます。
なお、New Relicでは、分散トレーシングによって、モバイルアプリやブラウザアプリなどのクライアントからバックエンドのアプリ含めてスタック横断の処理を一筆書きのようにトレースをすることが可能です。例えば、以下の画面ではブラウザからのAjaxリクエストがバックエンドのアプリ2つを介してレスポンスを返していますが、各コンポーネントの処理時間やエラーの発生有無を俯瞰してみることができます。これによりユーザーに影響を与えている性能劣化やエラーの原因をフロントからバックエンドまでシームレスに見ながら特定することができます。
CDNのキャッシュヒット率
ECの場合、商品画像の配信にCDNを利用するケースも多いですが、キャッシュが意図した通りに効いているかでどうかで体感性能は変わってきます。したがい、キャッシュヒット率も見ておくべき指標の1つです。CDNのデータの連携については、こちら（Fastly）やこちら（AWS CloudFront）を参照してください。
ユーザー視点・ビジネス視点での分析
ここまでユーザー体験を把握するための観点と指標について述べてきました。これに加えて、以下の点を意識しておくことが重要です。
ユーザー利用環境の把握
ユーザー体験は、ユーザー自身が利用しているデバイスやブラウザ、アクセスしている地域、キャリアによっても変わってきます。何か問題が発生した場合も、その問題が一部のユーザーだけで発生するのか、共通する問題なのかによって対応が変わってきます。ユーザー利用環境を計測しておくことで、これまでユーザーに聞かないと把握できなかった問題に対してプロアクティブに対応できますし、情報がなく再現性がないため泣き寝入りしていた問題に対しても対応していくことが可能になります。
カスタマージャーニーと見るべき指標の選定
ユーザーがサイトにアクセスして購入するまでの一連プロセスと、その中でどの画面や操作が特に重要かを明らかにすることが重要です。言い換えれば、カスタマージャーニーを描くことといえます。例えば、ログイン処理や決済処理などが特に重要な処理に該当するでしょう。カスタマージャーニーにおいて重要な画面や操作毎に、これまで挙げた指標を計測しておくことで、ユーザー体験に大きな影響を及ぼす問題を確実に拾っていくことと対応の優先度付けが可能になります。
ビジネスKPIとシステムパフォーマンスの相関を見る
ビジネス上のKPIを意識し、そのKPI達成に貢献する施策を効果的に打つことがROIの観点から重要です。例えば、利用ユーザーが購入までの割合（コンバージョン率）が重要な場合は、購入までの過程のどこで多く離脱しているかと、パフォーマンスやエラーの発生率を相関づけ、システムの問題がビジネスKPIに影響している傾向がみられればそこを優先的に改善することができます。また、あまり利用されておらず（アクセスが少なく）、ビジネス上も重要度の相対的に低い機能や画面はエンハンス対象から外すといった判断もすることができます。
以下のチャート群は、ビジネスKPI（コンバージョン）とシステムパフォーマンスを組み合わせたものです。例えば、購入に至る割合が期待より低く、消費リストや購入ページでの離脱が多い場合に、各ページの表示時間やエラーの発生率との相関を把握できます。これにより、表示性能の改善やエラー率低下の原因解消をすることで離脱の原因を取り除き、ビジネスKPIを改善することができる可能性があります。
まとめ
本ブログでは、ECのユーザー体験を把握し、改善するために考慮すべき点や見るべき指標について説明しました。「ユーザーはちゃんとアクセスできるか」「トラブルなく購入できるか」「快適な速度で利用できるか」、システム運用をしていてもこれらの問いにきちんと答えられるかを省み考慮できていないものがある場合には、是非、観測の範囲を広げてユーザー体験の改善に繋げていきましょう。
本ブログで説明した内容についてデモを交えて解説しているセミナーの録画も是非ご覧ください。
売上に貢献するECシステム運用のポイント
New Relicの主要機能については、以下のページにて動画で解説していますので是非見てください。
New Relic One の主要機能
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
