Debug e risoluzione dei problemi di raccolta dati

Il debug della raccolta dati comporta la verifica sia del comportamento dell’implementazione che dell’esito dell’invio dei dati. Inizia con il sintomo, quindi segui l’evento attraverso ogni fase della raccolta fino a quando non trovi dove smette di comportarti come previsto.

La registrazione di debug espone i comandi SDK, l’esecuzione dei tag, gli avvisi e gli errori nel browser o nel runtime dell’applicazione. L’ispezione delle richieste espone payload, risposte e, per i flussi di lavoro supportati, l’elaborazione lato server. Questi approcci spesso si integrano a vicenda: un registro può spiegare perché un evento è stato ritardato, mentre un’acquisizione di rete può mostrare se una richiesta è stata inviata.

Segui l’evento attraverso la raccolta diagnostic-workflow

Esaminate le seguenti fasi in ordine. La prova del successo di una fase non dimostra che anche le fasi successive abbiano avuto successo.

  1. Esecuzione dell’implementazione: il comando SDK o la regola di tag è stata eseguita? Controlla i messaggi di diagnostica e gli errori. Se la gestione del consenso o dell’identità ritarda un evento, esamina tale stato prima di cercare una richiesta di rete. Vedi Abilitare la registrazione di debug.
  2. Richiesta in uscita: la richiesta è stata inviata e conteneva i dati previsti? Ispeziona il payload e confrontalo con gli input di comando o gli elementi di dati. Consulta Richieste Web di verifica o Richieste mobili e server di verifica.
  3. Conferma server: l’endpoint della raccolta ha ricevuto la richiesta? Esamina la risposta se disponibile o utilizza una traccia lato server supportata. Un registro client che riporta l’invio di una richiesta non conferma la ricezione.
  4. Elaborazione e routing di Edge: l’evento ha utilizzato lo stream di dati previsto e i servizi configurati? Per il Web SDK, il parametro configId della richiesta mostra quale flusso di dati ha utilizzato e Edge Trace mostra come Edge Network ha elaborato l’evento.
  5. Elaborazione a valle: la destinazione ha accettato ed elaborato l’evento come previsto? Utilizza le istruzioni di debug specifiche per prodotto della destinazione. In caso di esito positivo, la risposta di Edge Network non è la prova che i dati siano disponibili in ogni rapporto o archivio a valle.

Scegli un punto di partenza choose-a-starting-point

Nella tabella seguente vengono illustrate le prove utili per le attività comuni. Quando si applicano entrambi gli approcci, rispondono a diverse parti dell’indagine. I messaggi e gli strumenti disponibili dipendono dal SDK, dal runtime e dai servizi configurati.

Attività o sintomo
Debug logging
Richiedi ispezione
Controllo successivo
Non viene visualizzato un evento previsto
Controlla l’esecuzione dei comandi o delle regole, gli errori e i messaggi relativi al consenso o ai ritardi nell’identificazione.
Verifica se è stata emessa una richiesta e ne esamina il payload e la risposta.
Inizia con registrazione, quindi richieste di verifica. Per i sintomi correlati all’identità, vedere Risoluzione dei problemi di identità.
Una richiesta contiene dati imprevisti
Confronta gli input dei comandi e l’esecuzione dei tag di SDK con i valori che intendi inviare.
Controlla il payload in uscita effettivo; confrontalo con Edge Trace se sono coinvolte trasformazioni.
Controllare gli elementi dati, gli input di comando e la configurazione dello stream di dati.
Durante la navigazione viene visualizzata una richiesta annullata
Controlla se SDK ha tentato di inviare l’evento o se lo stava ancora tenendo.
Esamina la richiesta e, ove possibile, la risposta del server o Edge Trace. L’etichetta annullata del browser da sola non è conclusiva.
Vedi Richieste interrotte e Web SDK documentUnloading.
Le richieste vengono visualizzate correttamente, ma mancano i dati di destinazione
Stabilisci la configurazione e gli input utilizzati per l’implementazione. I registri client non possono confermare l’elaborazione a valle.
Utilizza Edge Trace, Assurance e la diagnostica specifica della destinazione.
Controlla lo stream di dati, i servizi abilitati, il routing e l’elaborazione della destinazione. Consulta Elaborazione Edge Network di traccia e Debug specifico per il prodotto.
Gli eventi appaiono duplicati
Cerca chiamate di comando ripetute o esecuzione di regole di tag.
Confronta i conteggi delle richieste, i payload e gli identificatori. Richieste client multiple non sono l’unica fonte possibile di duplicazione.
Analizza i nuovi tentativi e la consegna almeno una volta, nonché l’esecuzione ripetuta del client. Vedi Gestione duplicazione eventi.
Un’implementazione per dispositivi mobili o server si comporta in modo imprevisto
Esaminare l’output di SDK nell’applicazione o nel runtime del server, anziché solo nella console del browser.
Utilizza Assurance per i flussi di lavoro mobili supportati o controlla il traffico HTTP dell’applicazione. Gli strumenti del browser non possono mostrare le chiamate in uscita del server.
Consulta Registrazione di Mobile SDK e Server SDK e Richieste di verifica di dispositivi mobili e server.

Debug specifico per il prodotto product-specific

Gli articoli in questa sezione si applicano a tutta la raccolta dati di Experience Platform. Le applicazioni Adobe che ricevono i dati possono utilizzare i propri endpoint, i formati di richiesta, le visualizzazioni di convalida e l’elaborazione. Dopo aver confermato che Edge Network ha ricevuto e instradato un evento o quando l’implementazione invia i dati direttamente a un’applicazione, continua con le linee guida per il debug di tale applicazione:

Continua l’indagine next-steps

Prima di condividere registri, tracce o acquisizioni di rete, rimuovi le credenziali, gli identificatori dei visitatori e altre informazioni riservate in base ai criteri della tua organizzazione.

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