Bonnes pratiques en matière de création de rapports

Créer d'abord de nouveaux rapports dans l'interface utilisateur

Les rapports sont soumis à un certain nombre de restrictions et d'exigences concernant les types, filtres, dimensions et métriques de rapports. Ces limites sont appliquées dans l'API, renvoyant une erreur HTTP 400. Pour éviter les erreurs lors de la création des rapports, nous vous recommandons de commencer par en créer dans l'interface utilisateur de Display & Video 360.

Après avoir créé votre rapport, cliquez sur la fonctionnalité Essayer cette API sur la page de la documentation de référence pour effectuer une queries.get de la ressource Query. Vous pouvez utiliser le fichier JSON renvoyé pour créer de futurs rapports.

Utiliser des métriques et des filtres spécifiques au type de rapport

Certaines valeurs de métriques et de filtres sont spécifiques à certains types de rapports. En plus de créer d'abord vos rapports dans l'interface utilisateur, vous pouvez également identifier les métriques et les filtres associés à certaines valeurs ReportType par leur valeur d'API Bid Manager.

Voici quelques façons d'identifier les filtres et les valeurs de métriques pertinents pour l'API Bid Manager. Ce tableau n'est pas une liste exhaustive des filtres et des métriques utilisables dans ces types de rapports. Les valeurs ne peuvent pas toutes être utilisées ensemble dans un même rapport.

ReportType Filtres et statistiques pertinents
INVENTORY_AVAILABILITY
  • Filtres avec le préfixe FILTER_TRUEVIEW_IAR.
YOUTUBE
  • Filtres avec le préfixe FILTER_TRUEVIEW, à l'exception de ceux avec le préfixe FILTER_TRUEVIEW_IAR.
  • Métriques avec le préfixe METRIC_TRUEVIEW.
GRP
  • Métriques avec le préfixe METRIC_GRP.
YOUTUBE_PROGRAMMATIC_GUARANTEED
  • Filtres avec le préfixe FILTER_YOUTUBE_PROGRAMMATIC_GUARANTEED
  • Métriques avec le préfixe METRIC_PROGRAMMATIC_GUARANTEED.
REACH
  • Métriques avec le préfixe METRIC_UNIQUE_REACH.
UNIQUE_REACH_AUDIENCE
  • Métriques avec le préfixe METRIC_UNIQUE_REACH.

Enregistrer et réutiliser des rapports

Nous vous recommandons de créer et d'enregistrer des rapports pour les requêtes que vous exécutez régulièrement, car l'insertion et la suppression multiples du même rapport gaspillent des ressources. L'utilisation des valeurs Range définies, telles que PREVIOUS_DAY ou LAST_7_DAYS, dans le champ dataRange facilite la réutilisation des rapports.

Planifier des rapports

Les rapports ponctuels ou ponctuels peuvent gaspiller des ressources, car ils sont exécutés individuellement et peuvent être exécutés sur un ensemble de données incomplet. Les rapports planifiés utilisent au mieux les ressources des rapports, car ils sont exécutés de manière groupée et ne s'exécuteront pas avant la fin du traitement des données du jour précédent. Pour en savoir plus, consultez les champs de planification disponibles.

Combiner des rapports similaires

Si vous générez régulièrement des rapports avec des métriques et des plages de dates identiques pour différents annonceurs ou partenaires, nous vous recommandons de les combiner afin d'optimiser leur volume de rapports.

Vous pouvez combiner des rapports similaires en ajoutant les filtres de tous les rapports et en ajoutant tous les types de filtres en tant que dimensions. Après la génération, vous pouvez diviser les lignes du rapport obtenu en fonction des valeurs du filtre d'origine pour générer les rapports d'origine.

Envisager les quotas de reporting

Les quotas d'utilisation ci-dessous s'appliquent à l'ensemble du produit afin de garantir une utilisation responsable de la fonctionnalité de création de rapports de Display & Video 360.

Exécutions de rapports ad hoc par jour

Limite le nombre de rapports ponctuels qu'un utilisateur peut exécuter sur une période de 24 heures. Pour rester en deçà de ce quota:

Rapports planifiés actifs

Limite le nombre de rapports qu'un utilisateur peut avoir activement planifiés à un moment donné. Pour rester en deçà de ce quota:

Rapports simultanés

Limite le nombre de rapports qu'un utilisateur peut générer simultanément. Pour rester en deçà de ce quota:

Si vous avez optimisé l'implémentation des rapports et que vous dépassez toujours le quota indiqué, contactez l'assistance Display & Video 360 à l'aide du formulaire de contact.

Utiliser un intervalle exponentiel entre les tentatives lors de l'interrogation de l'état du rapport

Il n'est pas possible de prévoir le temps nécessaire à l'exécution d'un rapport. Cette durée peut aller de quelques secondes à plusieurs heures en fonction de nombreux facteurs, y compris la plage de dates et la quantité de données à traiter, par exemple. Il n'y a pas non plus de corrélation entre la date d'exécution du rapport et le nombre de lignes qu'il renvoie. Vous devez donc récupérer régulièrement la ressource de rapport à l'aide de la méthode queries.reports.get et vérifier si le champ metadata.status.state de la ressource a été remplacé par DONE ou FAILED pour déterminer si l'exécution est terminée. Il s'agit d'un processus appelé "sondage".

Bien que l'interrogation soit nécessaire, une mise en œuvre inefficace peut rapidement épuiser votre quota en cas de rapport à long terme. C'est pourquoi nous vous recommandons d'utiliser un intervalle exponentiel entre les tentatives pour limiter les tentatives et préserver le quota.

Intervalle exponentiel entre les tentatives

L'intervalle exponentiel entre les tentatives est une stratégie standard de traitement des erreurs pour les applications réseau, selon laquelle le client relance périodiquement la requête sur une durée croissante. Utilisé correctement, l'intervalle exponentiel entre les tentatives augmente l'efficacité de l'utilisation de la bande passante, réduit le nombre de requêtes nécessaires pour obtenir une réponse positive et optimise le débit des requêtes dans les environnements avec simultanéité.

Le fonctionnement de l'intervalle exponentiel simple entre les tentatives se présente comme suit :

  1. Envoyez une requête queries.reports.get à l'API.
  2. Récupérez l'objet de rapport. Si le champ metadata.status.state n'est pas DONE ou FAILED, cela signifie que l'interrogation du rapport n'est pas terminée.
  3. Vous patientez cinq secondes plus un nombre aléatoire de millisecondes, puis relancez la requête.
  4. Récupérez l'objet de rapport. Si le champ metadata.status.state n'est pas DONE ou FAILED, cela signifie que l'interrogation du rapport n'est pas terminée.
  5. Vous patientez 10 secondes plus un nombre aléatoire de millisecondes, puis relancez la requête.
  6. Récupérez l'objet de rapport. Si le champ metadata.status.state n'est pas DONE ou FAILED, cela signifie que l'interrogation du rapport n'est pas terminée.
  7. Vous patientez 20 secondes plus un nombre aléatoire de millisecondes, puis relancez la requête.
  8. Récupérez l'objet de rapport. Si le champ metadata.status.state n'est pas DONE ou FAILED, cela signifie que l'interrogation du rapport n'est pas terminée.
  9. Vous patientez 40 secondes plus un nombre aléatoire de millisecondes, puis relancez la requête.
  10. Récupérez l'objet de rapport. Si le champ metadata.status.state n'est pas DONE ou FAILED, cela signifie que l'interrogation du rapport n'est pas terminée.
  11. Vous patientez 80 secondes plus un nombre aléatoire de millisecondes, puis relancez la requête.
  12. Continuez cette procédure jusqu'à ce que l'objet de rapport soit mis à jour ou qu'un délai maximal soit atteint.

Si l'exécution du rapport se termine et se termine à l'état DONE, vous pouvez récupérer le fichier de rapport généré depuis Google Cloud Storage, en utilisant le chemin d'accès indiqué dans le champ metadata.googleCloudStoragePath.