Diagnóstico

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

  1. Envie solicitações para transmitir eventos ou enviar ou remover participantes do público-alvo.

  2. 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 corrigir o erro e envie de novo.

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

  3. Envie uma solicitação RetrieveRequestStatus para cada request_id bem-sucedido.

  4. Analise cada RetrieveRequestStatusResponse para confirmar se os envios estão funcionando corretamente e identificar problemas com seus dados.

  5. Corrigir problemas de dados.

  6. Volte à etapa 1 e repita até resolver todos os problemas com seus envios.

Criar solicitações

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

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 tiver 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 campo request_status para determinar se a API Data Manager concluiu o processamento dos dados do 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 concluídos, mas outros falharam devido a erros.

Verificar o status de eventos ou públicos-alvo por destino

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

Status da 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 da 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 cada tipo de dado 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ários 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 para os 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.

Confira 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.

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

Status da 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 cada tipo de dado de público-alvo. Apenas um desses campos é definido.

user_data_removal_status
Status da remoção dos dados do usuário.
mobile_data_removal_status
Status da remoção dos dados móveis.
pair_data_removal_status
Status da remoção dos dados da PAIR.

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 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 um detalhamento 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 precisou ignorar partes dos dados dele.

Por exemplo, se um Event contiver dados criptografados de UserIdentifier e AdIdentifiers, como gclid, e os dados de UserIdentifier não puderem ser descriptografados, a API Data Manager ainda vai processar o registro usando 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 de 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.

Confira os campos de resposta que contêm informações sobre erros e avisos.

warning_info
Uma lista de objetos WarningCount. Cada WarningCount contém um reason com o tipo de aviso e um record_count que indica o número de registros com avisos desse tipo.
error_info
Uma lista de objetos ErrorCount. 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.