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.

  1. Envie solicitações para enviar 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 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.

  3. Aguarde 30 minutos e envie uma RetrieveRequestStatus solicitação para cada request_id bem-sucedido.

    Repita essa etapa periodicamente para cada request_id até que o status de destino de cada um deles atinja SUCCESS, PARTIAL_SUCCESS, ou FAILURE. Use um algoritmo de espera exponencial para aguardar entre cada solicitação.

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

  5. Corrija problemas de dados.

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

Enviar solicitações

Um RetrieveRequestStatusRequest exige um único request_id valor. Envie uma solicitação de status separada para cada ID de solicitação capturado de uma solicitação de ingestão bem-sucedida.

Envie periodicamente o RetrieveRequestStatusRequest usando um algoritmo de espera exponencial até que o request_status atinja SUCCESS, FAILURE, ou PARTIAL_SUCCESS para cada destino na solicitação original request. Isso pode levar até 24 horas, embora a API Data Manager possa concluir o processamento de algumas solicitações em apenas 30 minutos.

Confira um exemplo de tempo de espera inicial razoável e configuração de nova tentativa que equilibra a atividade e o uso da cota:

Configuração Valor
Tempo de espera antes da primeira solicitação de diagnóstico (minutos) 30
Multiplicador de espera 1.3
Espera máxima (minutos) 60 (1 hora)
Tempo total máximo (minutos) 1440 (24 horas)

Confira uma sequência de solicitações e o tempo decorrido com essa configuração:

Gráfico

Estratégia de pesquisa

Dados

Tentativa Tempo desde a solicitação de ingestão (hh:mm) Atraso antes da tentativa Observações
1 00:30 30,0 min Primeira verificação da disponibilidade de status
2 01:09 39,0 min
3 01:59 50,7 min
4 02:59 60,0 min O atraso agora está limitado a 1 hora
5 03:59 60,0 min
6 04:59 60,0 min
7 05:59 60,0 min
8 06:59 60,0 min
9 07:59 60,0 min
10 08:59 60,0 min
11 09:59 60,0 min
12 10:59 60,0 min
13 11:59 60,0 min Marca de 12 horas
14 12:59 60,0 min
15 13:59 60,0 min
16 14:59 60,0 min
17 15:59 60,0 min
18 16:59 60,0 min
19 17:59 60,0 min
20 18:59 60,0 min
21 19:59 60,0 min
22 20:59 60,0 min
23 21:59 60,0 min
24 22:59 60,0 min
25 23:59 60,0 min Última solicitação antes do tempo total máximo de 24 horas

Adicione uma pequena quantidade aleatória de instabilidade aos atrasos de espera para evitar o problema de "excesso de acionamentos", em que muitos clientes tentam novamente simultaneamente.

Revisar 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 terminou de processar os 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. Os avisos e erros não são preenchidos para o destino nessa fase.

  • SUCCESS: o processamento da solicitação para o destino foi concluído sem erros. Verifique se há avisos sinalizados durante o processamento.

  • FAILURE: todos os registros do destino falharam devido a erros. Verifique se há avisos e erros para determinar por que todos os registros falharam. Verifique também se há avisos sinalizados durante o processamento.

  • PARTIAL_SUCCESS: alguns dos registros do destino foram bem-sucedidos, mas outros falharam devido a erros. Verifique se há erros para determinar por que alguns registros falharam. Verifique também se há avisos sinalizados durante o processamento.

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:

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 participantes do público-alvo

O campo audience_members_ingestion_status é preenchido se a solicitação for um IngestAudienceMembersRequest. Confira o IngestAudienceMembersStatus campo para verificar cada tipo de dados do 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 de pares 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.

composite_data_ingestion_status

Verifique o record_count do IngestCompositeDataStatus 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 data_type_counts para confirmar se o número de identificadores corresponde às suas expectativas. Essa lista fornece uma detalhamento de todos os identificadores recebidos (como endereço de e-mail, número de telefone, endereço físico e endereço IP) por DataType.

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.

Status da remoção de participantes 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 do público-alvo. Apenas um desses campos é definido.

user_data_removal_status
Status da remoção de dados do usuário.
mobile_data_removal_status
Status da remoção de dados de dispositivos móveis.
pair_data_removal_status
Status da remoção de dados de pares.
ppid_data_removal_status
Status da remoção de dados de PPID.
user_id_data_removal_status
Status da remoção de dados de ID de usuário
composite_data_removal_status
Status da remoção de dados compostos

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, pair_id_count, ppid_count ou user_id_count para confirmar a contagem total de identificadores recebidos.

Para dados compostos, verifique o data_type_counts para confirmar se o número de identificadores corresponde às suas expectativas. Essa lista fornece uma detalhamento de todos os identificadores recebidos (como endereço de e-mail, número de telefone, endereço físico e endereço IP) por DataType.

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 teve que ignorar partes dos dados dele.

Por exemplo, se um Event contiver dados criptografados 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 os AdIdentifiers, mas 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.

Estes são os campos de resposta que contêm informações de aviso e erro. Esses campos são preenchidos quando o status geral do destino atinge SUCCESS, PARTIAL_SUCCESS, ou FAILURE.

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 tinham esse tipo de aviso.

Verifique o warning_info mesmo que o status geral do destino seja SUCCESS.

error_info

Uma lista de ErrorCount objetos. Cada ErrorCount contém um reason com o tipo de erro e um record_count que indica o número de registros que falharam devido a esse tipo de erro.