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 demande. Une requête réussie comporte un Status avec code égal à 0 (valeur d'énumération OK, réponse HTTP 200 OK) et renvoie un IngestEventsResponse, un IngestAudienceMembersResponse ou un 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 pour pouvoir l'utiliser afin de récupérer les diagnostics à l'étape suivante.

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

   Répétez régulièrement cette étape 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 l'opération 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 valeur request_id. Envoyez une demande d'état distincte pour chaque ID de requête que vous avez capturé à partir d'une requête d'ingestion réussie.

Autorisation

Un RetrieveRequestStatusRequest n'accepte pas les comptes de destination ni les en-têtes de requête. À la place, l'API Data Manager identifie les destinations à partir de la requête d'ingestion d'origine associée à l'request_id et vérifie que l'appelant a accès à l'operating_account sur chaque Destination.

Pour vérifier l'état d'une requête, les identifiants utilisés dans un RetrieveRequestStatusRequest doivent répondre aux exigences suivantes concernant le operating_account de chaque destination de la requête d'ingestion d'origine :

• Chemin d'accès identique : les identifiants doivent avoir accès à chaque operating_account en utilisant le chemin d'accès exact spécifié dans la demande d'ingestion d'origine.

  Par exemple, si une requête d'ingestion pour un operating_account Google Ads spécifie un compte administrateur parent comme login_account, les identifiants doivent également avoir accès au operating_account via ce même compte administrateur. Même si le compte Google associé aux identifiants dispose d'un accès direct au operating_account enfant, la requête échoue avec une erreur PERMISSION_DENIED si ce compte n'a pas accès via le compte administrateur login_account spécifié lors de l'ingestion.

• Niveau d'accès suffisant : le compte Google associé aux identifiants doit disposer d'un niveau d'accès ou d'un rôle autorisant l'ingestion de données dans operating_account.

  Par exemple, dans Google Ads, le compte Google doit disposer du niveau d'accès Administrateur ou Standard. Une requête avec les identifiants d'un compte disposant du niveau d'accès Lecture seule échoue avec une erreur PERMISSION_DENIED.

Stratégie d'interrogation

Envoyez régulièrement RetrieveRequestStatusRequest à l'aide d'un algorithme d'intervalle exponentiel entre les tentatives jusqu'à ce que request_status atteigne SUCCESS, FAILURE ou PARTIAL_SUCCESS pour chaque destination de la requête d'origine. Cela peut prendre jusqu'à 24 heures, même si l'API Data Manager peut traiter certaines requêtes en seulement 30 minutes.

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

Paramètre	Valeur
Temps d'attente avant la première demande de diagnostic (en 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 :

Ajoutez une petite quantité aléatoire de gigue aux délais d'intervalle entre les tentatives pour éviter le problème de "troupeau tonitruant" 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 demande 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

Commencez par vérifier le champ request_status pour déterminer si l'API Data Manager a fini de traiter les données pour le destination de l'RequestStatusPerDestination.

Voici les valeurs possibles de request_status :

• PROCESSING : les données de la destination sont toujours en cours de traitement. Les avertissements et 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. Vérifiez 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é. Vérifiez également si des avertissements ont été 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é. Vérifiez également les avertissements signalés lors du traitement.

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

Examinez le champ d'état qui correspond au type de demande d'ingestion. Un seul des champs suivants est défini sur chaque RequestStatusPerDestination :

• events_ingestion_status
• audience_members_ingestion_status
• audience_members_removal_status

État de l'ingestion des événements

Le champ events_ingestion_status est renseigné si la demande était une IngestEventsRequest.

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

État d'ingestion des membres de l'audience

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

composite_data_ingestion_status

Vérifiez le champ record_count de IngestCompositeDataStatus pour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes. Le record_count inclut les enregistrements ayant réussi et ceux ayant échoué.

Cochez la case data_type_counts pour confirmer que le nombre d'identifiants correspond à vos attentes. Cette liste fournit une répartition de tous les identifiants reçus (tels que l'adresse e-mail, le numéro de téléphone, l'adresse physique et l'adresse IP) par DataType.

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

google_user_id_data_ingestion_status

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

Consultez google_user_id_count pour vérifier que le nombre d'ID utilisateur Google reçus correspond à vos attentes.

mobile_data_ingestion_status

Vérifiez le champ record_count de IngestMobileDataStatus pour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes. Le record_count inclut les enregistrements ayant réussi et ceux ayant échoué.

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

pair_data_ingestion_status

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

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

partner_provided_id_data_ingestion_status

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

Vérifiez la partner_provided_id_count pour confirmer que le nombre d'ID fournis par le partenaire correspond à vos attentes.

ppid_data_ingestion_status

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

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

user_data_ingestion_status

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

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

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

user_id_data_ingestion_status

Consultez le record_count de IngestUserIdDataStatus pour vérifier que le nombre total d'enregistrements reçus correspond à vos attentes. Le record_count inclut les enregistrements réussis et ceux ayant échoué.

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

État de la suppression des membres de l'audience

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

composite_data_removal_status

État de la suppression pour Données composites

google_user_id_data_removal_status

État de la suppression des données d'ID utilisateur Google

mobile_data_removal_status

État de la suppression des données mobiles.

pair_data_removal_status

État de la suppression des données PAIR.

partner_provided_id_data_removal_status

État de la suppression des données d'identité fournies par le partenaire

ppid_data_removal_status

État de la suppression des données PPID.

user_data_removal_status

État de suppression des données utilisateur.

user_id_data_removal_status

État de la suppression des données d'ID utilisateur

Vérifiez la valeur 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 ayant échoué.

Vérifiez également user_identifier_count, mobile_id_count, pair_id_count, ppid_count, user_id_count, google_user_id_count ou partner_provided_id_count pour confirmer le nombre total d'identifiants reçus.

Pour les données composites, vérifiez le data_type_counts pour confirmer que le nombre d'identifiants correspond à vos attentes. Cette liste fournit une répartition de tous les identifiants reçus (comme l'adresse e-mail, le numéro de téléphone, l'adresse physique et l'adresse IP) par DataType.

Vérifier les avertissements et les erreurs

En plus des champs d'état pour la destination et le type de requête, 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 contient des données UserIdentifier chiffrées et des AdIdentifiers telles 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 de AdIdentifiers, mais renvoie l'avertissement PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR.

Toutefois, si Event ne contient pas AdIdentifiers et que les données UserIdentifier ne peuvent pas être déchiffrées, l'API Data Manager rejette l'intégralité de l'enregistrement et signale l'erreur PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR, car un Event valide doit contenir au moins l'un des éléments 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 global de la destination passe à SUCCESS, PARTIAL_SUCCESS ou FAILURE.

warning_info

Un objet WarningInfo. Son champ warning_counts contient une liste d'objets WarningCount. Chaque WarningCount contient un reason avec le type d'avertissement et un record_count indiquant le nombre d'enregistrements ayant reçu ce type d'avertissement.

Vérifiez l'warning_info même si l'état global de la destination est SUCCESS.

error_info

Objet ErrorInfo. Son champ error_counts contient une liste d'objets ErrorCount. Chaque ErrorCount contient un reason avec le type d'erreur et un record_count indiquant le nombre d'enregistrements ayant échoué en raison de ce type d'erreur.