Optimisation des quotas

L'optimisation des quotas est indispensable pour toute application utilisant l'API Display & Video 360. L'optimisation de l'utilisation des quotas améliore les performances en simplifiant les requêtes d'API et en vous aidant à éviter les erreurs renvoyées lorsque vous dépassez les limites de débit définies.

Cette page présente les bonnes pratiques générales et met en avant les fonctionnalités supplémentaires de l'API Display & Video 360 qui peuvent vous aider à réduire votre utilisation des quotas.

Envoyer des requêtes simultanées à différents annonceurs

La plupart des méthodes de l'API Display & Video 360 spécifient un annonceur dans l'URL. En plus du quota au niveau du projet, des limites de tarifs par annonceur et par projet plus restrictives sont appliquées à ces méthodes lorsque vous effectuez des appels spécifiant le même annonceur.

Pour optimiser ce quota, limitez les requêtes simultanées à celles qui spécifient différents annonceurs.

Utiliser les paramètres pageSize, filter et orderBy

Utilisez les méthodes list au lieu des méthodes get lorsque vous récupérez plusieurs ressources. En raison des limites de taille de page, les appels list peuvent toujours consommer beaucoup de quota.

Optimisez toutes vos requêtes list en définissant le paramètre pageSize sur la valeur maximale autorisée. La taille de page par défaut d'une méthode, utilisée lorsque le paramètre n'est pas défini, peut être inférieure à sa valeur maximale autorisée et nécessiter davantage de requêtes pour récupérer une liste exhaustive de ressources.

Si vous ne devez récupérer qu'un sous-ensemble de la réponse de la liste complète, vous pouvez optimiser l'utilisation des quotas en profitant des paramètres filter et orderBy facultatifs.

Le paramètre filter vous permet de limiter les ressources récupérées par l'appel list à celles dont les propriétés respectent des expressions données. Ce paramètre est utile lorsque vous essayez de récupérer:

  • Ressource spécifique dont l'ID est inconnu, mais dont les propriétés sont connues Si vous recherchez une ressource spécifique, vous pouvez filtrer la liste renvoyée par les propriétés connues de la ressource souhaitée. Par exemple, vous pouvez filtrer les éléments de campagne en fonction d'un displayName connu, les créations en fonction de l'creativeType attendue et les sources d'inventaire en fonction du exchange approprié.
  • Ressources associées Les ressources de Display & Video 360 sont souvent associées les unes aux autres. Vous pouvez utiliser des filtres pour limiter les ressources renvoyées à celles qui ont une relation spécifique avec une autre. Par exemple, vous pouvez récupérer tous les ordres d'insertion sous un campaignId spécifique et toutes les créations attribuées à un élément de campagne.
  • Seules les ressources qui disposent de propriétés exploitables. La fonctionnalité de l'API vous permet de vérifier facilement l'état des ressources et de réagir de manière programmatique. Grâce aux filtres, vous pouvez utiliser des appels list pour n'obtenir que les ressources nécessitant une action. Par exemple, vous pouvez récupérer tous les éléments de campagne qui affichent un lineItemWarningMessage exploitable, toutes les commandes d'insertion qui ont été mises à jour depuis une date et une heure données, ou toutes les créations dont l'approvalStatus a échoué.

Le paramètre orderBy vous permet de trier les ressources récupérées par des propriétés spécifiques, dans l'ordre croissant ou décroissant. orderBy, en particulier lorsqu'il est utilisé avec filter, peut être utilisé pour limiter le nombre de pages à parcourir avant de trouver une ressource spécifique. Il vous permet également d'obtenir facilement les limites supérieure et inférieure d'une liste de ressources. Par exemple, l'ordre updateTime vous permet de trouver rapidement les éléments de campagne ou les ordres d'insertion d'un annonceur les plus récemment mis à jour.

Utiliser des fonctions groupées et à l'échelle de la ressource

L'API Display & Video 360 propose un certain nombre de fonctions groupées et à l'échelle des ressources qui exécutent de nombreuses actions avec une seule requête. Voici quelques exemples de ces types de fonctions:

  • Modifier de manière groupée les sites appartenant à une seule chaîne Des milliers de sites peuvent être attribués à une chaîne. Au lieu de gérer la liste de sites d'un canal à l'aide de requêtes create ou delete individuelles, vous pouvez utiliser une seule requête bulkEdit ou replace pour ajouter et supprimer de nombreux sites, ou remplacer l'intégralité du contenu d'un canal, respectivement.
  • Gérer l'ensemble de la suite de ciblage d'un annonceur La suite de ciblage d'une ressource est attribuée à plusieurs types de ciblage. Les fonctions de ciblage au niveau des ressources, telles que listAssignedTargetingOptions et editAssignedTargetingOptions dans le service advertisers, vous permettent de récupérer, de créer et de supprimer du ciblage pour plusieurs types de ciblage en une seule requête. Cela permet de réduire le coût du quota lié à la configuration de la suite de ciblage d'un annonceur sur une seule requête.
  • Définir la même restriction de ciblage pour plusieurs éléments de campagne Si vous devez apporter les mêmes modifications de ciblage à plusieurs éléments de campagne à la fois, vous pouvez le faire à l'aide d'une seule requête advertisers.lineItems.bulkEditAssignedTargetingOptions.
  • Activer ou mettre en veille plusieurs éléments de campagne Les éléments de campagne doivent être activés après leur création pour commencer à être diffusés. Si vous créez plusieurs éléments de campagne en succession rapide, vous pouvez tous les activer avec une seule requête advertisers.lineItems.bulkUpdate. Vous pouvez utiliser la même méthode pour mettre en veille plusieurs éléments de campagne afin de les empêcher de diffuser des annonces.

Mettre en cache et vérifier les ID utilisés régulièrement

De nombreuses opérations de l'API Display & Video 360 nécessitent l'utilisation d'ID de ressources récupérés via l'API elle-même, y compris les ID d'options de ciblage, les ID d'audience Google, etc. Pour éviter de récupérer les ID de l'API à chaque utilisation, nous vous recommandons de les stocker localement.

Toutefois, certaines ressources peuvent être abandonnées, supprimées ou rendues inutilisables. La tentative d'utilisation des ID de ces ressources peut renvoyer une erreur. Par conséquent, nous vous recommandons de vérifier tous les ID mis en cache chaque semaine à l'aide de la méthode get ou list filtrée appropriée pour vous assurer qu'ils sont toujours récupérables et qu'ils ont l'état attendu.

Implémenter un intervalle exponentiel entre les tentatives pour les opérations de longue durée

Lorsque vous vérifiez si une opération de longue durée, telle qu'une tâche de téléchargement SDF, est terminée, utilisez une stratégie d'intervalle exponentiel entre les tentatives pour réduire la fréquence et le nombre total de requêtes envoyées.

L'intervalle exponentiel entre les tentatives est une stratégie standard de traitement d'erreurs pour les applications réseau, selon laquelle le client relance périodiquement les requêtes 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é.

Vous trouverez la stratégie d'intervalle exponentiel entre les tentatives implémentée avec les bibliothèques clientes dans nos exemples de code de téléchargement SDF. Le fonctionnement de l'intervalle exponentiel simple entre les tentatives se présente comme suit:

  • Envoyez une requête sdfdownloadtasks.operations.get à l'API.
  • Récupérez l'objet d'opération.
    • Si le champ done n'est pas défini sur "true", cela signifie que vous devez relancer la requête.
    • Vous patientez 5 secondes plus un nombre aléatoire de millisecondes, puis vous relancez la requête.
  • Récupérez l'objet d'opération.
    • Si le champ done n'est pas défini sur "true", cela signifie que vous devez relancer la requête.
    • Vous patientez 10 secondes + un nombre aléatoire de millisecondes, puis vous relancez la requête.
  • Récupérez l'objet d'opération.
    • Si le champ done n'est pas défini sur "true", cela signifie que vous devez relancer la requête.
    • Vous patientez 20 secondes plus un nombre aléatoire de millisecondes, puis vous relancez la requête.
  • Récupérez l'objet d'opération.
    • Si le champ done n'est pas défini sur "true", cela signifie que vous devez relancer la requête.
    • Vous patientez 40 secondes plus un nombre aléatoire de millisecondes, puis vous relancez la requête.
  • Récupérez l'objet d'opération.
    • Si le champ done n'est pas défini sur "true", cela signifie que vous devez relancer la requête.
    • Vous patientez 80 secondes plus un nombre aléatoire de millisecondes, puis vous relancez la requête.
  • Continuez ce modèle jusqu'à ce que l'objet de requête soit mis à jour ou qu'un délai maximal soit atteint.