Prüfen von Datenerfassungsanfragen
Beim Überprüfen von Anfragen wird angezeigt, was Ihre Implementierung gesendet hat, ob ein Server geantwortet hat und, bei Web SDK, wie die Edge Network das Ereignis verarbeitet hat. In diesem Artikel werden die Verarbeitungsschritte für ausgehende Anforderungen, Serverempfang und Edge des Diagnose-Workflows behandelt.
Informationen zum Auswählen eines Inspektionswerkzeugs finden Sie unter Debuggingwerkzeuge. Informationen zur Vorgehensweise Ihrer Implementierung vor dem Senden einer Anfrage finden Sie unter Debug-Protokollierung aktivieren. Informationen zu Endpunkten, Anfrageformaten und Validierungsschritten, die zu einem bestimmten Adobe-Programm gehören, finden Sie Produktspezifisches Debugging.
Web-Anfragen überprüfen web
Verwenden Sie Browser-Entwickler-Tools oder einen TagDebugger), um Anfragen von einer Web-Seite zu erfassen:
- Öffnen Sie die Entwicklertools: Drücken Sie F12 oder Strg+Umschalt+I (Windows und Linux) oder Befehlstaste+Wahltaste+I (macOS). Aktivieren Sie in Safari zunächst die Entwicklerfunktionen in den Safari-Einstellungen Erweitert.
- Wählen Sie die Registerkarte Netzwerk aus.
- Aktivieren Sie Protokoll beibehalten (Chrome und Edge) oder Protokolle beibehalten (Firefox), damit die Navigation die Anfrageliste nicht löscht.
- Filtern der Anfrageliste nach
/ee/(Web SDK). Wenn Ihre Implementierung Daten direkt an ein Adobe-Programm sendet, filtern Sie nach dem Endpunkt dieser Anwendung, wie in der Debugging-Anleitung beschrieben. - Reproduzieren Sie die Aktion. Anforderungen, die vor dem Öffnen der Tools gesendet wurden, werden nicht erfasst.
- Wählen Sie eine Sammlungsanfrage aus und überprüfen Sie deren URL, Payload, Antwort und Timing.
Browser-Tools zeigen Traffic an, der vom Browser ausgeht. Sie machen keine ausgehenden Aufrufe von Ihrem Anwendungsserver oder von Regeln für die Ereignisweiterleitung verfügbar.
Edge Network-Anfragen lesen edge-network-requests
Für Implementierungen, die Adobe Experience Platform Web SDK verwenden, filtern Sie Netzwerkanfragen nach:
/ee/
Wählen Sie die Anfrage aus und überprüfen Sie deren Payload, um die an die Edge Network gesendeten Daten anzuzeigen. Dieser Filter entspricht dem standardmäßigen Web SDK-Basispfad. Wenn sich Ihre Implementierung edgeBasePath ändert, filtern Sie stattdessen nach dem konfigurierten Pfad oder Sammlungs-Host.
Web-SDK-Anfrage-URLs haben das Format https://{edgeDomain}/ee/[{locationHint}/]v1/{action}?configId={datastreamId}&requestId={requestId}. Der edgeDomain ist edge.adobedc.net. Erstanbieterimplementierungen verwenden ihren eigenen CNAME. Die folgenden Teile der URL sind nützliche Beweise:
interact-Aktion Der Standard. Die Edge Network gibt Antwortinhalte wie Identität, Personalisierung, Warnungen und Fehler zurück, die Sie in der Antwort der Anfrage überprüfen können.collectAktion: Wird verwendet, wenn Web SDK ein Ereignis mitsendBeaconsendet, dasdocumentUnloadingnach der Identitätsfeststellung auswählt. Diese Anfragen geben keinen Antwortinhalt an die Seite zurück.configId-Parameter: Die von der Anfrage verwendete Datenstrom-ID. Wenn das Ereignis eine Datenstrom-ID-Überschreibung verwendet, enthält dieser Parameter die Überschreibung. Vergleichen Sie sie mit dem erwarteten Datenstrom.
Der Edge Network kann Daten an die Services weiterleiten, die in Ihrem Datenstrom konfiguriert sind. Die Überprüfung der Client-Anfrage zeigt an, was der Client zu senden versucht hat. Sie bestätigt allein nicht den Servereingang oder die nachgelagerte Verarbeitung.
Überprüfen von Mobil- und Server-Anfragen mobile-server
Fügen Sie bei Mobile SDK-Implementierungen die Assurance-Erweiterung zu Ihrer App hinzu und verbinden Sie sie mit einer Assurance-Sitzung um SDK-Ereignisse und unterstützte Validierungsansichten zu überprüfen. Verwenden Sie einen HTTP-DebuggingProxy, wenn Sie Beweise auf HTTP-Ebene benötigen, abhängig vom Zertifikat und der Netzwerkkonfiguration Ihrer App. Informationen zum Überprüfen von Nachrichten in nativen Entwicklungs-Tools finden Sie unter Mobile SDK-Protokollierung.
Überprüfen Sie bei Server-SDK, direkter Edge Network-API oder anderen serverseitigen Implementierungen die ausgehende Anfrage des Servers, den HTTP-Status, den Antworttext und Fehler. Verwenden Sie die HTTP-Instrumentierung Ihrer Laufzeit oder einen für diesen Server konfigurierten Proxy. Bei einer Browser-Anfrage an Ihre Anwendung wird die separate Anfrage Ihres Servers an Adobe nicht angezeigt. Siehe Server-SDK-Protokollierung für die SDK-Diagnoseausgabe.
Ein SDK-Protokoll oder eine erfolgreiche HTTP-Antwort ist ein Beweis für einen bestimmten Sammlungsschritt, nicht der Beweis, dass alle konfigurierten Ziele das Ereignis verarbeitet haben.
Verfolgen der Edge Network-Verarbeitung edge-processing
Verwenden Sie bei Web SDK-Implementierungen Edge Trace in Adobe Experience Platform Debugger, um die von Edge Network empfangene Anfrage, die angewendete Datenstromkonfiguration und die Anfragen anzuzeigen, die an die Services in Ihrem Datenstrom gesendet wurden. Edge Trace öffnet dieselben Daten auch in einer Assurance-Sitzung. Stellen Sie bei Mobile SDK-Implementierungen eine direkte Verbindung zwischen der App und Assurance her. Siehe Überprüfen von Mobil- und Server-Anfragen.
Behandeln Sie ein eingehendes Ereignis oder eine eingehende Antwort nicht als Bestätigung, dass jedes nachgelagerte Service es verarbeitet hat. Fahren Sie mit der „DebuggingAnleitung“ der entsprechenden Anwendung .
Für die Ereignisweiterleitung bietet Aktivitäten überwachen Berichte über Nutzung, ausgehende Fehler und Rechenzeit. Die aggregierten Berichte können dabei helfen, fehlgeschlagene Ziele zu identifizieren, sind jedoch keine Versandverfolgung pro Ereignis.
Abgebrochene Anfragen aborted-requests
Wenn eine Seite die Seite verlässt, kann der Browser Anfragen abbrechen, die noch in Bearbeitung sind. Firefox kennzeichnet diese Anfragen NS_BINDING_ABORTED; Chrome und Edge kennzeichnen sie (canceled). Um Anfragen nach der Navigation sichtbar zu halten, aktivieren Sie Protokoll beibehalten (Chrome und Edge) oder Protokolle beibehalten (Firefox).
Eine abgebrochene Anfrage bedeutet nicht unbedingt, dass Daten verloren gegangen sind. Der Browser hat möglicherweise die vollständige Anfrage gesendet und nur auf die Antwort gewartet. Anfragen, die navigator.sendBeacon() oder fetch mit keepalive verwenden, können nach der Navigation weiterhin gesendet werden, selbst wenn Entwickler-Tools den Status „Abgebrochen“ anzeigen. Wird das Protokoll beibehalten, bleibt der Eintrag sichtbar; die Bereitstellung wird nicht bestätigt.
Um dies zu untersuchen, öffnen Sie Debugger oder einen Proxy, bevor Sie die Navigation reproduzieren, und überprüfen Sie die erfasste Anfrage und alle Server-Antworten. Eine erfasste Server-Antwort zeigt, dass der Endpunkt die Anfrage verarbeitet hat. Eine ausgehende Anfrage allein reicht nicht aus. Bei Web SDK liefert eine eingehende Anfrage in Edge Trace serverseitige Beweise. Keine dieser Beobachtungen allein belegt die Verfügbarkeit nachgelagerter Berichte.
Browser stellen die HTTP-Antwort von sendBeacon nicht für die aufrufende JavaScript zur Verfügung. Eine Debugmeldung, die meldet, dass der verwendete SDK sendBeacon den Empfang daher nicht bestätigen kann.
Der documentUnloading von Web SDK wählt einen entladbaren Transport entsprechend den Identitäts- und Payload-Beschränkungen aus. Diese Option kann keine Ereignisse senden, die sich beim Entladen der Seite in der Warteschlange befinden. Siehe Wenn Ereignisse verloren gehen können. Bibliotheken, die Daten direkt an ein Adobe-Programm senden, können ähnliche Optionen bereitstellen. Weitere Informationen finden Sie in der zu diesem Programm.