Diagnostica

Di seguito è riportato il flusso di lavoro consigliato per verificare lo stato dei caricamenti di eventi e segmenti di pubblico e identificare i problemi relativi ai dati.

  1. Invia richieste per inviare eventi o inviare o rimuovere membri del segmento di pubblico.

  2. Controlla lo stato generale di ogni richiesta. Una richiesta riuscita ha un Status con code uguale a 0 (valore enum OK, HTTP risposta 200 OK) e restituisce un IngestEventsResponse, IngestAudienceMembersResponse o RemoveAudienceMembersResponse.

    Se una richiesta non va a buon fine, modificala per risolvere l'errore e inviala di nuovo.

    Se una richiesta va a buon fine, acquisisci il request_id della risposta in modo da poterlo utilizzare per recuperare i dati diagnostici nel passaggio successivo.

  3. Attendi 30 minuti, poi invia una RetrieveRequestStatus richiesta per ogni request_id riuscito.

    Ripeti periodicamente questo passaggio per ogni request_id finché lo stato di destinazione per ogni destinazione non raggiunge SUCCESS, PARTIAL_SUCCESS, o FAILURE. Utilizza un algoritmo di backoff esponenziale per attendere tra una richiesta e l'altra.

  4. Esamina ogni RetrieveRequestStatusResponse per verificare che i caricamenti funzionino correttamente e identificare eventuali problemi con i dati.

  5. Correggi i problemi relativi ai dati.

  6. Torna al passaggio 1 e ripeti l'operazione finché non avrai risolto tutti i problemi relativi ai caricamenti.

Invio di richieste

Un RetrieveRequestStatusRequest richiede un singolo request_id valore. Invia una richiesta di stato separata per ogni ID richiesta acquisito da una richiesta di importazione riuscita.

Invia periodicamente RetrieveRequestStatusRequest utilizzando un algoritmo di backoff esponenziale finché request_status non raggiunge SUCCESS, FAILURE, o PARTIAL_SUCCESS per ogni destinazione nella richiesta originale. Questa operazione potrebbe richiedere fino a 24 ore, anche se l'API Data Manager potrebbe completare l'elaborazione di alcune richieste in soli 30 minuti.

Ecco un esempio di tempo di attesa iniziale e configurazione dei tentativi ragionevoli che bilanciano l'attività e l'utilizzo della quota:

Impostazione Valore
Tempo di attesa prima della prima richiesta di dati diagnostici (minuti) 30
Moltiplicatore di backoff 1.3
Backoff massimo (minuti) 60 (1 ora)
Tempo totale massimo (minuti) 1440 (24 ore)

Di seguito è riportata una sequenza di richieste e il tempo trascorso con questa configurazione:

Grafico

Strategia di polling

Dati

Tentativo Tempo trascorso dalla richiesta di importazione (hh:mm) Ritardo prima del tentativo Note
1 00:30 30,0 min Primo controllo della disponibilità dello stato
2 01:09 39,0 min
3 01:59 50,7 min
4 02:59 60,0 min Il ritardo è ora limitato a 1 ora
5 03:59 60,0 min
6 04:59 60,0 min
7 05:59 60,0 min
8 06:59 60,0 min
9 07:59 60,0 min
10 08:59 60,0 min
11 09:59 60,0 min
12 10:59 60,0 min
13 11:59 60,0 min Segno di 12 ore
14 12:59 60,0 min
15 13:59 60,0 min
16 14:59 60,0 min
17 15:59 60,0 min
18 16:59 60,0 min
19 17:59 60,0 min
20 18:59 60,0 min
21 19:59 60,0 min
22 20:59 60,0 min
23 21:59 60,0 min
24 22:59 60,0 min
25 23:59 60,0 min Ultima richiesta prima del tempo totale massimo di 24 ore

Aggiungi una piccola quantità casuale di jitter ai ritardi di backoff per evitare il problema del "thundering herd", in cui molti client riprovano contemporaneamente.

Rivedi le risposte

The request_status_per_destination in a RetrieveRequestStatusResponse contiene una voce separata per ogni destinazione nella richiesta di importazione corrispondente.

Ad esempio, se il tuo IngestAudienceMembersRequest conteneva 3 voci nell'elenco destinations per inviare dati a 3 segmenti di pubblico diversi, la risposta di stato conterrebbe 3 voci in request_status_per_destination (una voce per segmento di pubblico).

Controlla lo stato generale della destinazione

Come primo passo, controlla il campo request_status per determinare se l' API Data Manager ha terminato l'elaborazione dei dati per la destination del RequestStatusPerDestination.

Ecco i valori possibili di request_status:

  • PROCESSING: i dati per la destinazione sono ancora in fase di elaborazione. In questa fase, gli avvisi e gli errori non vengono inseriti per la destinazione.

  • SUCCESS: l'elaborazione della richiesta per la destinazione è stata completata senza errori. Controlla se sono presenti avvisi segnalati durante l'elaborazione.

  • FAILURE: tutti i record per la destinazione non sono riusciti a causa di errori. Controlla la presenza di avvisi ed errori per determinare il motivo per cui tutti i record non sono riusciti. Controlla anche se sono presenti avvisi segnalati durante l'elaborazione.

  • PARTIAL_SUCCESS: alcuni record per la destinazione sono riusciti, ma altri non sono riusciti a causa di errori. Controlla la presenza di errori per determinare il motivo per cui alcuni record non sono riusciti. Controlla anche se sono presenti avvisi segnalati durante l'elaborazione.

Controlla lo stato dell'evento o del segmento di pubblico per destinazione

Esamina il campo di stato che corrisponde al tipo di richiesta di importazione. In ogni RequestStatusPerDestination è impostato solo uno dei seguenti campi:

Stato di importazione degli eventi

Il campo events_ingestion_status viene compilato se la richiesta era un IngestEventsRequest.

Controlla il record_count di IngestEventStatus per verificare che il numero totale di record ricevuti corrisponda alle tue aspettative. record_count include i record riusciti e non riusciti.

Stato di importazione dei membri del segmento di pubblico

Il campo audience_members_ingestion_status viene compilato se la richiesta era un IngestAudienceMembersRequest. Ecco il IngestAudienceMembersStatus campo da controllare per ogni tipo di dati del segmento di pubblico. È impostato solo uno di questi campi.

user_data_ingestion_status

Controlla il record_count del IngestUserDataStatus per verificare che il numero totale di record ricevuti corrisponda alle tue aspettative. record_count include i record riusciti e non riusciti.

Controlla user_identifier_count per verificare che il numero di identificatori utente ricevuti corrisponda alle tue aspettative.

Se la richiesta aveva un numero sufficiente di record, il upload_match_rate_range contiene l'intervallo di tasso di corrispondenza per i record nella richiesta.

mobile_data_ingestion_status

Controlla il record_count del IngestMobileDataStatus per verificare che il numero totale di record ricevuti corrisponda alle tue aspettative. record_count include i record riusciti e non riusciti.

Controlla mobile_id_count per verificare che il numero di ID mobile ricevuti corrisponda alle tue aspettative.

pair_data_ingestion_status

Controlla il record_count del IngestPairDataStatus per verificare che il numero totale di record ricevuti corrisponda alle tue aspettative. record_count include i record riusciti e non riusciti.

Controlla pair_id_count per verificare che il numero di ID PAIR ricevuti corrisponda alle tue aspettative.

ppid_data_ingestion_status

Controlla il record_count del IngestPpidDataStatus per verificare che il numero totale di record ricevuti corrisponda alle tue aspettative. record_count include i record riusciti e non riusciti.

Controlla ppid_count per verificare che il numero di PPID ricevuti corrisponda alle tue aspettative.

user_id_data_ingestion_status

Controlla record_count di IngestUserIdDataStatus per verificare che il totale numero di record ricevuti corrisponda alle tue aspettative. record_count include i record riusciti e non riusciti.

Controlla user_id_count per verificare che il numero di ID utente ricevuti corrisponda alle tue aspettative.

composite_data_ingestion_status

Controlla il record_count del IngestCompositeDataStatus per verificare che il numero totale di record ricevuti corrisponda alle tue aspettative. record_count include i record riusciti e non riusciti.

Controlla data_type_counts per verificare che il numero di identificatori corrisponda alle tue aspettative. Questo elenco fornisce una suddivisione di tutti gli identificatori ricevuti (ad esempio indirizzo email, numero di telefono, indirizzo fisico e indirizzo IP) per DataType.

Se la richiesta aveva un numero sufficiente di record, il upload_match_rate_range contiene l'intervallo di tasso di corrispondenza per i record nella richiesta.

Stato di rimozione dei membri del segmento di pubblico

Il campo audience_members_removal_status viene compilato se la richiesta era un RemoveAudienceMembersRequest. Ecco il RemoveAudienceMembersStatus campo da controllare per ogni tipo di dati del segmento di pubblico. È impostato solo uno di questi campi.

user_data_removal_status
Stato di rimozione per i dati utente.
mobile_data_removal_status
Stato di rimozione per i dati mobile.
pair_data_removal_status
Stato di rimozione per i dati PAIR.
ppid_data_removal_status
Stato di rimozione per i dati PPID.
user_id_data_removal_status
Stato di rimozione per i dati ID utente
composite_data_removal_status
Stato di rimozione per i dati compositi

Controlla record_count per verificare che il numero totale di record ricevuti corrisponda alle tue aspettative. record_count include i record riusciti e non riusciti.

Inoltre, controlla user_identifier_count, mobile_id_count, pair_id_count, ppid_count o user_id_count per verificare il conteggio totale degli identificatori ricevuti.

Per i dati compositi, controlla data_type_counts per verificare che il numero di identificatori corrisponda alle tue aspettative. Questo elenco fornisce una suddivisione di tutti gli identificatori ricevuti (ad esempio indirizzo email, numero di telefono, indirizzo fisico e indirizzo IP) per DataType.

Controlla avvisi ed errori

Oltre ai campi di stato per la destinazione e il tipo di richiesta, il RetrieveRequestStatusResponse contiene una suddivisione di avvisi ed errori per la richiesta.

  • Un errore indica che l'API ha rifiutato completamente il record.
  • Un avviso indica che l'API non ha rifiutato il record, ma ha dovuto ignorare parti dei dati del record.

Ad esempio, se un Event contiene dati criptati UserIdentifier e AdIdentifiers come gclid, e i dati UserIdentifier non possono essere decriptati, l'API Data Manager elabora comunque il record utilizzando AdIdentifiers, ma restituisce l'avviso PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR.

Tuttavia, se Event non contiene AdIdentifiers e i dati UserIdentifier non possono essere decriptati, l'API Data Manager rifiuta l'intero record e segnala l'errore PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR perché un Event valido deve avere almeno uno tra ad_identifiers o user_data.

Di seguito sono riportati i campi di risposta che contengono informazioni su avvisi ed errori. Questi campi vengono compilati quando lo stato generale della destinazione raggiunge SUCCESS, PARTIAL_SUCCESS, o FAILURE.

warning_info

Un elenco di WarningCount oggetti. Ogni WarningCount contiene un reason con il tipo di avviso e un record_count che indica il numero di record che avevano quel tipo di avviso.

Controlla il warning_info anche se lo stato generale della destinazione è SUCCESS.

error_info

Un elenco di ErrorCount oggetti. Ogni ErrorCount contiene un reason con il tipo di errore e un record_count che indica il numero di record non riusciti a causa di quel tipo di errore.