Diagnostica

Ecco il flusso di lavoro consigliato per verificare l'integrità dei caricamenti di eventi e segmenti di pubblico e identificare i problemi relativi ai dati.

  1. Emetti richieste per inviare eventi o inviare o rimuovere membri del pubblico.

  2. Controlla lo stato generale di ogni richiesta. Una richiesta andata a buon fine ha un Status con code uguale a 0 (valore enum OK, risposta HTTP 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 ha esito positivo, acquisisci request_id della risposta in modo da poterlo utilizzare per recuperare la diagnostica nel passaggio successivo.

  3. Attendi 30 minuti, poi invia una richiesta RetrieveRequestStatus per ogni request_id andato a buon fine.

    Ripeti periodicamente questo passaggio per ogni request_id finché lo stato della 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 la procedura finché non avrai risolto tutti i problemi relativi ai tuoi caricamenti.

Invio di richieste

Un RetrieveRequestStatusRequest richiede un singolo valore request_id. 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. L'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 diagnostica (in minuti) 30
Moltiplicatore di backoff 1.3
Backoff massimo (minuti) 60 (1 ora)
Tempo totale massimo (minuti) 1440 (24 ore)

Ecco 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 min Per prima cosa, verifica la disponibilità dello stato.
2 01:09 39,0 min
3 01:59 50,7 min
4 02:59 60 minuti Il ritardo è ora limitato a 1 ora
5 03:59 60 minuti
6 04:59 60 minuti
7 05:59 60 minuti
8 06:59 60 minuti
9 07:59 60 minuti
10 08:59 60 minuti
11 09:59 60 minuti
12 10:59 60 minuti
13 11:59 60 minuti Segno delle 12 ore
14 12:59 60 minuti
15 13:59 60 minuti
16 14:59 60 minuti
17 15:59 60 minuti
18 16:59 60 minuti
19 17:59 60 minuti
20 18:59 60 minuti
21 19:59 60 minuti
22 20:59 60 minuti
23 21:59 60 minuti
24 22:59 60 minuti
25 23:59 60 minuti 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 simultaneamente.

Rivedi le risposte

L'request_status_per_destination in un RetrieveRequestStatusResponse contiene una voce separata per ogni destinazione nella richiesta di importazione corrispondente.

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

Controllare lo stato generale della destinazione

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

Ecco i valori possibili di request_status:

  • PROCESSING: i dati per la destinazione sono ancora in fase di elaborazione. Gli avvisi ed errori non vengono compilati per la destinazione in questa fase.

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

  • FAILURE: Tutti i record per la destinazione non sono stati caricati a causa di errori. Controlla la presenza di avvisi ed errori per determinare perché tutti i record non sono stati caricati. Controlla anche gli avvisi segnalati durante l'elaborazione.

  • PARTIAL_SUCCESS: alcuni record per la destinazione sono stati elaborati correttamente, ma altri non sono riusciti a causa di errori. Controlla la presenza di errori per determinare perché alcuni record non sono stati caricati. Controlla anche gli avvisi segnalati durante l'elaborazione.

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

Esamina il campo dello stato corrispondente al tipo di richiesta di importazione. Su ogni RequestStatusPerDestination è impostato solo uno dei seguenti campi:

Stato dell'importazione di eventi

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

Controlla il campo record_count di IngestEventStatus per verificare che il numero totale di record ricevuti corrisponda alle tue aspettative. record_count include sia i record riusciti che quelli 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 campo IngestAudienceMembersStatus da controllare per ogni tipo di dati sul pubblico. È impostato solo uno di questi campi.

user_data_ingestion_status

Controlla il campo 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 il campo user_identifier_count per verificare che il numero di identificatori utente ricevuti corrisponda alle tue aspettative.

Se la richiesta conteneva un numero sufficiente di record, upload_match_rate_range contiene l'intervallo del 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 campo 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 coppia ricevuti corrisponda alle tue aspettative.

ppid_data_ingestion_status

Controlla il campo 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 il campo record_count del IngestUserIdDataStatus per verificare che il numero totale 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.

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 campo RemoveAudienceMembersStatus da controllare per ogni tipo di dati del pubblico. È impostato solo uno di questi campi.

user_data_removal_status
Stato della rimozione dei dati utente.
mobile_data_removal_status
Stato della rimozione per i dati mobili.
pair_data_removal_status
Stato della rimozione dei dati PAIR.
ppid_data_removal_status
Stato della rimozione per i dati PPID.
user_id_data_removal_status
Stato della rimozione per i dati ID utente

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

Inoltre, controlla user_identifier_count, mobile_id_count o pair_id_count per confermare il conteggio totale di identificatori utente, ID mobile o ID PAIR ricevuti.

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 per una conversione offline di Google Ads contiene dati UserIdentifier criptati 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é una conversione offline di Google Ads valida Event deve avere almeno uno dei valori 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 complessivo della destinazione raggiunge SUCCESS, PARTIAL_SUCCESS o FAILURE.

warning_info

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

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

error_info

Un elenco di oggetti ErrorCount. 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.