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. Acquisisci il request_id da ogni IngestEventsResponse, IngestAudienceMembersResponse o RemoveAudienceMembersResponse.
  3. Invia una richiesta RetrieveRequestStatus per ogni request_id.
  4. Esamina ogni RetrieveRequestStatusResponse per verificare che i caricamenti funzionino correttamente e identificare eventuali problemi con i dati.
  5. Correggere 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.

Richieste di costruzione

Un RetrieveRequestStatusRequest ha un solo campo request_id. Invia una richiesta per ogni ID richiesta acquisito durante l'invio delle richieste di importazione.

Rivedere 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 tre voci nell'elenco destinations per inviare dati a tre pubblici diversi, la risposta di stato conterrà tre voci in request_status_per_destination (una voce per 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 il destination di RequestStatusPerDestination. Di seguito sono riportati i valori possibili di request_status:

  • PROCESSING: I dati per la destinazione sono ancora in fase di elaborazione.
  • SUCCESS: l'elaborazione della richiesta per la destinazione è stata completata senza errori.
  • FAILURE: Tutti i record per la destinazione non sono stati caricati a causa di errori.
  • PARTIAL_SUCCESS: alcuni record per la destinazione sono stati elaborati correttamente, ma altri non sono riusciti a causa di errori.

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 di importazione degli 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 dell'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. Il record_count include sia i record riusciti che quelli 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 campo record_count del IngestMobileDataStatus per verificare che il numero totale di record ricevuti corrisponda alle tue aspettative. Il 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. Il record_count include sia i record riusciti che quelli non riusciti.

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

Stato della 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.

Controlla record_count per verificare che il numero totale di record ricevuti corrisponda alle tue aspettative. record_count include sia i record riusciti sia 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 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é un Event valido deve contenere almeno ad_identifiers o user_data.

Di seguito sono riportati i campi di risposta che contengono informazioni su avvisi ed errori.

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 hanno generato avvisi di quel tipo.
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.