Diagnostic

Voici le workflow recommandé pour vérifier l'état de vos importations d'événements et d'audiences, et identifier les problèmes liés à vos données.

  1. Envoyez des requêtes pour envoyer des événements ou envoyer ou supprimer des membres d'audience.

  2. Vérifiez l'état général de chaque requête. Une requête réussie présente un Status avec code égal à 0 (valeur d'énumération OK, HTTP réponse 200 OK) et renvoie un IngestEventsResponse, IngestAudienceMembersResponse ou RemoveAudienceMembersResponse.

    Si une requête échoue, modifiez-la pour corriger l'erreur, puis renvoyez-la.

    Si une requête aboutit, capturez le request_id de la réponse afin de pouvoir l'utiliser pour récupérer les diagnostics à l'étape suivante.

  3. Attendez 30 minutes, puis envoyez une RetrieveRequestStatus requête pour chaque request_id réussi.

    Répétez cette étape périodiquement pour chaque request_id jusqu'à ce que l'état de destination de chaque destination atteigne SUCCESS, PARTIAL_SUCCESS, ou FAILURE. Utilisez un algorithme d'intervalle exponentiel entre les tentatives pour attendre entre chaque requête.

  4. Examinez chaque RetrieveRequestStatusResponse pour vérifier que vos importations fonctionnent correctement et identifier les problèmes liés à vos données.

  5. Corrigez les problèmes liés aux données.

  6. Revenez à l'étape 1 et répétez-la jusqu'à ce que vous ayez résolu tous les problèmes liés à vos importations.

Envoyer des requêtes

Un RetrieveRequestStatusRequest nécessite une seule request_id valeur. Envoyez une requête d'état distincte pour chaque ID de requête que vous avez capturé à partir d'une requête d'ingestion réussie.

Envoyez périodiquement le RetrieveRequestStatusRequest à l'aide d'un algorithme d'intervalle exponentiel entre les tentatives jusqu'à ce que le request_status atteigne SUCCESS, FAILURE, ou PARTIAL_SUCCESS pour chaque destination de la requête d'origine. Cela peut prendre jusqu'à 24 heures, bien que l'API Data Manager puisse terminer le traitement de certaines requêtes en seulement 30 minutes.

Voici un exemple de délai d'attente initial raisonnable et de configuration de nouvelle tentative qui équilibre l'activité et l'utilisation du quota :

Paramètre Valeur
Délai d'attente avant la première requête de diagnostic (minutes) 30
Multiplicateur d'intervalle entre les tentatives 1.3
Intervalle maximal entre les tentatives (minutes) 60 (1 heure)
Durée totale maximale (minutes) 1440 (24 heures)

Voici une séquence de requêtes et le temps écoulé avec cette configuration :

Graphique

Stratégie d'interrogation

Données

Tentative Temps écoulé depuis la requête d'ingestion (hh:mm) Délai avant la tentative Remarques
1 00:30 30,0 min Première vérification de la disponibilité de l'état
2 01:09 39,0 min
3 01:59 50,7 min
4 02:59 60,0 min Le délai est désormais limité à 1 heure
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 Marque de 12 heures
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 Dernière requête avant la durée totale maximale de 24 heures

Ajoutez une petite quantité aléatoire de gigue aux délais d'intervalle entre les tentatives pour éviter le problème de "tonnerre de troupeau", où de nombreux clients effectuent une nouvelle tentative simultanément.

Examiner les réponses

Le request_status_per_destination d'un RetrieveRequestStatusResponse contient une entrée distincte pour chaque destination de la requête d'ingestion correspondante.

Par exemple, si votre IngestAudienceMembersRequest contenait trois entrées dans la liste destinations pour envoyer des données à trois audiences différentes, la réponse d'état contiendrait trois entrées dans request_status_per_destination (une entrée par audience).

Vérifier l'état général de la destination

Pour commencer, vérifiez le champ request_status pour déterminer si l' API Data Manager a terminé le traitement des données pour la destination du RequestStatusPerDestination.

Voici les valeurs possibles de request_status :

  • PROCESSING : les données de la destination sont toujours en cours de traitement. Les avertissements et les erreurs ne sont pas renseignés pour la destination à ce stade.

  • SUCCESS: le traitement de la requête pour la destination s'est terminé sans erreur. Recherchez les avertissements signalés lors du traitement.

  • FAILURE : tous les enregistrements de la destination ont échoué en raison d'erreurs. Recherchez les avertissements et les erreurs pour déterminer pourquoi tous les enregistrements ont échoué. Recherchez également les avertissements signalés lors du traitement.

  • PARTIAL_SUCCESS: certains enregistrements de la destination ont réussi, mais d'autres ont échoué en raison d'erreurs. Recherchez les erreurs pour déterminer pourquoi certains enregistrements ont échoué. Recherchez également les avertissements signalés lors du traitement.

Vérifier l'état des événements ou de l'audience par destination

Inspectez le champ d'état qui correspond au type de requête d'ingestion. Seul un des champs suivants est défini sur chaque RequestStatusPerDestination :

État de l'ingestion d'événements

Le champ events_ingestion_status est renseigné si la requête était un IngestEventsRequest.

Vérifiez le record_count du IngestEventStatus pour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes. Le record_count inclut les enregistrements réussis et ceux qui ont échoué.

État de l'ingestion des membres d'audience

Le champ audience_members_ingestion_status est renseigné si la requête était un IngestAudienceMembersRequest. Voici le IngestAudienceMembersStatus champ à vérifier pour chaque type de données d'audience. Seul un de ces champs est défini.

user_data_ingestion_status

Vérifiez le record_count des IngestUserDataStatus pour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes. Le record_count inclut les enregistrements réussis et ceux qui ont échoué.

Vérifiez le user_identifier_count pour confirmer que le nombre d' identifiants utilisateur reçus correspond à vos attentes.

Si la requête comportait un nombre suffisant d'enregistrements, le upload_match_rate_range contient la plage de taux de correspondance pour les enregistrements de la requête.

mobile_data_ingestion_status

Vérifiez le record_count des IngestMobileDataStatus pour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes. Le record_count inclut les enregistrements réussis et ceux qui ont échoué.

Vérifiez le mobile_id_count pour confirmer que le nombre d'identifiants mobiles reçus correspond à vos attentes.

pair_data_ingestion_status

Vérifiez le record_count des IngestPairDataStatus pour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes. Le record_count inclut les enregistrements réussis et ceux qui ont échoué.

Vérifiez le pair_id_count pour confirmer que le nombre d'identifiants PAIR reçus correspond à vos attentes.

ppid_data_ingestion_status

Vérifiez le record_count des IngestPpidDataStatus pour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes. Le record_count inclut les enregistrements réussis et ceux qui ont échoué.

Vérifiez le ppid_count pour confirmer que le nombre de PPID reçus correspond à vos attentes.

user_id_data_ingestion_status

Vérifiez le record_count de l' IngestUserIdDataStatus pour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes. Le record_count inclut les enregistrements réussis et ceux qui ont échoué.

Vérifiez le user_id_count pour confirmer que le nombre d'identifiants utilisateur reçus correspond à vos attentes.

État de la suppression des membres d'audience

Le champ audience_members_removal_status est renseigné si la requête était un RemoveAudienceMembersRequest. Voici le RemoveAudienceMembersStatus champ à vérifier pour chaque type de données d'audience. Seul un de ces champs est défini.

user_data_removal_status
État de la suppression des données utilisateur.
mobile_data_removal_status
État de la suppression des données mobiles.
pair_data_removal_status
État de la suppression des données PAIR.
ppid_data_removal_status
État de la suppression des données PPID.
user_id_data_removal_status
État de la suppression des données d'identifiant utilisateur

Vérifiez le record_count pour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes. Le record_count inclut les enregistrements réussis et ceux qui ont échoué.

Vérifiez également le user_identifier_count, le mobile_id_count ou le pair_id_count pour confirmer le nombre total d'identifiants utilisateur, d'identifiants mobiles ou d'identifiants PAIR reçus.

Vérifier les avertissements et les erreurs

En plus des champs d'état pour la destination et le type de requête, le RetrieveRequestStatusResponse contient une répartition des avertissements et des erreurs pour la requête.

  • Une erreur indique que l'API a complètement rejeté l'enregistrement.
  • Un avertissement indique que l'API n'a pas rejeté l'enregistrement, mais qu'elle a dû ignorer certaines parties des données de l'enregistrement.

Par exemple, si un Event pour une conversion hors connexion Google Ads contient des données chiffrées UserIdentifier et des AdIdentifiers tels que gclid, et que les données UserIdentifier ne peuvent pas être déchiffrées, l'API Data Manager traite toujours l'enregistrement à l'aide des AdIdentifiers mais renvoie l'avertissement PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR.

Toutefois, si l'Event ne contient pas de AdIdentifiers et que les données UserIdentifier ne peuvent pas être déchiffrées, l'API Data Manager rejette l'enregistrement entier et signale l'erreur PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR, car un Event de conversion hors connexion Google Ads valide doit comporter au moins l'un des éléments suivants : ad_identifiers ou user_data.

Voici les champs de réponse qui contiennent des informations sur les avertissements et les erreurs. Ces champs sont renseignés lorsque l'état général de la destination atteint SUCCESS, PARTIAL_SUCCESS, ou FAILURE.

warning_info

Liste d'objets WarningCount. Chaque WarningCount contient un reason avec le type d'avertissement et un record_count indiquant le nombre d'enregistrements qui ont généré ce type d'avertissement.

Vérifiez le warning_info même si l'état général de la destination est SUCCESS.

error_info

Liste d'objets ErrorCount. Chaque ErrorCount contient un reason avec le type d'erreur et un record_count indiquant le nombre d'enregistrements qui ont échoué en raison de ce type d'erreur.