Diagnóstico

Confira o fluxo de trabalho recomendado para verificar a integridade dos envios de eventos e públicos-alvo e identificar problemas com seus dados.

Faça solicitações para enviar eventos ou enviar ou remover membros do público-alvo.
Verifique o status geral de cada solicitação. Uma solicitação bem-sucedida tem um Status com code igual a 0 (valor de enumeração OK, resposta HTTP 200 OK) e retorna um IngestEventsResponse, IngestAudienceMembersResponse ou RemoveAudienceMembersResponse.

Se uma solicitação não for bem-sucedida, modifique-a para resolver o erro e envie-a novamente.

Se uma solicitação for bem-sucedida, capture o request_id da resposta para usá-lo na recuperação de diagnósticos na próxima etapa.

**Observação**: só é possível recuperar diagnósticos de solicitações bem-sucedidas e que não tenham validate_only definido como true.
Envie uma solicitação RetrieveRequestStatus para cada request_id bem-sucedido.
Analise cada RetrieveRequestStatusResponse para confirmar se os envios estão funcionando corretamente e identificar problemas com seus dados.
Corrija problemas de dados.
Volte à etapa 1 e repita até resolver todos os problemas com seus envios.

Enviar solicitações

Um RetrieveRequestStatusRequest tem um único request_id campo. Envie uma solicitação para cada ID de solicitação bem-sucedido capturado ao enviar solicitações de ingestão.

Teste uma solicitação no navegador usando o APIs Explorer.

Analisar respostas

O request_status_per_destination em um RetrieveRequestStatusResponse contém uma entrada separada para cada destino na solicitação de ingestão correspondente.

Por exemplo, se o IngestAudienceMembersRequest contiver três entradas na lista destinations para enviar dados a três públicos-alvo diferentes, a resposta de status vai conter três entradas em request_status_per_destination (uma entrada por público-alvo).

Verificar o status geral do destino

Como primeira etapa, verifique o request_status campo para determinar se a API Data Manager concluiu o processamento dos dados para o destination do RequestStatusPerDestination. Estes são os valores possíveis de request_status:

PROCESSING: os dados do destino ainda estão sendo processados.
SUCCESS: o processamento da solicitação para o destino foi concluído sem erros.
FAILURE: todos os registros do destino falharam devido a erros.
PARTIAL_SUCCESS: alguns dos registros do destino foram bem-sucedidos, mas outros falharam devido a erros.

Verificar o status do evento ou do público-alvo por destino

Inspecione o campo de status que corresponde ao tipo de solicitação de ingestão. Apenas um dos campos a seguir é definido em cada RequestStatusPerDestination:

events_ingestion_status
audience_members_ingestion_status
audience_members_removal_status

Status de ingestão de eventos

O campo events_ingestion_status é preenchido se a solicitação for um IngestEventsRequest.

Verifique o record_count do IngestEventStatus para confirmar se o número total de registros recebidos corresponde às suas expectativas. O record_count inclui registros bem-sucedidos e com falha.

Status de ingestão de membros do público-alvo

O campo audience_members_ingestion_status é preenchido se a solicitação for um IngestAudienceMembersRequest. Confira o campo IngestAudienceMembersStatus para verificar cada tipo de dados de público-alvo. Apenas um desses campos é definido.

user_data_ingestion_status

Verifique o record_count do IngestUserDataStatus para confirmar se o número total de registros recebidos corresponde às suas expectativas. O record_count inclui registros bem-sucedidos e com falha.

Verifique o user_identifier_count para confirmar se o número de identificadores de usuário recebidos corresponde às suas expectativas.

Se a solicitação tiver um número suficiente de registros, o upload_match_rate_range vai conter o intervalo de taxa de correspondência range para registros na solicitação.

mobile_data_ingestion_status

Verifique o record_count do IngestMobileDataStatus para confirmar se o número total de registros recebidos corresponde às suas expectativas. O record_count inclui registros bem-sucedidos e com falha.

Verifique o mobile_id_count para confirmar se o número de IDs de dispositivos móveis recebidos corresponde às suas expectativas.

pair_data_ingestion_status

Verifique o record_count do IngestPairDataStatus para confirmar se o número total de registros recebidos corresponde às suas expectativas. O record_count inclui registros bem-sucedidos e com falha.

Verifique o pair_id_count para confirmar se o número de IDs da PAIR recebidos corresponde às suas expectativas.

ppid_data_ingestion_status

Verifique o record_count do IngestPpidDataStatus para confirmar se o total número de registros recebidos corresponde às suas expectativas. O record_count inclui registros bem-sucedidos e com falha.

Verifique o ppid_count para confirmar se o número de PPIDs recebidos corresponde às suas expectativas.

user_id_data_ingestion_status

Verifique o record_count do IngestUserIdDataStatus para confirmar se o total número de registros recebidos corresponde às suas expectativas. O record_count inclui registros bem-sucedidos e com falha.

Verifique o user_id_count para confirmar se o número de IDs de usuário recebidos corresponde às suas expectativas.

Status de remoção de membros do público-alvo

O campo audience_members_removal_status é preenchido se a solicitação for um RemoveAudienceMembersRequest. Confira o campo RemoveAudienceMembersStatus para verificar cada tipo de dados de público-alvo. Apenas um desses campos é definido.

user_data_removal_status: Status de remoção de dados do usuário.
mobile_data_removal_status: Status de remoção de dados móveis.
pair_data_removal_status
ppid_data_removal_status: Status de remoção de dados de PPID.
user_id_data_removal_status: Status de remoção de dados de ID do usuário

Verifique o record_count para confirmar se o número total de registros recebidos corresponde às suas expectativas. O record_count inclui registros bem-sucedidos e com falha.

Além disso, verifique o user_identifier_count, mobile_id_count ou pair_id_count para confirmar a contagem total de identificadores de usuário, IDs de dispositivos móveis, ou IDs da PAIR recebidos.

Verificar avisos e erros

Além dos campos de status para o destino e o tipo de solicitação, o RetrieveRequestStatusResponse contém uma discriminação de avisos e erros da solicitação.

Um erro indica que a API rejeitou completamente o registro.
Um aviso indica que a API não rejeitou o registro, mas teve que ignorar partes dos dados dele.

Por exemplo, se um Event contiver dados UserIdentifier criptografados e AdIdentifiers, como gclid, e os dados UserIdentifier não puderem ser descriptografados, a API Data Manager ainda vai processar o registro usando os AdIdentifiers, mas vai retornar o aviso PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR.

No entanto, se o Event não contiver AdIdentifiers e os dados UserIdentifier não puderem ser descriptografados, a API Data Manager vai rejeitar todo o registro e informar o erro PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR porque um Event válido precisa ter pelo menos um de ad_identifiers ou user_data.

Estes são os campos de resposta que contêm informações de aviso e erro.

warning_info: Uma lista de WarningCount objetos. Cada WarningCount contém um reason com o tipo de aviso e um record_count que indica o número de registros que tiveram avisos desse tipo.
error_info: Uma lista de ErrorCount objetos. Cada ErrorCount contém um reason com o tipo de erro e um record_count indicando o número de registros que falharam devido a esse tipo de erro.