Optimisation des quotas

L'optimisation des quotas est impérative pour toute application qui utilise l'API Display & Video 360. Optimiser l'utilisation des quotas permet d'améliorer les performances en simplifiant les requêtes API et en vous aidant à éviter les erreurs renvoyées en cas de dépassement des limites de débit définies.

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

Envoyer des demandes 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 des quotas à l'échelle du projet, des limites de débit 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 spécifiant différents annonceurs.

Utilisez les paramètres filter et orderBy.

Utilisez les méthodes list au lieu des méthodes get lorsque vous récupérez plusieurs ressources. Toutefois, les appels list peuvent toujours consommer un quota important en raison des limites de taille de page. 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 du quota à l'aide des paramètres facultatifs filter et orderBy.

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 lors d'une tentative de récupération des éléments suivants:

  • Ressource spécifique avec un ID inconnu, mais des propriétés connues. Si vous recherchez une ressource spécifique, vous pouvez filtrer la liste renvoyée en fonction des 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 des creativeType attendus et les sources d'inventaire pertinentes en fonction des valeurs exchange pertinentes.
  • Ressources associées. Les ressources dans Display & Video 360 sont souvent associées les unes aux autres. Vous pouvez utiliser des filtres pour limiter les ressources renvoyées à celles ayant 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.
  • Uniquement les ressources dont les propriétés sont exploitables. Les fonctionnalités de l'API vous permettent de vérifier facilement l'état des ressources et de réagir par programmation. À l'aide de filtres, vous pouvez utiliser des appels list pour n'obtenir que les ressources pour lesquelles une action est nécessaire. Par exemple, vous pouvez récupérer tous les éléments de campagne qui affichent un lineItemWarningMessage exploitable, tous les ordres d'insertion qui ont été mis à jour depuis une date/heure donnée ou toutes les créations dont l'élément approvalStatus a échoué.

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

Utiliser des fonctions groupées et à l'échelle des ressources

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

  • Modification groupée de sites appartenant à un seul canal. Les canaux peuvent être associés à des milliers de sites. Au lieu de gérer la liste de sites d'une chaîne avec des requêtes create ou delete individuelles, vous pouvez utiliser une seule requête bulkEdit ou replace pour ajouter et supprimer de nombreux sites, ou pour remplacer l'intégralité du contenu d'une chaîne, respectivement.
  • Vous gérez 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, créer et supprimer un ciblage pour plusieurs types de ciblage à l'aide d'une seule requête. Cela permet de réduire le coût du quota lié à la définition de la suite de ciblage d'un annonceur pour une seule demande.
  • Définissez 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 utiliser 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 pouvoir être diffusés. Si vous créez plusieurs éléments de campagne à la suite, vous pouvez tous les activer à l'aide d'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 d'arrêter leur diffusion.

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

De nombreuses opérations dans 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'option de ciblage, les ID d'audience Google, etc. Pour éviter de récupérer les ID de l'API lors de chaque utilisation, nous vous recommandons de les stocker localement.

Cependant, certaines ressources peuvent être obsolètes, supprimées ou rendues inaccessibles. Toute tentative d'utilisation des ID de ces ressources peut renvoyer une erreur. Par conséquent, nous vous recommandons de vérifier chaque semaine tous les ID mis en cache à l'aide de la méthode get appropriée ou de la méthode list filtrée pour vous assurer qu'ils peuvent toujours être récupérés et qu'ils présentent l'état attendu.

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

Lorsque vous interrogez pour vérifier si une opération de longue durée, telle qu'une tâche de téléchargement de fichiers 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 des erreurs pour les applications réseau, où le client relance régulièrement les requêtes 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 maximise le débit des requêtes dans des environnements simultanés.

Vous trouverez la stratégie d'intervalle exponentiel entre les tentatives mise en œuvre avec les bibliothèques clientes dans nos exemples de code de téléchargement de fichiers SDF. La procédure détaillée pour implémenter un intervalle exponentiel simple entre les tentatives est le suivant:

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