Gérer les données efficacement

L'une des fonctions principales de nombreuses applications Google Ads consiste à récupérer les données d'un compte pour des cas d'utilisation tels que l'analyse de données, les requêtes des clients et les contrôles de conformité avec les règles. Lorsque vous récupérez les données, vous devez optimiser votre utilisation afin de ne pas surcharger les serveurs Google, au risque de voir votre débit limité. Pour en savoir plus, consultez les guides sur la limitation du débit et la mise à jour de l'adresse e-mail de contact.

Comprendre les règles d'utilisation des ressources pour les rapports

Remarque : Pour en savoir plus sur cette règle, consultez l'article de blog sur les règles d'utilisation des ressources.

Pour garantir la stabilité de ses serveurs, l'API Google Ads limite les schémas de requête GoogleAdsService.Search et GoogleAdsService.SearchStream qui consomment une quantité excessive de ressources d'API. Si un schéma de requête particulier est limité, les autres services, méthodes et schémas de requête continuent de fonctionner sans être affectés. Les erreurs suivantes sont générées pour les requêtes limitées :

Code d'erreur
QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION ou QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION, selon la durée d'utilisation élevée des ressources.

Si vous rencontrez ces erreurs, attendez cinq minutes avant de relancer les requêtes qui ont échoué avec l'erreur QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION, et 30 minutes pour les requêtes qui ont échoué avec l'erreur QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION.

Pour vous aider à identifier et à surveiller vos rapports coûteux, nous renvoyons également une métrique de coût pour chaque rapport :

Méthode	Champ "Coût"
GoogleAdsService.Search	SearchGoogleAdsResponse.query_resource_consumption
GoogleAdsService.SearchStream	SearchGoogleAdsStreamResponse.query_resource_consumption

La métrique de coût renvoyée par ces champs dépend de plusieurs facteurs, tels que :

• La taille de vos comptes
• Les vues et les colonnes que vous récupérez dans vos rapports
• La charge sur les serveurs de l'API Google Ads

Le tableau suivant présente des statistiques agrégées sur la consommation de ressources de différents schémas de requête sur les serveurs d'API Google Ads. Il vous aide à suivre et à affiner les requêtes coûteuses :

Période	Moyenne (p50)	P70 (moyenne)	P95 (très élevée)
Court terme (5 min)	6000	30000	1800000
Long terme (24 h)	16000	90000	8400000

Par exemple, supposons que vous exécutiez un schéma de requête comme suit, qui consomme 600 unités de ressources par rapport :

SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
    segments.date = 'YYYY-MM-DD'

Vous exécutez cette requête pour plusieurs comptes client à différentes dates en modifiant la requête pour remplacer différentes valeurs du filtre segments.date. Le tableau suivant indique le nombre de rapports que vous pouvez exécuter dans un intervalle de temps donné, de sorte que votre utilisation des ressources s'inscrive dans différents buckets d'utilisation des ressources.

Période	Moyenne	Modérément élevée	Très élevé
Court terme (5 min)	10	50	3000
Long terme (24 h)	26	150	14000

L'exécution de ce schéma de requête 10 fois en 5 minutes serait considérée comme une utilisation moyenne, tandis que l'exécution de 3 000 rapports en 5 minutes serait considérée comme une utilisation très élevée.

Il existe plusieurs stratégies pour optimiser la consommation de ressources de vos rapports. Le reste de ce guide décrit certaines de ces stratégies.

Mettre en cache vos données

Vous devez mettre en cache les détails de l'entité que vous récupérez à partir des serveurs d'API dans une base de données locale au lieu d'appeler le serveur chaque fois que vous avez besoin des données, en particulier pour les entités fréquemment consultées ou qui changent rarement. Utilisez change-event et change-status dans la mesure du possible pour détecter les objets qui ont changé depuis la dernière synchronisation des résultats.

Optimiser la fréquence d'exécution des rapports

Google Ads a publié des consignes concernant la fraîcheur des données et la fréquence de leur mise à jour. Vous devez utiliser ces conseils pour déterminer la fréquence de récupération des rapports.

Si vous devez mettre à jour des comptes régulièrement, nous vous recommandons de limiter le nombre de ces comptes à un petit ensemble, par exemple, les 20 premiers comptes Google Ads. Le reste peut être mis à jour moins fréquemment, par exemple une ou deux fois par jour.

Optimiser la taille de vos rapports

Votre application doit récupérer de grands lots de données au lieu d'exécuter un grand nombre de petits rapports. Les limites du compte sont un facteur qui entre en jeu dans ce choix.

Prenons l'exemple du code suivant, qui extrait les statistiques de groupes d'annonces spécifiques et met à jour une table de base de données de statistiques :

  List<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();

  foreach (long adGroupId in adGroupIds)
  {
    string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
        "metrics.cost_micros, metrics.impressions, segments.date FROM " +
        "ad_group WHERE segments.date DURING LAST_7_DAYS AND " +
        $"ad_group.id = {adGroupId}";
    List<GoogleAdsRow> rows = RunGoogleAdsReport(customerId, query);
    InsertRowsIntoStatsTable(adGroupId, rows);
  }

Ce code fonctionne bien sur un petit compte de test. Toutefois, Google Ads accepte jusqu'à 20 000 groupes d'annonces par campagne et 10 000 campagnes par compte. Par conséquent, si ce code est exécuté sur un compte Google Ads volumineux, il peut surcharger les serveurs de l'API Google Ads, ce qui entraîne une limitation du débit et une limitation de la bande passante.

Une meilleure approche consisterait à exécuter un seul rapport et à le traiter localement. Voici une approche utilisant une carte en mémoire :

  HashSet<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();

  string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
      "metrics.cost_micros, metrics.impressions, segments.date FROM " +
      "ad_group WHERE segments.date DURING LAST_7_DAYS";
  List<GoogleAdsRow> rows = RunGoogleAdsReport(customerId, query);

  var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
  foreach (GoogleAdsRow row in rows)
  {
    long adGroupId = row.AdGroup.Id;

    if (adGroupIds.Contains(adGroupId))
    {
      CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
    }
  }
  foreach (KeyValuePair<long, List<GoogleAdsRow>> entry in memoryMap)
  {
    InsertRowsIntoStatsTable(entry.Key, entry.Value);
  }

Cela réduit la charge sur les serveurs de l'API Google Ads, car moins de rapports sont exécutés.

Si vous constatez que le rapport est trop volumineux pour être conservé en mémoire, vous pouvez également décomposer la requête en groupes plus petits en ajoutant une clause LIMIT comme suit :

SELECT
  ad_group.id,
  ad_group.name,
  metrics.clicks,
  metrics.cost_micros,
  metrics.impressions,
  segments.date
FROM ad_group
WHERE segments.date DURING LAST_7_DAYS
  AND ad_group.id IN (id1, id2, ...)
LIMIT 100000

Les libellés sont un autre moyen de regrouper des entités et de réduire le nombre de requêtes de reporting. Pour en savoir plus, consultez le guide sur les libellés.

Optimiser ce que vous récupérez

Lorsque vous exécutez des rapports, vous devez faire attention aux colonnes que vous incluez dans vos requêtes. Prenons l'exemple suivant, qui est planifié pour s'exécuter toutes les heures :

SELECT
  customer.id,
  customer.currency_code,
  campaign.id,
  campaign.name,
  ad_group.id,
  ad_group.name,
  ad_group_criterion.keyword.match_type,
  ad_group_criterion.keyword.text,
  ad_group_criterion.criterion_id,
  ad_group_criterion.quality_info.creative_quality_score,
  ad_group_criterion.system_serving_status,
  ad_group_criterion.negative,
  ad_group_criterion.quality_info.quality_score,
  ad_group_criterion.quality_info.search_predicted_ctr,
  ad_group_criterion.quality_info.post_click_quality_score,
  metrics.historical_landing_page_quality_score,
  metrics.search_click_share,
  metrics.historical_creative_quality_score,
  metrics.clicks,
  metrics.impressions
FROM keyword_view
WHERE segments.date DURING LAST_7_DAYS

Les seules colonnes susceptibles de changer toutes les heures sont metrics.clicks et metrics.impressions. Toutes les autres colonnes sont mises à jour rarement, voire jamais. Il est donc très inefficace de les récupérer toutes les heures. Vous pouvez stocker ces valeurs dans une base de données locale et exécuter un rapport change-event ou change-status pour télécharger les modifications une ou deux fois par jour.

Dans certains cas, vous pouvez réduire le nombre de lignes que vous téléchargez en appliquant des filtres appropriés.

Supprimer les comptes inutilisés

Si votre application gère des comptes client tiers, vous devez la développer en tenant compte de l'attrition des clients. Vous devez nettoyer régulièrement vos processus et vos datastores pour supprimer les comptes des clients qui n'utilisent plus votre application. Lorsque vous nettoyez des comptes Google Ads inutilisés, tenez compte des conseils suivants :

• Révoquez l'autorisation que votre client a accordée à votre application pour gérer son compte.
• Arrêtez d'effectuer des appels d'API vers les comptes Google Ads du client. Cela s'applique en particulier aux jobs hors connexion, tels que les jobs Cron et les pipelines de données, qui sont conçus pour s'exécuter sans intervention de l'utilisateur.
• Si le client a révoqué son autorisation, votre application doit gérer la situation de manière appropriée et éviter d'envoyer des appels d'API non valides aux serveurs d'API de Google.
• Si le client a désactivé son compte Google Ads, vous devez détecter les comptes désactivés et éviter d'envoyer des appels d'API non valides aux serveurs d'API de Google.
• Supprimez de votre base de données locale les données que vous avez téléchargées à partir des comptes Google Ads du client après un délai approprié.