Inspecter les requêtes de collecte de données

L’inspection des requêtes indique ce que votre implémentation a envoyé, si un serveur a répondu et, pour Web SDK, comment Edge Network a traité l’événement. Cet article couvre les étapes de demande sortante, de réception du serveur et de traitement Edge du workflow de diagnostic.

Pour choisir un outil de contrôle, voir Outils de débogage. Pour connaître les effets de votre implémentation avant l’envoi d’une requête, consultez Activation de la journalisation du débogage. Pour les points d’entrée, les formats de requête et les étapes de validation appartenant à une application Adobe spécifique, consultez Débogage spécifique au produit.

Inspecter les requêtes web web

Utilisez les outils de développement du navigateur ou un débogueur de balises pour capturer les requêtes d’une page web :

  1. Ouvrez les outils de développement : appuyez sur F12 ou Ctrl+Maj+I (Windows et Linux) ou Cmd+Option+I (macOS). Dans Safari, commencez par activer les fonctionnalités de développement dans les paramètres avancés de Safari.
  2. Sélectionnez l’onglet Réseau.
  3. Activez Conserver le journal (Chrome et Edge) ou Conserver les journaux (Firefox) afin que la navigation n’efface pas la liste des requêtes.
  4. Filtrer la liste des demandes pour /ee/ (Web SDK). Si votre implémentation envoie directement des données à une application Adobe, filtrez le point d’entrée de cette application comme décrit dans ses conseils de débogage.
  5. Reproduisez l’action. Les requêtes envoyées avant l’ouverture des outils ne sont pas capturées.
  6. Sélectionnez une requête de collection et examinez son URL, sa payload, sa réponse et son timing.

Les outils du navigateur affichent le trafic provenant du navigateur. Ils n’exposent pas les appels sortants provenant de votre serveur d’applications ou de règles de transfert d’événement.

Lecture des requêtes Edge Network edge-network-requests

Pour les implémentations qui utilisent Adobe Experience Platform Web SDK, filtrez les requêtes réseau pour :

/ee/

Sélectionnez la requête et examinez sa payload pour afficher les données envoyées à Edge Network. Ce filtre correspond au chemin d’accès de base par défaut de Web SDK ; si votre implémentation change de edgeBasePath, filtrez plutôt le chemin d’accès configuré ou l’hôte de collection.

Les URL de requête de Web SDK utilisent le format https://{edgeDomain}/ee/[{locationHint}/]v1/{action}?configId={datastreamId}&requestId={requestId}. Le edgeDomain par défaut est edge.adobedc.net ; les implémentations propriétaires utilisent leur propre CNAME. Les parties suivantes de l’URL sont des preuves utiles :

  • interactaction : valeur par défaut. Edge Network renvoie le contenu de la réponse, tel que l’identité, la personnalisation, les avertissements et les erreurs, que vous pouvez examiner dans la réponse de la requête.
  • collectaction : utilisé lorsque Web SDK envoie un événement avec sendBeacon, que documentUnloading sélectionne une fois l’identité établie. Ces requêtes ne renvoient pas le contenu de la réponse à la page.
  • configIdparamètre : identifiant du flux de données utilisé par la requête. Si l’événement utilise un remplacement d’identifiant de flux de données, ce paramètre contient le remplacement. Comparez-le au flux de données attendu.

Edge Network peut transférer des données vers les services configurés dans votre flux de données. L’inspection de la requête du client montre ce que le client a tenté d’envoyer ; elle ne confirme pas en elle-même la réception par le serveur ou le traitement en aval.

Inspecter les requêtes mobiles et de serveur mobile-server

Pour les implémentations de Mobile SDK, ajoutez l’extension Assurance à votre application et connectez-la à une session Assurance pour inspecter les événements SDK et les vues de validation prises en charge. Utilisez un proxy de débogage HTTP lorsque vous avez besoin de preuves au niveau HTTP, sous réserve du certificat et de la configuration réseau de votre application. Pour examiner les messages dans les outils de développement natifs, voir Journalisation Mobile SDK.

Pour Server SDK, l’API Edge Network directe ou d’autres implémentations côté serveur, examinez la requête sortante du serveur, l’état HTTP, le corps de la réponse et les erreurs. Utilisez l’instrumentation HTTP de votre runtime ou un proxy configuré pour ce serveur. Une requête de navigateur à votre application n’affiche pas la requête distincte de votre serveur à Adobe. Voir Journalisation SDK du serveur pour obtenir une sortie de diagnostic SDK.

Un journal SDK ou une réponse HTTP réussie est la preuve d’une étape particulière de la collecte, et non la preuve que toutes les destinations configurées ont traité l’événement.

Trace du traitement d’Edge Network edge-processing

Pour les implémentations de Web SDK, utilisez Edge Trace dans Adobe Experience Platform Debugger pour afficher la requête reçue par Edge Network, la configuration de train de données appliquée et les requêtes envoyées aux services dans votre train de données. Edge Trace ouvre également les mêmes données dans une session Assurance. Pour les implémentations de Mobile SDK, connectez directement l’application à Assurance. Voir Inspecter les requêtes mobiles et de serveur.

Ne traitez pas un événement entrant ou un handle de réponse comme une confirmation que chaque service en aval l’a traité. Continuez avec les conseils de débogage de l’application appropriée.

Pour le transfert d’événement, la section Surveiller les activités fournit des rapports d’utilisation, d’erreur sortante et de temps de calcul. Ses rapports agrégés peuvent aider à identifier les destinations défaillantes, mais ne sont pas une trace de diffusion par événement.

Requêtes abandonnées aborted-requests

Lorsqu’une page quitte l’application, le navigateur peut annuler les requêtes qui sont toujours en cours. Firefox classe ces requêtes NS_BINDING_ABORTED ; Chrome et Edge les classent (canceled). Pour que les requêtes restent visibles après la navigation, activez Conserver le journal (Chrome et Edge) ou Conserver les journaux (Firefox).

Une demande annulée ne signifie pas nécessairement que des données ont été perdues. Le navigateur a peut-être envoyé la requête complète et cessé d’attendre uniquement la réponse. Les requêtes utilisant navigator.sendBeacon() ou fetch avec keepalive peuvent continuer à être envoyées après la navigation, même si les outils de développement affichent le statut annulé. La conservation du log permet de conserver la visibilité de l’entrée ; elle ne confirme pas la diffusion.

Pour effectuer une recherche, ouvrez Debugger ou un proxy avant de reproduire la navigation et examinez la requête capturée et toute réponse du serveur. Une réponse de serveur capturée fournit des preuves que le point d’entrée a géré la requête ; ce n’est pas le cas d’une requête sortante seule. Pour Web SDK, une requête entrante dans Edge Trace fournit des preuves côté serveur. Aucune de ces observations n’établit à elle seule la disponibilité dans les rapports en aval.

Les navigateurs n’exposent pas la réponse HTTP de sendBeacon au JavaScript appelant. Un message de débogage signalant que le SDK a utilisé sendBeacon ne peut donc pas confirmer la réception.

Le documentUnloading de SDK Web sélectionne un transport compatible avec le déchargement et soumis aux contraintes d’identité et de payload. Cette option ne peut pas envoyer les événements qui sont toujours en file d’attente au déchargement de la page. Consultez la section Lorsque des événements peuvent être perdus. Les bibliothèques qui envoient directement des données à une application Adobe peuvent fournir des options similaires. Consultez les conseils de débogage de cette application.

recommendation-more-help
experience-platform-help-collection