• /
  • English日本語
  • ログイン
  • 無料アカウント

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

英語版と齟齬がある場合、英語版の定めが優先するものとします。より詳しい情報については、本リンクをご参照ください。

問題を作成する

クオリティー・ファウンデーション導入ガイド

概要

デジタルカスタマーエクスペリエンスとは、デジタル上のすべてのタッチポイントにおけるエンドユーザーの体験のことです。ユーザーの体験に影響を与える4つのコアファクターがあります。

  • アベイラビリティ（到達可能であるか）
  • 性能（使えるだけの性能があるか？）
  • コンテンツの質（ユーザーが必要としているものがあり、それを見つけることができるか？）
  • 製品とコンテンツの関連性（ユーザーが気になっているものがあるか？）

デジタル・カスタマー・エクスペリエンス

デジタルカスタマーエクスペリエンスには、ウェブ、モバイル、IoTなどがあります。このガイドの最初のバージョンでは、エンドユーザーのウェブ体験の測定に焦点を当てています。

Quality Foundationは、デジタル・カスタマー・エクスペリエンスを意味のある形で理解するための標準的な手法を構築することを目的としています。

このインプリメンテーションガイドは、その手助けとなるものです。

  • カスタマーエクスペリエンスに関連して見てみましょう。

    • 検索やログインなどのグローバル機能
    • 事業内容
    • 地域

  • ビジネスのステークホルダーが関心を持っていることを報告する

  • 取り組む内容の優先順位を決める

  • 再現性のある練習方法の確立

望ましい結果

エンドユーザーの体験に沿った形でパフォーマンスを測定・改善することで、カスタマーエンゲージメントとリテンションを向上させる。

主要なパフォーマンス指標

Quality Foundationでは、以下のKPIを測定しています。

それぞれのKPIには、警告用と重要用のしきい値を設定しました。これらの値はどこから来ているのか、自分のアプリケーションに適用されることをどうやって確認できるのか、という疑問があるかもしれません。私たちのしきい値は、Google（Core Web Vitalsと同様）が推奨するもの、または多くのお客様やアプリケーションでの経験に基づいて私たちが推奨するものです。しかし、アプリケーションごとに調整するのではなく、組織レベルで調整する必要があります。

Quality Foundationは、ユーザーの維持、転換、満足度を最適化するために、アプリケーションのどこを改善する必要があるかを特定するのに役立ちます。これは、現在の状況よりも、どこに到達するかということを意味しています。

また、今後何を測定すべきかがわかります。これを利用して、 サービスレベル目標（SLO） （サービスレベルダッシュボードで）を定義し、それに基づいて警告を発することができます。

前提条件

必要な知識

必要なインストールと設定

現状の確立


インスツルメンテーションされたページの確認 ブラウザのURLグループ化の検証 データのセグメント化の方法の理解 品質基盤ダッシュボードのインポート ダッシュボードの各ページの現在のパフォーマンスの把握


インストルメントページの確認

ブラウザのアプリとページを確認し、New Relic に報告される予定のものがすべてあるかどうかを確認します。これを行うには、Browser UI の Page Views タブを確認するか、以下のクエリを実行します。

SELECT uniques(pageUrl) from PageView LIMIT MAX

リクエストIDや顧客IDを含むURLをフィルタリングする必要があるかもしれません。

ブラウザのURLグループ化の検証

ブラウザセグメントが正しく取得され、ユーザーエクスペリエンスのパフォーマンスがNewRelicのUIとNRQLでのクエリ時の集計レベルの両方で測定できるようにする。

セグメントとは、URL の 2 つの / の間、またはドメイン名の . の間のテキストのことです。例えば、URL website.com/product/widget-name の中で、セグメントは次のようになります。

  • ホームページ
  • .com
  • 製品
  • ウィジェット名

たくさんのセグメントを持つ URL があると、URL がつぶれてしまい、 website.com/product/widget-name が website.com/ または website.com/product/ となってしまうことがあります。この例では、1つ目の潰れたURLは特に有用ではありませんが、2つ目の潰れたURLは、その製品のカスタマーエクスペリエンスデータを集約するのに有効な手段であると考えられます。

設定を調整する必要があるかどうかわからない？GitHub にある Segment Allow List Investigation ダッシュボードをインポートして参考にしてください。

cx_segment_whitelist_investigation

追加するセグメントが決まったら、ブラウザ のセグメント許可リストを使って追加することができます。

データをどのようにセグメント化するかを理解する

カスタマー・エクスペリエンス・データを異なるセグメントに分けることで、理解しやすく、実用的なものにします。ここでいうセグメントとは、データのグループを指します。 segment allow lists のように、URL のセクションを意味するものではありません。

以下の記述について考えてみましょう。

  • ほとんどのユーザーが、最初の入力から3秒以上の遅れを感じています。
  • 最大のコンテンツフル・ペイントには、平均して2秒の時間がかかっています。
  • 先週のページビューは100万でした。

と比較しています。

  • 米国、カナダ、EMEAのほとんどのユーザーは、最初の入力までの遅延が2秒以下となっています。マレーシアとインドネシアのユーザーには4秒の遅延が発生しており、これについては調査中です。
  • 自動車保険を購入するお客様は、通常、1秒から最大のコンテンツフル・ペイントを見ます。家の保険の場合は、4秒です。
  • 先週のページビューは、デスクトップが30万件だったのに対し、モバイルブラウザアプリは70万件でした。モバイル体験を最適化するようにしましょう。

代表的なセグメンテーションでは、ユーザーエクスペリエンスを以下のように分類しています。

セグメント

ガイダンス

地域/場所

基本： 国別にグループ化します。ブラウザのイベントには、リクエストの国コードが自動的に含まれているので、さらに分けて考える必要はありません。

Advanced: 「ブラウザ」で カスタム属性 を使用して独自の地域属性を作成することにより、地域グループ化を地域の SLO グループと一致させます。

countryCodeによるファセット.

関連する属性

  • 地域コード
  • 市
  • asn緯度
  • asn経度

デバイス

パフォーマンスとエンゲージメントのデバイスタイプを分けて、理解できるようにする。

  • デスクトップとモバイルブラウザのユーザーの典型的な内訳

  • デスクトップとモバイルブラウザのユーザーの経験

    Facet by deviceType.

    関連する属性

  • ユーザーエージェント名

  • userAgentOS

  • userAgentVersion

製品／事業内容

このシナリオでは、製品とは、組織が提供する独立したビジネスラインまたはサービスのことです。業界とそれぞれの製品の例をいくつか挙げます。

  • 自動車保険と住宅保険の両方を販売する保険会社

  • 複数のストリーミングサービスやチャンネルを持つメディア企業

  • ホテルの予約だけでなく、レンタカーも提供する旅行会社

    Basic: 製品別にパフォーマンスをブレイクアウトする。

  • Faceting on pageUrl: New Relic で複数の製品が 1 つのブラウザアプリにまとめられている場合、この方法を使用します。

  • Faceting by appName: 各製品が個別のWebアプリとしてインストルメント化されている場合に、この方法を使用します。

  • Grouping by appName and then facet: この方法は、1つの製品をサポートするブラウザに複数のアプリがある場合に使用します。

    Advanced: カスタムアトリビュートを使用して、ブラウザページにカスタムアトリビュートとして製品提供を追加.

環境

インスツルメンテーションの際、またはその後に、ブラウザで環境を指定する命名規則に従ってください。適切に命名されたブラウザアプリは、環境だけでなく、製品や機能も指定します。例

  • アカウント管理.prod

  • hotels-book.prod

  • 自動車保険.uat

    アプリの命名規則を使用して環境を指定することで、UIとダッシュボードの両方でデータのフィルタリングがサポートされます。詳細については、 how to rename Browser apps のドキュメントを参照してください。

チーム

組織によっては、1 つのチームが複数の製品をサポートしている場合もあれば、1 つの製品が複数のチームによってサポートされるほど大きい場合もあります。カスタマーエクスペリエンスやエンゲージメントに対するチームのパフォーマンスをレポートするには、ブラウザアプリ名にチーム名を追加するか（例： account-management.prod.unicorn-squad ）、 カスタムアトリビュート を使用します。

Quality Foundationのダッシュボードのインポート

cx_qf_dashboard.png

このステップでは、カスタマーエクスペリエンスの測定と改善に使用するダッシュボードを作成します。

  1. GitHub リポジトリをクローンする.
  2. GitHubリポジトリのREADME の指示に従って、ダッシュボードを実装します。
  3. ダッシュボードは、チームではなく、ビジネスラインや顧客向け製品に合わせて作成してください。これにより、最適化のための時間を最も効果的な場所に費やすことができます。

ダッシュボードの各ページの現在のパフォーマンスを把握

cx_qf_kpi_progress.png

  1. GitHub README の指示に従ってください。

  2. 前のステップで作成したダッシュボードを使用して、各ビジネスラインの全体的なパフォーマンスを把握します。必要に応じてフィルターを適用し、地域やデバイスごとのパフォーマンスを確認します。値が目標値を下回り、それが問題となる場合は、改善候補としてシートに追加します。

    • 追跡する価値はない。米国で保険を販売している会社が、マレーシアでのパフォーマンスの低さに気づく。
    • 追跡する価値がある。米国で保険を販売している会社が、米国のモバイルユーザーに関してのみパフォーマンスが低いことに気づく。

改善プロセス


作業を計画する 改善するKPIを決める 対象とするKPIを改善する ページロードパフォーマンスを改善する AJAXレスポンスタイムを改善する AJAXエラーレートを改善する JavaScriptエラーを改善する




仕事の計画を立てる

パフォーマンスを向上させるための専用の取り組みを行っている場合でも、継続的なメンテナンスに分類している場合でも、スプリントの終わりごとに進捗状況を確認する必要があります。

どのKPIを改善するかを決める

これで、複数のビジネスラインでのユーザーエクスペリエンスがわかったと思います。どこを改善すべきでしょうか？

  1. まずはビジネスプロフェッショナルから。ビジネス上の明確な指示がある場合や、そのような指示を受けられるシニアマネージャーがいる場合は、組織にとって最も重要なことに焦点を当てるべきです。例えば、最近、あるビジネスラインに関連した新しい取り組みを開始したが、そのUIに関連するKPIが目標を下回っているとします。最初はここに時間を割くべきです。
  2. 次に、ビジネスラインごとのKPIに焦点を当てます。
  3. 最後に、各ビジネスラインをデバイスや地域などでフィルタリングし、特定の地域やデバイスに対してさらなるフォーカスが必要かどうかを確認します。

対象となるKPIの改善

進捗状況を確認するには、新しいダッシュボードを作成するか、既存のダッシュボードに新しいページを追加し、名前を Quality Foundation KPI Improvement とします。詳細については、 Improve Web Uptime をご覧ください。

ページロードパフォーマンスの向上

ターゲット KPI 値を満たしていない特定のページに焦点を絞ります。Quality Foundation ダッシュボードで範囲外となっている各ページロード KPI 結果について、 COMPARE WITH 節を削除し、 FACET pageUrl/targetGroupedUrl LIMIT MAX を追加して、どのページがパフォーマンスが低いかを見つけます。

targetGroupedUrl 結果が多数ある場合、例えば顧客IDがURLの一部である場合などに使用します。それ以外の場合は、 pageUrl を使用してください。

オリジナルのDashboardクエリ。

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のレスポンスタイムの向上

遅いリクエストを見つける。

  1. ダッシュボードのAjax durationウィジェットにアクセスします。
  2. クエリを表示し、クエリビルダで開きます。
  3. facet requestUrl LIMIT MAX をクエリの最後に追加します。
  4. クエリを実行します。
  5. 結果を表として表示し、KPI改善ダッシュボードに LOB - AjaxResponseTimes として保存します。
  6. timeToSettle > 2.5sのリクエストを中心に改善します。

レスポンスタイムを改善するために、New Relic が推奨するベスト プラクティスを使用します。 AJAX トラブルシューティングのヒント を参照してください。

AJAXエラーレートの改善

失敗したリクエストを見つける。

  1. Dashboards> Query builderにアクセスします。
  2. エンター
FROM AjaxRequest 
SELECT percentage(count(*), WHERE httpResponseCode >= 400) 
WHERE httpResponseCode >= 200 AND <Ajax Request filter>
SINCE 1 week AGO facet pageUrl, appName
  1. クエリを実行します。
  2. 結果を表として表示し、KPI改善ダッシュボードに LOB - AjaxErrorsを持つページ.
  3. 最も問題のあるページについて再度クエリを実行し、失敗しているリクエストを見つけます。
FROM AjaxRequest 
SELECT percentage(count(*), WHERE httpResponseCode >= 400) 
WHERE httpResponseCode >= 200 AND pageUrl=<problematic page> AND appName = <corresponding app> <Ajax Request filter> 
SINCE 1 week AGO  facet requestUrl

レスポンスタイムを改善するために、New Relic が推奨するベスト プラクティスを使用します。 AJAX トラブルシューティングのヒント を参照してください。

JavaScriptエラーの改善

最も多い失敗例を見つけてください。

  1. Go to Dashboards> Query builder
  2. エンター
FROM JavaScriptError 
SELECT count(errorClass) 
SINCE 1 week AGO WHERE <PageView filter>  
FACET transactionName, errorClass, errorMessage, domain
  1. クエリを実行します。
  2. 結果を表として表示し、KPI改善ダッシュボードに LOB - Javascript Errors として保存します。
  3. この情報を利用して、対処が必要なエラーを把握する New Relic の推奨するベストプラクティスを利用して、対処が必要なエラーを解決する。 JavaScript のエラーのページを参照してください。エラーの検出と分析.
  4. 付加価値を生まないサードパーティのエラーを削除する。

サードパーティ製のJavaScriptを使用していて、ノイズが多いが期待通りの動作をしている場合があります。いくつかの方法があります。

  • 予期せぬ変化を確認できるように、JavaScriptエラー/ページビュー比率ウィジェットからドメイン名を削除し、独自のウィジェットとして追加します。 Baseline NRQL のアラートを使用して、これを警告することができます。
  • ドロップフィルターを使用して、JavaScriptのエラーをドロップする 。このオプションは、エラーの量がデータの取り込みに大きな影響を与えている場合にのみ使用してください。ドロップフィルタには、できるだけ具体的な情報を入力してください。

結論

採用すべきベスト・プラクティス

  • 各スプリントの終わりにパフォーマンス指標（本文書ではQuality Foundation KPIとして共有）を再検討する。
  • パフォーマンスの改善を開発者のスプリントに組み込む。
  • 自分がサポートしているビジネスラインやその他の社内のステークホルダーとメトリクスをオープンに共有する。
  • カスタマーエクスペリエンスSLOの定義
  • Quality FoundationのKPIである business critical drops のアラートを作成します。

価値の実現

このプロセスの最後には、次のようになります。

  • エンドユーザーの体験を、具体的で実行可能な方法で理解し、エンジニアやビジネスが理解しやすいようにします。
  • リリースが最終顧客に与える影響を知る
  • サービス、インフラ、ネットワークレベルのイベントがお客様にどのような影響を与えるかを把握することができます。
  • バックエンドサービスに起因するレイテンシーの問題がある場合、それを確認する。
  • ビジネスオーナーとの間に共通言語を作り、一緒に仕事ができるようにしている。これにより、新しいプロジェクトに対する評価やスポンサーシップの道が開けます。
問題を作成する
Copyright © 2022 New Relic Inc.
採用情報サービス利用規約DCMAポリシープライバシー通知Cookieポリシー英国現代奴隷法