データ収集リクエストの調査

リクエストを調べることは、サーバーが応答したかどうか、およびWeb SDKの場合はEdge Networkがイベントをどのように処理したかを示します。 この記事では、診断ワークフローの送信リクエスト、サーバーレシート、およびEdgeの処理段階について説明します。

検査ツールを選択するには、​ ツールのデバッグ ​を参照してください。 実装がリクエストを送信する前にどのような処理を行ったかを確認するには、​ デバッグログを有効にするを参照してください。 特定のAdobe アプリケーションに属するエンドポイント、リクエスト形式、および検証手順については、製品固有のデバッグ ​を参照してください。

web リクエストの調査 web

ブラウザー開発者ツールまたは​ タグデバッガーを使用して、web ページからリクエストを取得します。

ブラウザーツール：ブラウザーからのトラフィックを表示します。 アプリケーションサーバーやイベント転送ルールからの発信コールは公開されません。

Edge Network リクエストの読み取り edge-network-requests

Adobe Experience Platform Web SDKを使用する実装の場合、次のネットワークリクエストをフィルタリングします。

/ee/

リクエストを選択し、そのペイロードを調べて、Edge Networkに送信されたデータを表示します。 このフィルターは、デフォルトのWeb SDK ベースパスと一致します。実装がedgeBasePathに変更された場合は、代わりに設定されたパスまたはコレクションホストをフィルタリングします。

Web SDK リクエスト URLは、https://{edgeDomain}/ee/[{locationHint}/]v1/{action}?configId={datastreamId}&requestId={requestId}という形式を使用します。 既定のedgeDomainはedge.adobedc.netです。ファーストパーティ実装では、独自のCNAMEが使用されます。 URLの以下の部分は有用な証拠です。

Edge Networkは、データストリームで設定されたサービスにデータを転送できます。 クライアントリクエストを調べることは、クライアントが送信しようとした内容を示します。それ自体では、サーバーの受信やダウンストリームの処理を確認しません。

モバイルとサーバーのリクエストの調査 mobile-server

Mobile SDKの実装の場合は、Assurance拡張機能をアプリに追加し、Assurance セッション ​に接続して、SDK イベントとサポートされている検証ビューを調べます。 HTTP レベルの証拠が必要な場合は、アプリの証明書とネットワーク設定に従って、HTTP デバッグプロキシ ​を使用します。 ネイティブ開発ツールのメッセージを調べるには、​ モバイルSDKのログ ​を参照してください。

Server SDK、ダイレクト Edge Network APIまたはその他のサーバーサイド実装の場合は、サーバーの送信リクエスト、HTTP ステータス、応答本文、エラーを調べます。 ランタイムのHTTP インストルメンテーションまたはそのサーバー用に設定されたプロキシを使用します。 アプリケーションへのブラウザーリクエストに、サーバーからAdobeへの個別のリクエストが表示されません。 SDKの診断出力については、Server SDKのログ記録を参照してください。

SDK ログまたはHTTP レスポンスが成功した場合は、収集の特定の段階に関する証拠であり、設定されたすべての宛先がイベントを処理したことを証明するものではありません。

トレース Edge Network処理 edge-processing

Web SDKの実装では、Adobe Experience Platform DebuggerでEdge Traceを使用して、Edge Networkが受信したリクエスト、適用されたデータストリーム設定、データストリームのサービスに送信したリクエストを確認します。 Edge Traceは、Assurance セッションで同じデータを開きます。 モバイル SDKの実装については、アプリをAssuranceに直接接続します。​ モバイルおよびサーバーリクエストの調査を参照してください。

受信イベントまたは応答ハンドルを、すべてのダウンストリームサービスが処理したことを確認するものとして扱わないでください。 関連アプリケーションの​ デバッグガイダンス ​に進みます。

イベント転送の場合、​ アクティビティの監視は、使用状況、送信エラー、計算時間のレポートを提供します。 集計レポートは、失敗した宛先の特定に役立ちますが、イベントごとの配信トレースではありません。

中断された要求 aborted-requests

ページが移動すると、ブラウザーは処理中のリクエストをキャンセルできます。 FirefoxはこれらのリクエストにNS_BINDING_ABORTEDというラベルを付けます。ChromeとEdgeはそれらを(canceled)というラベルを付けます。 ナビゲーション後にリクエストを表示するには、ログを保持 （ChromeとEdge）または​ログを保持 （Firefox）を有効にします。

キャンセルされたリクエストは、必ずしもデータが失われたわけではありません。 ブラウザーは完全なリクエストを送信し、応答の待ち時間のみを停止した可能性があります。 navigator.sendBeacon()またはfetchとkeepaliveを使用しているリクエストは、開発者ツールでキャンセル済みのステータスが表示された場合でも、ナビゲーション後に送信を続行できます。 ログを保持すると、エントリは表示され続けます。配信は確認されません。

調査するには、ナビゲーションを再生する前にデバッガーまたはプロキシを開き、キャプチャしたリクエストとサーバーの応答を調べます。 キャプチャされたサーバー応答は、エンドポイントがリクエストを処理したことを示す証拠を提供します。送信リクエストだけでは処理されません。 Web SDKの場合、Edge Traceの受信リクエストは、サーバーサイドのエビデンスを提供します。 これらの観察だけでは、下流レポートの可用性を確認することはできません。

ブラウザーは、sendBeaconから呼び出し元のJavaScriptへのHTTP レスポンスを公開しません。 SDKがsendBeaconを使用したことを報告するデバッグメッセージは、したがってレシートを確定できません。

Web SDKのdocumentUnloadingは、IDおよびペイロードの制約に従うアンロード対応トランスポートを選択します。 このオプションは、ページの読み込み解除時にまだキューに入っているイベントを送信できません。​ イベントが失われる可能性がある場合を参照してください。 Adobe アプリケーションに直接データを送信するライブラリでは、同様のオプションを提供できます。そのアプリケーションの​ デバッグガイダンス ​を参照してください。