デジタルエクスペリエンスモニタリングとは？顧客の旅路を外側から観察する方法

あなたのアップタイムモニターは100%を報告しています。あなたのサーバーは180ミリ秒で応答しています。そして注文は火曜日の朝から30%減少しています。

デジタルエクスペリエンスモニタリング（DEM）はそのような状況のために存在します。サーバーサイドのメトリクスはインフラが応答したことを確認しますが、フランクフルトのショッピング客が中程度のAndroid端末で、支払いボタンの前に遅い支払いスクリプトがある状況で実際にチェックアウトを完了できるかどうかは示しません。

このトピックに関するほとんどのガイドは、従業員のラップトップやVPNトンネルを監視するITチーム向けのDEMを定義しています。このガイドはもう一つのバージョン、つまり収益を生み出す顧客向けのジャーニーを監視する方法を取り扱います。DEMが測定するもの、各データソースの盲点、実際の店舗での設定方法、そしてDotcom-Monitorのどのチェックがそれぞれの障害を検知するかについて説明します。

このガイドの内容

• デジタルエクスペリエンスモニタリングとは？
• チェックアウトが壊れているのにダッシュボードがグリーンになる理由
• 合成モニタリング vs. RUM vs. ネットワークパス分析
• 収益パスで測定すべきこと
• アップタイムチェックが見逃す4つの障害
• デジタルエクスペリエンスモニタリングの設定方法
• デジタルエクスペリエンスモニタリングツールの選び方
• Dotcom-Monitorによるデジタルエクスペリエンスモニタリングの対応
• デジタルエクスペリエンスモニタリングよくある質問
• まとめ

デジタルエクスペリエンスモニタリングとは？

デジタルエクスペリエンスモニタリングは、ユーザーが自分のウェブサイトやアプリケーションをネットワーク、ブラウザ、使用デバイスを通じてどのように体験しているかをエンドツーエンドで測定する手法です。「サーバーが応答したか」ではなく、「誰かがここに来て何をしようとして、それを完了できたか、どのくらい時間がかかったか？」を問います。その測定は実際のセッションから、スクリプト化されたジャーニーをスケジュールで実行する方法から、あるいはその両方から得られます。

適用範囲はアップタイムより広く、DEM設定ではページのレンダリング、検索やチェックアウトなどのマルチステップトランザクション、それらのステップ背後のAPI、サードパーティスクリプト、さらには地域、ブラウザ、接続速度による変化も監視します。同じ手法はエンドユーザーエクスペリエンスモニタリング、アプリケーションエクスペリエンスモニタリング、またはデジタルエクスペリエンスマネジメントとして販売されることもあります。名称は異なっても、測定対象はほぼ同じです。

DEMには2種類あり混同される理由

この用語で検索すると、ページのトップはネットワークやセキュリティベンダーが多く、Palo Alto Networks、Fortinet、Cloudflare、ThousandEyes、Taniumなどが目立ちます。これらのページの多くは従業員向けで、エンドポイントの健康状態、SASEトンネル、リモートワーカーのラップトップとMicrosoft 365間の経路を監視する内容です。一部は顧客トラフィックもカバーしますが、結果の冒頭の定義は従業員向けに偏っています。

これは実際の問題を解決する本物のカテゴリですが、eコマースやデジタル運用チームの問題とは異なります。

顧客向けバージョンは外向きです。あなたのユーザーはあなたが管理しないネットワーク上の他人で、あなたが提供しなかったデバイスを使用し、チケットを出すことなく離脱します。壊れたプロモコード欄を報告する人はいません。彼らは競合へ移ります。

社員向けDEMは「なぜサラのZoomコールが途切れるのか」を答えます。顧客向けDEMは「なぜブラジルで昨夜カート完了率が18%減ったのか」を答えます。同じ略称でも、使用するツールも所有者も異なります。

このガイドの残りは後者についてです。

チェックアウトが壊れているのにダッシュボードがグリーンになる理由

よくある3つのセットアップがすべて同方向に失敗し、静かに失敗します。

アップタイムの確認は間違ったものをチェックしている。 ホームページのHTTPチェックは1つのURLが200を返したことを確認します。チェックアウトは「お支払いを処理できませんでした」というメッセージをページ内に表示しながら200を返すことがあります。ステータスコードはコンテンツについて何も判断しません。

サーバーサイドのメトリクスはエッジで止まる。 アプリの応答時間、CPU、エラー率はインフラを表しますが、DNS解決、TLSハンドシェイク、CDNエッジの挙動、サードパーティタグの実行、モバイルでメインスレッドを2.8秒間ブロックするチャットウィジェットは含みません。

リアルユーザーモニタリングは生存バイアスの問題がある。 リアルユーザーモニタリングはページ内のJavaScriptビーコンからデータを収集します。つまりページが読み込まれビーコンが発火したセッションのみを報告し、DNS障害、CDN403、TLSエラーに遭遇したユーザーはビーコンを読み込まないので報告しません。最悪の障害ほどRUMデータは少なくなり、静かに消えたトラフィックは売上の鈍い日として扱われます。

検知速度も3つすべてに影響します。多くの真の障害は短時間で、短時間の障害は誰もダッシュボードを見ていて気づきません。チェックが5分ごとなら4分の障害は両者の間に起きて終わり、注文が減ったという以外の証拠は残りません。

この3つのギャップを埋めるには3つの要素が必要です：自社インフラ外からのチェック、実際のブラウザでのレンダリング、ステータスコードではなくページ内容で結果を判断すること。これこそ合成モニタリングが行うことであり、このガイドが設定する内容です。

合成モニタリング vs. RUM vs. ネットワークパス分析

アナリストはDEMを通常3つの入力に分けます。これらは重なり合い、各々が他が見える場所で盲点を持ちます。

合成とRUMは多くのチームが実際に運用している組み合わせです。合成は誰かが起きていて買い物しているかに依存しない一定の信号を提供し、RUMは実際のユーザー層を示します。合成で検知・アラートを行い、修正優先度はRUMで判断します。

Dotcom-Monitorは表の1行目と3行目をカバーします。Webアプリケーション監視がスクリプト化されたブラウザジャーニーを実行し、インターネットインフラストラクチャチェックはDNS、TLS、ネットワーク層を監視します。RUMデータは収集しないので、実際のショッピングセッションの分析が必要ならRUMツールを併用してください。

合成には別の限界もあります：スクリプトしたジャーニーしか知らないため、一度もスクリプトされていないゲストチェックアウトは破損したまま一週間経過することもあります。

収益パスで測定すべきこと

メトリクスリストではなくジャーニーから始めましょう。ほとんどのeコマースやSaaSサイトでは4つのパスがリスクのほぼ全てを占めます：検索、カート追加、チェックアウト、ログイン。

それぞれについて追跡するもの：

• ステップ単位の成功。 各ステップが完了し、ページに期待したテキストが含まれていたか？確認番号はステータスコードより優れた指標です。EveryStepではコンテンツアサーションを各ステップに付け、テキスト、要素、HTTPステータス、レスポンスヘッダー、JSONペイロードをチェック可能です。
• ステップ単位の時間。 総ジャーニー時間は問題を隠すことがあります。たとえば「プロモコード適用」が400msから9秒に増え、他は変わらない場合を見たい。EveryStepのスクリプト時間ウォッチャーはステップごとに閾値を設定し、そのステップ単体で失敗を検知します。
• Core Web Vitals。 Largest Contentful Paint、Interaction to Next Paint、Cumulative Layout Shiftをコンバージョンするページで測定。Webページ監視でページごとに要素のウォーターフォールと共に報告されます。
• タイム・トゥ・ファーストバイト。 DNS、TLS、リダイレクト、CDNエッジの挙動、オリジンの遅延を含め最初の応答取得にかかる遅延を分離する指標。TTFBが速くページが遅い場合はフロントエンドの問題です。
• サードパーティ要素のタイミング。 支払いプロバイダー、タグマネージャー、チャットウィジェット、レビュー、広告ピクセル。サードパーティコンテンツモニタリングは、パッチできず迂回するしかない資産を監視します。ウォーターフォールチャートは各サードパーティリクエストを独立した行で表示し、どのベンダーが今月900ms遅くしたかを把握可能。証明書期限切れの支払いゲートウェイは自社の障害と同様にチェックアウトを停止させます。
• APIの応答時間と正確性。 インベントリ、価格、税金、配送、支払い呼び出しはファネルの各ステップ背後にあります。Webサービスチェックはこれらエンドポイントに直接アクセスし、レスポンスボディを検証するため、ページに到達する前に悪いペイロードを捕捉します。
• 証明書とDNSの健全性。 支払いサブドメインの証明書切れはチェックアウトを完全停止させ、SSL証明書監視とDNS監視をブラウザチェックと組み合わせて実施することで防げます。
• 地域差。 シカゴ、ロンドン、シンガポールから同じページを監視。地域毎の乖離は通常 CDN や DNS が原因でアプリケーションではないため、Dotcom-Monitorは1拠点ではなく30以上の世界各地から同じスクリプトを実行します。

アップタイムチェックが見逃す4つの障害

これらのそれぞれは緑色のアップタイムダッシュボードを残します。

1. 200 OKエラーページ

カード処理業者がAPI契約を変更。チェックアウトは例外をキャッチし「問題が発生しました。再試行してください」というフレンドリーなメッセージを表示し、HTTP 200を返します。インターネット上のすべてのアップタイムチェックはサイト正常として報告します。注文は停止。

解決策はコンテンツアサーションです：スクリプト化ジャーニーは注文確認番号を見つけなければならず、そうでなければステップ失敗になります。

検知するもの： 確認ステップにコンテンツアサーションを付与したWeb Applications (UserView)チェック。EveryStepは実際のレンダリングテキストを検証し、「問題が発生しました」はサーバーが200を返していてもチェック失敗になります。

2. モバイルだけに悪影響を与えるサードパーティスクリプト

マーケティングチームがパーソナライズタグを加えます。デスクトップではほぼ分からず、制限されたモバイル接続では支払いボタンがインタラクティブになるまで3秒遅延し、モバイルのコンバージョンが低下する一方、デスクトップは通常通り。タグマネージャーからのデプロイであるため1週間気付かれません。

同じEveryStepスクリプトを40以上のモバイルブラウザやデバイス、デスクトップで再生すると違いが明らかになります。両環境でステップごとのタイミング差を比較するとタグが単一の遅いステップとして現れ、「モバイルがなんとなく遅い」より具体的な洞察が得られます。

検知するもの： 同一のEveryStepスクリプトを複数環境で再生してタイミングを比較すること。

3. 地域的なCDNまたはDNS障害

CDN構成の更新が1つのポイントオブプレゼンスを破壊。サンパウロの顧客はエッジから403を受けJavaScriptを読み込みません。RUMではトラフィックが減るのではなくブラジルのセッションが来なくなるだけで、軽いトラフィック減に見えます。

サンパウロの監視ロケーションは最初のチェックで失敗します。これが1つのクラウドリージョンからのチェックではなくグローバル監視ネットワークが必要な理由です。

検知するもの： 30以上のロケーションからジャーニーを実行し、ウォーターフォールチャートと同期した動画記録で失敗を確認。ブラジルの顧客が見た403ページとリクエストをリアルタイムに把握、数日後のサポートチケット待ちを回避。

4. 障害ではなく劣化するAPI

配送料金サービスが300msから11秒へ遅延。エラーは返さずエラーレートアラートは鳴らず。顧客は配送ステップでスピナーを見て離脱。

検知するもの： 配送料金APIエンドポイントを対象に応答時間の閾値設定とレスポンスJSONのアサーションを行うWeb Services (WebView)チェック。ブラウザジャーニーのタイムアウトを待たずAPI自体で検知可能。

デジタルエクスペリエンスモニタリングの設定方法

これは何もない状態から始める場合や既存のアップタイムチェックに深みを加える場合にも有効です。

ステップ1：収益を生むジャーニーをマッピングする。 ファネルレポートを取り出し、実際に顧客がたどる3〜5のパスをリストアップ：検索、カート追加、ゲストチェックアウト、アカウントチェックアウト、ログイン。各パスの成功条件を正確に書き出します。

ステップ2：各ジャーニーをスクリプト化取引として記録する。 EveryStep Web Recorderでパスを一度クリック。クリック、フォーム記入、ナビゲーション、待機を捕捉し、ドロップダウン、モーダル、AJAXコンテンツ、iframeも含む。セレクターを書く必要なし。面倒な部分は手際よく扱う：クッキーバナー、動的な要素ID、一度きりのパスワード、誰にも課金されないテスト支払い方法。スクリプトには専用のテストアカウントとインベントリ安全なSKUを与え、モニタリングで実際の注文が発生しないようにします。これがウェブトランザクション監視です。

ステップ3：すべてのステップにアサーションを追加。 各ステップは「注文確認済み」「確認番号」「アイテム価格と一致するカート小計」など成功時のみ現れるテキスト・要素を検証します。EveryStepはHTTPステータス、レスポンスヘッダー、JSONペイロードのアサーションも可能で、ページが間違ってレンダリングされる前に悪いAPI応答で失敗させられます。アサーションなしでは再びステータスコードのチェックに戻ってしまいます。

ステップ4：トラフィックに合ったロケーション・デバイスを選ぶ。 アナリティクスから上位地域を取り出し、そこからモニタリング。サーバーの場所からではなく顧客の実際の場所から実行します。Dotcom-Monitorは30以上のロケーションと40以上のモバイルブラウザ・デバイスを提供し、実際の顧客に近い3〜4箇所を選び、1つ以上の制限付きモバイルプロファイルを加えましょう。モニタリング頻度とロケーションは実際の顧客を反映すべきです。

ステップ5：収益への影響で頻度を決める。 チェックアウトはキャリアページより高頻度に。完全なトランザクションスクリプトは単一ページチェックよりコストが高いため、注文の多い部分に予算を割り当てます。

ステップ6：下層サービスも監視。 ファネルが依存するAPI、DNS、TLS証明書、支払い経路のパートナーエンドポイントのチェックを追加。API監視は応答アサーションでブラウザジャーニーが後で示す劣化を事前に検知します。

ステップ7：人が動くようにアラート経路を設定。 誰かに電話や通知を送る前に、別地域で失敗を確認し誤検知を除外。ただし同リージョン内の第二ロケーションを使うこと。異大陸のノードを使うと、もともと検知したかった地域障害を抑制してしまうため。Dotcom-Monitorのアラートルールは閾値や確認ロジックを処理し、PagerDuty、Slack、Teamsへネイティブにプッシュ。チェックアウト失敗はすぐ担当者の目に届きます。

ステップ8：定期的にウォーターフォールを見直す。 週に一度、最も遅いジャーニーのウォーターフォールチャートを開き変化を確認。サードパーティ資産は徐々に増えた上で自己主張しません。失敗時はジャーニーの動画とウォーターフォールが同期しており、顧客が実際に見たものが10秒ほどで分かります。ウォーターフォールの読み方で数値を具体的な修正依頼に変え、公開ダッシュボードとメールレポートでコンバージョン問合せの担当者に数字を示せます。

デジタルエクスペリエンスモニタリングツールの選び方

ほとんどのベンダーはダッシュボードを見せてくれますが、以下の質問をクリアするものは少ないです。

• 実際のブラウザで動作するか？ HTTPレベルのチェックはJavaScriptを実行できず、モダンな店舗が初期応答後に行う処理を全て見逃します。
• マルチステップジャーニーのスクリプト作成は簡単か？ チェックアウトスクリプトに開発者が2日かかるなら、カートページが再設計された後は誰もメンテしません。
• どこからテストできるか？ 顧客と一致するロケーション数を数えましょう。北米に20ノードあっても欧州展開の役には立ちません。
• 内容をチェックできるか、ステータスだけか？ これがトランザクション監視と単なるおしゃれなPingの違いです。
• 障害時に根本原因データが得られるか？ ウォーターフォール、失敗時のスクリーンショット、失敗要素。単に「チェックアウト失敗」とだけ通知されては調査はゼロから始まります。
• インシデントワークフローに合うか？ PagerDuty、Slack、Teams、SMSやWebhookで届くアラートは対応されます。誰も開いていないダッシュボード内のアラートは対応されません。
• 内部環境やステージング環境に届くか？ プレプロダクションやファイアウォール内アプリはネットワーク内部にプライベートエージェントが必要です。
• ジャーニーを増やすと料金はどう変わるか？ ステップ毎や実行毎の課金は「深いジャーニー監視」を買いたいニーズに合いません。

Dotcom-Monitorによるデジタルエクスペリエンスモニタリングの対応

Dotcom-MonitorはDEMの合成側をカバーし、すべての検知レイヤーを支えます。4種類のデバイスタイプが顧客ジャーニー層に対応し、多くの店舗は4つすべてを使います。

ジャーニーはEveryStep Web Recorderでクリック操作でキャプチャされ、40以上のモバイルブラウザ・デバイスと30以上のグローバル監視ロケーションで再生されます。ステップごとに閾値で遅いステップを検知し、コンテンツアサーションで見た目は正常でも問題があるステップを捕捉。プライベートエージェントはステージングやファイアウォール内アプリでも同じチェックを実行し、悪いチェックアウトデプロイをリリース前に検知します。

正直に2つの注意点。Dotcom-Monitorは合成プラットフォームでありRUMデータは収集しないため、セッションレベル分析が必要ならRUMツールとの併用が必要です。またAPMではなく、どのステップが壊れたかを示し場所を見せますが、コードのどの行が原因かは示しません。両方必要なチームは小売・EC監視を内部APMと共に運用し、合成レイヤーを外側からの早期警戒として使います。

まとめ

デジタルエクスペリエンスモニタリングは「サーバーは動いている」と「顧客が購入できる」のギャップを埋めます。あなたがパフォーマンス問題で失っている収益の大半はこのギャップに潜みます：200 OKエラーページ、モバイルだけ遅いサードパーティスクリプト、RUMが見えない地域的CDN障害、エラーを返さず劣化するAPI。

大規模プログラムは不要です。一番価値の高いジャーニーを取り出しEveryStepでステップごとにアサーションを加え、実際の顧客がいる3地域から実行し、対応できる担当者にアラートを回しましょう。その1チェックで現在のダッシュボードの隠れ障害を検知できます。

それがきれいに1週間動作したら、次のジャーニーをスクリプトし繰り返し。多くのチームは3〜4回でファネル全体をカバーします。

デジタルエクスペリエンスモニタリングよくある質問