このガイドでは、カスタマーエクスペリエンスを理解、測定、および改善するための高品質の基盤を確立する方法について説明します。これは、可観測性の成熟度に関するシリーズの一部です。
概要
デジタルカスタマーエクスペリエンスとは、すべてのデジタルタッチポイントでのエンドユーザーエクスペリエンスを指します。ユーザーエクスペリエンスに影響を与える4つの主要な要因があります。
- 可用性：到達可能ですか？
- パフォーマンス：使用できるほど十分にパフォーマンスがありますか？
- コンテンツの品質：ユーザーが必要とするものがあり、見つけることができますか？
- 製品とコンテンツの関連性：ユーザーが気にかけていることはありますか？
デジタルカスタマーエクスペリエンスには、ウェブ、モバイル、IoTなどがあります。このガイドの最初のバージョンでは、エンドユーザーのウェブ体験の測定に焦点を当てています。
このQualityFoundationガイドは、デジタルカスタマーエクスペリエンスを有意義な方法で理解するのに役立つ標準的なプラクティスを作成することを目的としています。この実装ガイドは次のことに役立ちます。
カスタマーエクスペリエンスに関連して見てみましょう。
- 検索やログインなどのグローバル機能
- 事業内容
- 地域
ビジネスのステークホルダーが関心を持っていることを報告する
取り組む内容の優先順位を決める
再現性のある練習方法の確立
望ましい結果
エンドユーザーの体験に沿った形でパフォーマンスを測定・改善することで、カスタマーエンゲージメントとリテンションを向上させる。
主要業績評価指標
このガイドでは、次のKPIを測定します。
KPIごとに、しきい値を定義しました。1つは警告状態用、もう1つはクリティカル状態用です。これらの値がどこから来ているのか、またはそれらがアプリケーションに適用されることをどのように確認できるのかを尋ねる場合があります。私たちのしきい値は、多数の顧客とアプリケーションにわたる私たちの経験に基づいて、Google（Core Web Vitalsの場合と同様）または私たちが推奨するものです。それらが異なるはずだと強く感じた場合は、それらを調整することができますが、これは、アプリケーションごとではなく、組織レベルで行う必要があります。
この品質基盤ガイドは、ユーザーの維持、変換、満足度を最適化するために、アプリケーションのどこで改善を行う必要があるかを特定するのに役立ちます。それは物事がどこにあるかではなく、どこに行くかについてです。
また、今後測定する必要があるものも示します。これを使用して、（サービスレベルダッシュボードで）サービスレベル目標（SLO）を定義し、それらにアラートを出すことができます。
前提条件
必要な知識
次の基本的な知識が必要です。
必要なインストールと構成
シンセティック・モニターの設定
- 匿名ユーザー用に設定されたPingモニター
- ログインフローに設定されたスクリプトによる合成チェック
- モニターは、ユーザーに適用されるすべての地域から テストを行うように設定されている必要があります。
- モニターは、各ドメインと各ログインフローに設定する必要があります。
平均スプリントの2倍以上のブラウザイベントのデータ保持
現在の状態を確立する
現在の状態を確立するには：
- インストルメントページの確認
- ブラウザのURLグループ化を検証する
- データをどのようにセグメント化するかを理解する
- Quality Foundationのダッシュボードのインポート
- ダッシュボードの各ページの現在のパフォーマンスを把握
これらの手順については、以下で詳しく説明します。
インストルメントページの確認
ブラウザのアプリとページを見直して、NewRelicに報告することを期待しているすべてのものが実際にそうしていることを確認します。これを行うには、ブラウザの監視UIの[ページビュー]タブを確認するか、次のクエリを実行します。
SELECT uniques(pageUrl) from PageView LIMIT MAXリクエストIDや顧客IDを含むURLをフィルタリングする必要があるかもしれません。
ブラウザのURLグループ化を検証する
ブラウザセグメントが正しくキャプチャされていることを確認して、NRQLを介してクエリを実行するときに、NewRelicUIと集計レベルの両方でユーザーエクスペリエンスのパフォーマンスを測定できるようにします。
セグメントは、URL内の2つの/の間、またはドメイン名の.の間のテキストです。たとえば、URL website.com/product/widget-nameでは、セグメントは次のとおりです。
website.comproductwidget-name
セグメントの多いURLが多い場合、URLが要約される可能性があるため、 website.com/product/widget-nameはwebsite.com/またはwebsite.com/product/になります。この例では、最初の要約URLは特に有用ではありませんが、2番目の要約URLは、製品の顧客体験データを集約するための有用な方法である可能性があります。
構成を調整する必要があるかどうかわからない場合は、役立つセグメント許可リスト調査ダッシュボードをインポートします。
追加するセグメントを特定したら、ブラウザのセグメント許可リストを使用してそれらを追加できます。
データをどのようにセグメント化するかを理解する
顧客体験データをさまざまなセグメントに分割することで、理解しやすく実用的なものにします。この場合、セグメントはデータのグループを参照します。 セグメント許可リストのように、URLのセクションを参照しません。
以下の記述について考えてみましょう。
- ほとんどのユーザーが、最初の入力から3秒以上の遅れを感じています。
- 最大のコンテンツフル・ペイントには、平均して2秒の時間がかかっています。
- 先週のページビューは100万でした。
と比較しています。
- 米国、カナダ、EMEAのほとんどのユーザーは、最初の入力までの遅延が2秒以下となっています。マレーシアとインドネシアのユーザーには4秒の遅延が発生しており、これについては調査中です。
- 自動車保険を購入する顧客は、通常、1秒から最大の満足のいく塗料を目にします。住宅保険の場合、4秒です。
- 先週、モバイルブラウザアプリのページビューは700,000でしたが、デスクトップのページビューは300,000でした。モバイルエクスペリエンスを最適化していることを確認しましょう。
代表的なセグメンテーションでは、ユーザーエクスペリエンスを以下のように分類しています。
セグメント | ガイダンス |
|---|---|
地域/場所 | 基本： 国別にグループ化します。ブラウザのイベントには、リクエストの国コードが自動的に含まれているので、さらに分けて考える必要はありません。 詳細：ブラウザの監視でカスタム属性を使用して独自の地域属性を作成することにより、地域グループを地域SLOグループと一致させます。
関連する属性
|
デバイス | パフォーマンスとエンゲージメントのデバイスタイプを分けて、理解できるようにする。
|
製品/事業部門 | このシナリオでは、製品とは、組織が提供する独立したビジネスラインまたはサービスのことです。業界とそれぞれの製品の例をいくつか挙げます。
|
環境 | インストルメンテーション中またはその後は、ブラウザーアプリの環境を指定する命名規則に従ってください。よく名付けられたブラウザアプリは、製品や機能、および環境を指定します。例：
|
チーム | 一部の組織では、単一のチームが複数の製品をサポートしますが、他の組織では、製品が複数のチームでサポートされるのに十分な大きさです。 New Relicのブラウザアプリ名にチーム名を追加するか（たとえば、 |
Quality Foundationのダッシュボードのインポート
この手順では、カスタマーエクスペリエンスを測定して改善するために使用するダッシュボードを作成します。これをする：
- QualityFoundationクイックスタートに移動します。
- クイックスタートの指示に従ってダッシュボードをダウンロードし、データの分割方法に合わせてダッシュボードをカスタマイズします。
- ダッシュボードは、チームではなく、ビジネスラインや顧客向け製品に合わせて作成してください。これにより、最適化のための時間を最も効果的な場所に費やすことができます。
ダッシュボードの各ページの現在のパフォーマンスを把握
Quality FoundationGitHubREADMEの指示に従ってください。
前の手順のダッシュボードを使用して、各事業部門の全体的なパフォーマンスを理解します。必要に応じて、フィルターを適用して、地域またはデバイス全体のパフォーマンスを確認します。値が目標を下回り、それが重要な場合は、改善の候補としてシートに追加します。追跡値の例：
- 追跡する価値はない。米国で保険を販売している会社が、マレーシアでのパフォーマンスの低さに気づく。
- 追跡する価値がある。米国で保険を販売している会社が、米国のモバイルユーザーに関してのみパフォーマンスが低いことに気づく。
改善プロセス
このプロセスの改善に関連する重要な手順は次のとおりです。
- あなたの仕事を計画する
- どのKPIを改善するかを決める
- 対象となるKPIの改善
- ページの読み込みパフォーマンスを向上させる
- AJAXのレスポンスタイムの向上
- AJAXエラーレートの改善
- JavaScriptエラーの改善
これらの手順については、以下で詳しく説明します。
あなたの仕事を計画する
パフォーマンスを向上させるための専用の取り組みを行っている場合でも、継続的なメンテナンスに分類している場合でも、スプリントの終わりごとに進捗状況を確認する必要があります。
どのKPIを改善するかを決める
これで、複数のビジネスラインでのユーザーエクスペリエンスがわかったと思います。どこを改善すべきでしょうか？
- ビジネスの優先順位から始めます。明確なビジネス指令がある場合、またはその上にいる上級管理職にアクセスできる場合は、組織にとって最も重要なことに集中する必要があります。たとえば、あなたの会社が最近、基幹業務に関する新しいイニシアチブを開始したが、UIに関連付けられたKPIが目標を下回っているとします。これは、最初に時間を集中する必要がある場所です。
- 次に、ビジネスラインごとのKPIに焦点を当てます。
- 最後に、各ビジネスラインをデバイスや地域などでフィルタリングし、特定の地域やデバイスに対してさらなるフォーカスが必要かどうかを確認します。
対象となるKPIの改善
進行状況を追跡するには、新しいダッシュボードを作成するか、既存のダッシュボードに新しいページを追加して、 Quality Foundation KPI Improvementという名前を付けます。詳細については、「 Web稼働時間の改善」を参照してください。
ページの読み込みパフォーマンスを向上させる
目標KPI値を満たしていない特定のページに焦点を絞ります。
Quality Foundationダッシュボードで範囲外のページロードKPI結果ごとに、 COMPARE WITH句を削除し、 FACET pageUrl/targetGroupedUrl LIMIT MAXを追加して、パフォーマンスの低いページを見つけます。
結果が多い場合はtargetGroupedUrlを使用します。たとえば、顧客IDがURLの一部である場合です。それ以外の場合は、 pageUrlを使用します。
元のダッシュボードクエリ：
FROM PageViewTiming SELECT percentile(largestContentfulPaint, 75) WHERE appName ='WebPortal' AND pageUrl LIKE '%phone%' SINCE 1 week AGO COMPARE WITH 1 week AGO問題のあるページを特定するための新しいクエリです。
FROM PageViewTiming SELECT percentile(largestContentfulPaint, 75) WHERE appName ='WebPortal' AND pageUrl LIKE '%phone%' FACET targetGroupedUrl LIMIT MAX改善するページを特定したら、「ページの読み込みパフォーマンスを改善する」のガイダンスを参照してください。
AJAXのレスポンスタイムの向上
次の手順を使用して、遅いリクエストを見つけます。
- ダッシュボードのAJAX期間ウィジェットに移動します。
- クエリを表示し、クエリビルダで開きます。
- クエリの最後に
facet requestUrl LIMIT MAXを追加します。 - クエリを実行します。
- 結果を表として表示し、KPI改善ダッシュボードに
LOB - AjaxResponseTimesとして保存します。 timeToSettle>2.5秒でリクエストの改善に焦点を合わせます。
New Relicが推奨するベストプラクティスを使用して、応答時間を改善します。 AJAXのトラブルシューティングのヒントを参照してください。
AJAXエラーレートの改善
失敗したリクエストを見つけます。
Dashboards> Query builderにアクセスします。
次のクエリを入力して実行します。
FROM AjaxRequestSELECT percentage(count(*), WHERE httpResponseCode >= 400)WHERE httpResponseCode >= 200 AND <Ajax Request filter>SINCE 1 week AGO facet pageUrl, appName結果を表として表示し、KPI改善ダッシュボードに
LOB - Pages with AjaxErrorsとして保存します。最も問題のあるページについて再度クエリを実行し、失敗しているリクエストを見つけます。
FROM AjaxRequest SELECT percentage(count(*), WHERE httpResponseCode >= 400) WHERE httpResponseCode >= 200 AND pageUrl=PROBLEMATIC_PAGE AND appName = YOUR_APP_NAME <Ajax Request filter> SINCE 1 week AGO facet requestUrl
New Relicが推奨するベストプラクティスを使用して、応答時間を改善します。 AJAXのトラブルシューティングのヒントを参照してください。
JavaScriptエラーの改善
最も一般的な障害を見つけます。
Go to Dashboards> Query builder
次のクエリを入力して実行します。
FROM JavaScriptErrorSELECT count(errorClass)SINCE 1 week AGO WHERE <PageView filter>FACET transactionName, errorClass, errorMessage, domain結果を表として表示し、KPI改善ダッシュボードに
LOB - Javascript Errorsとして保存します。この情報を使用して、対処する必要のあるエラーを特定します。 New Relicが推奨するベストプラクティスを使用して、対処が必要なエラーを解決します。 JavaScriptエラーページ：エラーの検出と分析を参照してください。
付加価値を生まないサードパーティのエラーを削除する。
サードパーティ製のJavaScriptを使用していて、ノイズが多いが期待通りの動作をしている場合があります。いくつかの方法があります。
- JavaScriptエラー/ページビュー比率ウィジェットからドメイン名を削除し、それを独自のウィジェットとして追加して、予期しない変更を確認できるようにします。 ベースラインNRQLアラートを使用してこれについてアラートを出すことができます。
- ドロップフィルターを使用してJavaScriptエラーをドロップします。このオプションは、エラーの量がデータの取り込みに大きな影響を与えている場合にのみ使用してください。ドロップフィルターでできるだけ具体的にしてください。
結論
採用するベストプラクティス：
- 各スプリントの最後に、パフォーマンスメトリクス（このドキュメントでは品質基盤KPIとして共有）を再検討します。
- パフォーマンスの改善を開発者のスプリントに組み込む。
- サポートしている事業部門やその他の内部の利害関係者とメトリックをオープンに共有します。
- カスタマーエクスペリエンスSLOを定義します。
- 品質基盤KPIのビジネスクリティカルな低下に関するアラートを作成します。
価値の実現
このプロセスの最後に、次のことを行う必要があります。
- エンドユーザーの体験を、具体的で実行可能な方法で理解し、エンジニアやビジネスが理解しやすいようにします。
- リリースがエンドユーザーにどのように影響するかを理解します。
- サービス、インフラ、ネットワークレベルのイベントがお客様にどのような影響を与えるかを把握することができます。
- バックエンドサービスが存在する場合は、それによって引き起こされる遅延の問題を確認してください。
- 一緒に仕事をしているように、ビジネスオーナーと共通の言語を作成したか、作成するための道を進んでいます。これにより、新しいプロジェクトの承認と後援のための新しい道が開かれる可能性があります。