デジタル エクスペリエンスのパフォーマンスの現在の状態を確立したら、収集した情報を取得して、それを使用してカスタマー エクスペリエンスを向上させ始めます。ニーズはさまざまであるため、どの領域を改善する必要があるかを知ることができるのはあなただけです。次の手順は、顧客エクスペリエンスを向上させるために使用する推奨順序であり、最も関連性の高いものに注目し、そうでないものはスキップできます。これは継続的なプロセスであるため、将来 KPI が変更されたときに参照できるように、このページをブックマークしておくことをお勧めします。
現在の状態を確立すると、システム全体でのユーザー エクスペリエンスがどのように見えるかがわかります。そこから、次のどの領域を改善する必要があるかを判断する必要があります。
- ビジネスの優先順位から始める: ビジネス上の明確な指示がある場合は、組織にとって最も重要なことに焦点を当てる必要があります。たとえば、会社が最近、事業分野に関する新しい取り組みを開始したものの、UI に関連する KPI が目標を下回っている場合、これは取り組みに集中するのに最適な場所です。
- データを KPI に合わせる: 主要業績評価指標は、顧客にとって問題点となるシステムのさまざまな側面に関する洞察を提供します。そのデータを取得して KPI と比較し、どこを改善する必要があるかを確認します。
- 各セグメントをフィルタリングする: 前のドキュメントで作成した各セグメントをグループ化し、特定の地域、デバイス、またはその他の有用なグループ化にさらに焦点を当てる必要があるかどうかを確認します。
対象となるKPIの改善
進行状況を追跡するには、新しいダッシュボードを作成し (または既存のダッシュボードに新しいページを追加し)、 Quality Foundation KPI Improvementという名前を付けます。詳細については、 「Web 稼働時間の向上」を参照してください。
ページの読み込みパフォーマンスを向上させる
品質基盤ダッシュボードを作成したら、目標 KPI 値を満たしていない特定のページに焦点を絞ります。
品質基盤ダッシュボードで低いと報告されているページ読み込み KPI 結果ごとに、 COMPARE WITH 句を削除し、 FACET pageUrl/targetGroupedUrl LIMIT MAX を追加して、どのページのパフォーマンスが低いかを調べます。顧客 ID が URL の一部である場合など、多数の結果がある場合は、 targetGroupedUrl を使用します。それ以外の場合は、 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 応答時間は次のステップに進むのに最適です。遅い AJAX 応答時間を見つけるには:
- ダッシュボードのAJAX期間ウィジェットに移動します。
- View query [クエリの表示] を選択し、クエリ ビルダーで開きます。
- クエリの最後に
facet requestUrl LIMIT MAXを追加します。 - クエリを実行します。
- 結果を表として表示し、KPI改善ダッシュボードに
LOB - AjaxResponseTimesとして保存します。 timeToSettle>2.5秒でリクエストの改善に焦点を合わせます。
AJAX リクエストの改善の詳細については、 「AJAX トラブルシューティングのヒント」を参照してください。
AJAXエラーレートの改善
AJAX の応答時間を特定して改善したら、すでに AJAX を扱っているため、エラー率の改善にも進む必要があります。失敗したリクエストを見つけるには:
に行く
> 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 AjaxRequestSELECT 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不十分な AJAX エラー率を特定できたら、応答時間を改善する方法の詳細について、 AJAX トラブルシューティングのヒント を参照してください。
JavaScriptエラーの改善
改善プロセスを締めくくるには、過剰な JavaScript エラーの修正に重点を置く必要があります。最も一般的な失敗を見つけるには:
に行く
> Query builder
次のクエリを入力して実行します。
FROM JavaScriptErrorSELECT count(errorClass)SINCE 1 week AGO WHERE <PageView filter>FACET transactionName, errorClass, errorMessage, domain結果を表として表示し、KPI改善ダッシュボードに
LOB - Javascript Errorsとして保存します。この情報を使用して、どのエラーに対処する必要があるかを判断します。詳細については 、JavaScript エラー ページ: エラーの検出と分析に関する ドキュメントを参照してください。
価値を追加しないサードパーティのエラーを削除します。
ヒント
ノイズは多いものの期待どおりに動作するサードパーティの JavaScript を使用している可能性があります。次のようないくつかのアプローチを取ることができます。
- JavaScript エラー/ページビュー比率ウィジェットからドメイン名を削除し、それを独自のウィジェットとして追加して、予期しない変化を確認できるようにします。Anomaly NRQLアラートを使用して、これについてアラートを出すことができます。
- ドロップフィルターを使用してJavaScriptエラーをドロップします。このオプションは、エラーの量がデータの取り込みに大きな影響を与えている場合にのみ使用してください。ドロップフィルターでできるだけ具体的にしてください。
前進する
上記の手順を実行した後は、KPI を定期的に見直して、カスタマー エクスペリエンスが常に適切な品質であることを確認することをお勧めします。各組織には異なるニーズがあるため、使用する手順は組織ごとに異なります。ただし、次の提案に留意してください。
- 各スプリントの最後にパフォーマンスメトリックを再検討します。
- パフォーマンスの改善を開発者のスプリントに組み込む。
- サポートしている事業部門やその他の内部の利害関係者とメトリックをオープンに共有します。
- カスタマーエクスペリエンスSLOを定義します。
- ビジネス上の重要な品質基盤 KPI の低下に関するアラートを作成します 。