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

Créez d'abord des rapports dans l'UI

Les rapports sont soumis à un certain nombre de restrictions et d'exigences concernant les types de rapports, les filtres, les dimensions et les métriques. Ces limites sont appliquées dans l'API et renvoient une erreur HTTP 400. Pour éviter les erreurs lors de la création de 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 documentation de référence pour effectuer une queries.get de la ressource Query. Vous pouvez utiliser le fichier JSON renvoyé pour créer d'autres rapports.

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

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

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

ReportType Filtres et métriques pertinents
YOUTUBE
  • Filtres avec le préfixe FILTER_TRUEVIEW.
  • 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 insérer et supprimer plusieurs fois le même rapport gaspille des ressources. L'utilisation des valeurs Range définies, telles que PREVIOUS_DAY ou LAST_7_DAYS, dans le champ dataRange rend les rapports plus réutilisables.

Planifier des rapports

Les rapports ponctuels ou ad hoc peuvent gaspiller des ressources, car ils sont exécutés individuellement et peuvent s'exécuter sur un ensemble de données incomplet. Les rapports planifiés exploitent au mieux les ressources de création de rapports, car ils sont exécutés de manière groupée et ne s'exécutent qu'une fois le traitement des données du jour précédent terminé. 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 périodes identiques pour différents annonceurs ou partenaires, nous vous recommandons de les combiner pour optimiser leur volume.

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. Une fois le rapport généré, vous pouvez diviser les lignes du rapport généré en fonction des valeurs de filtre d'origine pour générer les rapports d'origine.

Prendre en compte les quotas de création de rapports

L'utilisation responsable de la fonctionnalité de création de rapports Display & Video 360 est appliquée via les quotas d'utilisation suivants pour l'ensemble du produit.

Exécutions de rapports ad hoc par jour

Limite le nombre de rapports ad hoc qu'un utilisateur peut exécuter sur une période de 24 heures. Pour ne pas dépasser ce quota:

Rapports planifiés actifs

Limite le nombre de rapports qu'un utilisateur peut planifier activement à un moment donné. Pour ne pas dépasser ce quota:

Rapports simultanés

Limite le nombre de rapports qu'un utilisateur peut exécuter simultanément. Pour ne pas dépasser ce quota:

Si vous avez optimisé l'implémentation de vos rapports et que vous dépassez toujours votre quota, 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 est impossible de prédire la durée d'exécution d'un rapport. La durée peut aller de quelques secondes à plusieurs heures, en fonction de nombreux facteurs, comme la période et la quantité de données à traiter. Il n'y a pas non plus de corrélation entre le temps d'exécution du rapport et le nombre de lignes renvoyées dans le rapport. 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é mis à jour avec DONE ou FAILED pour déterminer si l'exécution est terminée. Il s'agit d'un processus appelé "interrogation".

Bien que l'interrogation soit nécessaire, une implémentation inefficace peut rapidement épuiser votre quota en cas de rapport de longue durée. Par conséquent, nous vous recommandons d'utiliser un intervalle exponentiel entre les tentatives pour limiter les nouvelles tentatives et préserver les quotas.

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 une requête sur une durée de plus en plus longue. 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 du rapport. Si le champ metadata.status.state n'est pas DONE ou FAILED, cela signifie que l'exécution du rapport n'est pas terminée et que l'interrogation doit se poursuivre.
  3. Vous patientez 5 secondes plus un nombre aléatoire de millisecondes, puis vous relancez la requête.
  4. Récupérez l'objet du rapport. Si le champ metadata.status.state n'est pas DONE ou FAILED, cela signifie que l'exécution du rapport n'est pas terminée et que l'interrogation doit se poursuivre.
  5. Vous patientez 10 secondes plus un nombre aléatoire de millisecondes, puis vous relancez la requête.
  6. Récupérez l'objet du rapport. Si le champ metadata.status.state n'est pas DONE ou FAILED, cela signifie que l'exécution du rapport n'est pas terminée et que l'interrogation doit se poursuivre.
  7. Vous patientez 20 secondes plus un nombre aléatoire de millisecondes, puis vous 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'exécution du rapport n'est pas terminée et que l'interrogation doit se poursuivre.
  9. Vous patientez 40 secondes plus un nombre aléatoire de millisecondes, puis vous relancez la requête.
  10. Récupérez l'objet du rapport. Si le champ metadata.status.state n'est pas DONE ou FAILED, cela signifie que l'exécution du rapport n'est pas terminée et que l'interrogation doit se poursuivre.
  11. Vous patientez 80 secondes plus un nombre aléatoire de millisecondes, puis vous relancez la requête.
  12. Poursuivez ce modèle 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 par un état DONE, vous pouvez récupérer le fichier de rapport généré à partir de Google Cloud Storage au chemin d'accès indiqué dans le champ metadata.googleCloudStoragePath.