Esaminare le richieste di raccolta dati

L’analisi delle richieste mostra ciò che l’implementazione ha inviato, se un server ha risposto e, per Web SDK, come Edge Network ha elaborato l’evento. Questo articolo descrive le fasi di richiesta in uscita, ricezione server e elaborazione Edge del flusso di lavoro diagnostico.

Per scegliere uno strumento di ispezione, vedere Strumenti di debug. Per visualizzare le operazioni eseguite dall’implementazione prima dell’invio di una richiesta, vedere Abilitare la registrazione di debug. Per gli endpoint, i formati di richiesta e i passaggi di convalida che appartengono a un’applicazione Adobe specifica, vedere Debug specifico per il prodotto.

Controllare le richieste web web

Utilizza gli strumenti per sviluppatori del browser o un debugger tag per acquisire richieste da una pagina Web:

Gli strumenti del browser mostrano il traffico proveniente dal browser. Non espongono chiamate in uscita dal server applicazioni o da regole di inoltro degli eventi.

Leggi richieste Edge Network edge-network-requests

Per le implementazioni che utilizzano Adobe Experience Platform Web SDK, filtra le richieste di rete per:

/ee/

Seleziona la richiesta e analizzane il payload per visualizzare i dati inviati all’Edge Network. Questo filtro corrisponde al percorso di base predefinito di Web SDK. Se l’implementazione cambia edgeBasePath, filtrare per il percorso configurato o l’host della raccolta.

Gli URL di richiesta di Web SDK utilizzano il formato https://{edgeDomain}/ee/[{locationHint}/]v1/{action}?configId={datastreamId}&requestId={requestId}. Il valore predefinito edgeDomain è edge.adobedc.net. Le implementazioni di prime parti utilizzano il proprio CNAME. Le seguenti parti dell’URL sono prove utili:

Edge Network può inoltrare i dati ai servizi configurati nel flusso di dati. L’analisi della richiesta del client mostra ciò che il client ha tentato di inviare; non conferma di per sé la ricezione del server o l’elaborazione a valle.

Controllare le richieste per dispositivi mobili e server mobile-server

Per le implementazioni di Mobile SDK, aggiungi l’estensione Assurance all’app e collegala a una sessione Assurance per esaminare gli eventi SDK e le viste di convalida supportate. Utilizza un proxy di debug HTTP quando hai bisogno di prove a livello HTTP, in base al certificato e alla configurazione di rete dell’app. Per esaminare i messaggi negli strumenti di sviluppo nativi, vedere Registrazione SDK mobile.

Per Server SDK, dirigi Edge Network API o altre implementazioni lato server, controlla la richiesta in uscita del server, lo stato HTTP, il corpo della risposta e gli errori. Utilizza la strumentazione HTTP del tuo runtime o un proxy configurato per quel server. Una richiesta del browser all’applicazione non mostra la richiesta separata dal server ad Adobe. Per l’output di diagnostica SDK, vedere Registrazione SDK server.

Un registro SDK o una risposta HTTP corretta sono prove di una particolare fase della raccolta, non prove che tutte le destinazioni configurate abbiano elaborato l’evento.

Elaborazione Trace Edge Network edge-processing

Per le implementazioni di Web SDK, utilizza Edge Trace in Adobe Experience Platform Debugger per visualizzare la richiesta ricevuta da Edge Network, la configurazione dello stream di dati applicata e le richieste inviate ai servizi dello stream di dati. Anche Edge Trace apre gli stessi dati in una sessione di Assurance. Per le implementazioni di Mobile SDK, connetti direttamente l’app ad Assurance; vedi Richieste per dispositivi mobili e server.

Non trattare un evento in ingresso o un handle di risposta come conferma che ogni servizio a valle lo abbia elaborato. Continua con le linee guida per il debug dell’applicazione pertinente.

Per l’inoltro di eventi, Attività di monitoraggio fornisce report sull’utilizzo, sugli errori in uscita e sul tempo di calcolo. I rapporti aggregati possono aiutare a identificare le destinazioni che non riescono, ma non sono una traccia di consegna per evento.

Richieste interrotte aborted-requests

Quando una pagina si sposta, il browser può annullare le richieste ancora in corso. Firefox etichetta queste richieste NS_BINDING_ABORTED; Chrome e Edge le etichetta (canceled). Per mantenere visibili le richieste dopo la navigazione, abilita Mantieni registro (Chrome e Edge) o Mantieni registri (Firefox).

Una richiesta annullata non significa necessariamente che i dati siano andati persi. Il browser potrebbe aver inviato la richiesta completa e interrotto l’attesa solo della risposta. Le richieste che utilizzano navigator.sendBeacon() o fetch con keepalive possono continuare a inviare dopo la navigazione anche quando gli strumenti per sviluppatori visualizzano uno stato annullato. Se si mantiene visibile la voce, la consegna non viene confermata.

Per indagare, apri Debugger o un proxy prima di riprodurre la navigazione e controlla la richiesta acquisita e qualsiasi risposta del server. Una risposta del server acquisita fornisce la prova che l’endpoint ha gestito la richiesta; una richiesta in uscita da sola non lo fa. Per Web SDK, una richiesta in ingresso in Edge Trace fornisce prove lato server. Nessuna di queste osservazioni, da sola, stabilisce la disponibilità nelle relazioni a valle.

I browser non espongono la risposta HTTP da sendBeacon al JavaScript chiamante. Un messaggio di debug che segnala che SDK ha utilizzato sendBeacon non può quindi confermare la conferma.

documentUnloading di Web SDK seleziona un trasporto che supporta lo scaricamento soggetto a vincoli di identità e payload. Questa opzione non può inviare eventi ancora in coda al momento dello scaricamento della pagina. Vedere Quando gli eventi possono andare persi. Le librerie che inviano dati direttamente a un’applicazione Adobe possono fornire opzioni simili. Consulta le linee guida per il debug dell’applicazione.