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

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

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

    Repita essa etapa periodicamente para cada request_id até que o status de destino de cada destino 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 com dados.

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

Enviar solicitações

Um RetrieveRequestStatusRequest requer um único valor de request_id. 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 alcance SUCCESS, FAILURE ou PARTIAL_SUCCESS para cada destino na solicitação original. 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 e configuração de nova tentativa razoáveis que equilibram a atividade e o uso de 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 min Primeiro, verifique a 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 jitter 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 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

Primeiro, verifique o campo request_status para determinar se a API Data Manager concluiu o processamento dos dados do destination do RequestStatusPerDestination.

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

  • SUCCESS: o processamento da solicitação para o destino foi concluído sem erros. Verifique os 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 concluídos, 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 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 participantes 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á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 da 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.

ppid_data_ingestion_status

Verifique o record_count do IngestPpidDataStatus 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 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 número total 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 User-IDs 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.
ppid_data_removal_status
Status da remoção dos dados de PPID.
user_id_data_removal_status
Status da remoção dos dados de ID do usuário

Verifique o campo 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 de uma conversão off-line do Google Ads contiver dados criptografados de UserIdentifier e AdIdentifiers, como gclid, e os dados de UserIdentifier não puderem ser descriptografados, a API Data Manager ainda 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 uma conversão off-line válida do Google Ads Event precisa ter pelo menos um dos seguintes itens: ad_identifiers ou user_data.

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

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

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

error_info

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