Questa pagina è stata tradotta dall'API Cloud Translation.

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.

Emetti richieste per inviare eventi o inviare o rimuovere membri del pubblico.
Controlla lo stato generale di ogni richiesta. Una richiesta riuscita 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.

Nota: puoi recuperare i dati diagnostici solo per le richieste che vanno a buon fine e non hanno validate_only impostato su true.
Invia una richiesta RetrieveRequestStatus per ogni request_id riuscito.
Esamina ogni RetrieveRequestStatusResponse per verificare che i caricamenti funzionino correttamente e identificare eventuali problemi con i dati.
Correggere i problemi relativi ai dati.
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 riuscita 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:

events_ingestion_status
audience_members_ingestion_status
audience_members_removal_status

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.