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.
Émettez des requêtes pour envoyer des événements ou envoyer ou supprimer des membres d'audience.
Vérifiez l'état général de chaque demande. Une requête réussie comporte un
Statusaveccodeégal à0(valeur d'énumérationOK, réponse HTTP200 OK) et renvoie unIngestEventsResponse,IngestAudienceMembersResponseouRemoveAudienceMembersResponse.Si une requête échoue, modifiez-la pour corriger l'erreur, puis renvoyez-la.
Si une requête aboutit, capturez le
request_idde la réponse pour pouvoir l'utiliser afin de récupérer les diagnostics à l'étape suivante.Attendez 30 minutes, puis envoyez une requête
RetrieveRequestStatuspour chaquerequest_idréussi.Répétez régulièrement cette étape pour chaque
request_idjusqu'à ce que l'état de la destination de chaque destination atteigneSUCCESS,PARTIAL_SUCCESSouFAILURE. Utilisez un algorithme d'intervalle exponentiel entre les tentatives pour attendre entre chaque requête.Examinez chaque
RetrieveRequestStatusResponsepour vérifier que vos importations fonctionnent correctement et identifier les éventuels problèmes liés à vos données.Corrigez les problèmes de données.
Revenez à l'étape 1 et répétez l'opération jusqu'à ce que tous les problèmes liés à vos importations soient résolus.
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 enregistré à partir d'une demande d'ingestion réussie.
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. Cette opération peut prendre jusqu'à 24 heures, bien que l'API Data Manager puisse traiter certaines demandes en à peine 30 minutes.
Voici un exemple de configuration raisonnable du délai d'attente initial et des 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 de l'intervalle entre les tentatives | 1.3 |
| Intervalle maximal entre les tentatives (minutes) | 60 (1 heure) |
| Durée totale maximale (en minutes) | 1440 (24 heures) |
Voici une séquence de requêtes et le temps écoulé avec cette configuration :
Graphique
Données
| Tentative | Temps écoulé depuis la demande d'ingestion (hh:mm) | Délai avant la tentative | Remarques |
|---|---|---|---|
| 1 | 00:30 | 30 min | Vérifiez d'abord si l'état est disponible. |
| 2 | 01:09 | 39 min | |
| 3 | 01:59 | 50,7 min | |
| 4 | 02:59 | 60 min | Le délai est désormais limité à une heure |
| 5 | 03:59 | 60 min | |
| 6 | 04:59 | 60 min | |
| 7 | 05:59 | 60 min | |
| 8 | 06:59 | 60 min | |
| 9 | 07:59 | 60 min | |
| 10 | 08:59 | 60 min | |
| 11 | 09:59 | 60 min | |
| 12 | 10:59 | 60 min | |
| 13 | 11:59 | 60 min | 12 heures |
| 14 | 12:59 | 60 min | |
| 15 | 13:59 | 60 min | |
| 16 | 14:59 | 60 min | |
| 17 | 15:59 | 60 min | |
| 18 | 16:59 | 60 min | |
| 19 | 17:59 | 60 min | |
| 20 | 18:59 | 60 min | |
| 21 | 19:59 | 60 min | |
| 22 | 20:59 | 60 min | |
| 23 | 21:59 | 60 min | |
| 24 | 22:59 | 60 min | |
| 25 | 23:59 | 60 min | Dernière demande avant la durée totale maximale de 24 heures |
Ajoutez une petite quantité aléatoire de gigue aux délais de backoff 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 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 des destinations
Pour commencer, vérifiez le champ request_status afin de déterminer si l'API Data Manager a fini de traiter les données pour le destination de 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 demande 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é. Vérifiez également les avertissements signalés lors du traitement.PARTIAL_SUCCESS: certains enregistrements pour la destination ont été traités, 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
Inspectez le champ d'état qui correspond au type de demande d'ingestion. Un seul 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 une IngestEventsRequest.
Vérifiez le record_count de IngestEventStatus 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é.
État de l'ingestion des membres de l'audience
Le champ audience_members_ingestion_status est renseigné si la requête était une IngestAudienceMembersRequest. Voici le champ IngestAudienceMembersStatus à vérifier pour chaque type de données d'audience. Un seul de ces champs est défini.
user_data_ingestion_statusVérifiez le
record_countdeIngestUserDataStatuspour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes.record_countinclut les enregistrements ayant réussi et ceux ayant échoué.Vérifiez le champ
user_identifier_countpour confirmer que le nombre d'identifiants utilisateur reçus correspond à vos attentes.Si la requête contenait un nombre suffisant d'enregistrements,
upload_match_rate_rangecontient la plage de taux de correspondance pour les enregistrements de la requête.mobile_data_ingestion_statusVérifiez le
record_countdeIngestMobileDataStatuspour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes.record_countinclut les enregistrements ayant réussi et ceux ayant échoué.Vérifiez le
mobile_id_countpour confirmer que le nombre d'identifiants mobiles reçus correspond à vos attentes.pair_data_ingestion_statusVérifiez le
record_countdeIngestPairDataStatuspour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes.record_countinclut les enregistrements ayant réussi et ceux ayant échoué.Vérifiez que le nombre d'ID PAIR reçus correspond à vos attentes en consultant
pair_id_count.ppid_data_ingestion_statusVérifiez le
record_countdeIngestPpidDataStatuspour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes.record_countinclut les enregistrements ayant réussi et ceux ayant échoué.Vérifiez le
ppid_countpour confirmer que le nombre de PPID reçus correspond à vos attentes.user_id_data_ingestion_statusVérifiez le
record_countdeIngestUserIdDataStatuspour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes.record_countinclut les enregistrements ayant réussi et ceux ayant échoué.Vérifiez le champ
user_id_countpour vous assurer que le nombre d'ID utilisateur reçus correspond à vos attentes.composite_data_ingestion_statusVérifiez le
record_countdeIngestCompositeDataStatuspour confirmer que le nombre total d'enregistrements reçus correspond à vos attentes.record_countinclut les enregistrements ayant réussi et ceux ayant échoué.Consultez
data_type_countspour vérifier que le nombre d'identifiants correspond à vos attentes. Cette liste fournit une répartition de tous les identifiants reçus (adresse e-mail, numéro de téléphone, adresse physique et adresse IP, par exemple) parDataType.Si la requête contenait un nombre suffisant d'enregistrements,
upload_match_rate_rangecontient la plage de taux de correspondance pour les enregistrements de la requête.
État de la suppression des membres de l'audience
Le champ audience_members_removal_status est renseigné si la requête était une RemoveAudienceMembersRequest. Voici le champ RemoveAudienceMembersStatus à vérifier pour chaque type de données d'audience. Un seul 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'ID utilisateur
composite_data_removal_status- État de la suppression pour données composites
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 ayant réussi et ceux ayant échoué.
Vérifiez également les éléments user_identifier_count, mobile_id_count, pair_id_count, ppid_count ou user_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 (adresse e-mail, numéro de téléphone, adresse physique et adresse IP, par exemple) 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 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 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 global de la destination atteint SUCCESS, PARTIAL_SUCCESS ou FAILURE.
warning_infoListe d'objets
WarningCount. ChaqueWarningCountcontient unreasonavec le type d'avertissement et unrecord_countindiquant le nombre d'enregistrements ayant ce type d'avertissement.Vérifiez l'
warning_infomême si l'état global de la destination estSUCCESS.error_infoListe d'objets
ErrorCount. ChaqueErrorCountcontient unreasonavec le type d'erreur et unrecord_countindiquant le nombre d'enregistrements ayant échoué en raison de ce type d'erreur.