Une fonction essentielle de nombreuses applications Google Ads consiste à récupérer les données du compte pour des cas d'utilisation tels que l'analyse des données, les requêtes des clients et les vérifications de la conformité avec le règlement. Lorsque vous récupérez les données, vous devez optimiser votre utilisation afin de ne pas surcharger les serveurs Google ni risquer d'être limité. Pour en savoir plus, consultez les guides sur la limitation du débit et sur la mise à jour de l' adresse e-mail de contact.
Comprendre les règles d'utilisation des ressources Google pour les rapports
Pour assurer la stabilité de ses serveurs, l'API Google Ads limite
GoogleAdsService.Search et
GoogleAdsService.SearchStream les modèles de requête qui consomment des quantités excessives
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 continueront 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 de l'utilisation élevée des ressources. |
Si vous rencontrez ces erreurs, attendez cinq minutes avant de réessayer les requêtes qui ont échoué avec QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION, et 30 minutes pour les requêtes qui ont échoué avec QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION.
Pour vous aider à identifier et à surveiller vos rapports coûteux, nous renverrons également une métrique de coût pour les rapports individuels.
| Méthode | Champ de 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.
Pour vous aider à suivre les requêtes coûteuses, nous publions des statistiques agrégées initiales sur la consommation de ressources des différents modèles de requête que nous observons sur nos serveurs. Nous publierons régulièrement des chiffres mis à jour pour vous aider à affiner vos requêtes.
| Période | Moyenne (p50) | P70 (moyenne-élevée) | 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écutez 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 pour plusieurs dates individuelles en modifiant la requête afin de remplacer différentes valeurs pour le filtre segments.date. Le tableau suivant indique le nombre de rapports que vous pouvez exécuter dans une période donnée afin que votre utilisation des ressources s'inscrive dans différents buckets d'utilisation des ressources.
| Période | Moyenne | Moyenne-élevée | Très élevée |
|---|---|---|---|
| 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 cinq minutes serait considérée comme une utilisation moyenne, tandis que l'exécution de 3 000 rapports en cinq 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 couvre 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 auxquelles vous accédez fréquemment 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 sur la fraîcheur des données et la fréquence à laquelle elles sont mises à jour. Vous devez suivre ces consignes pour déterminer la fréquence à laquelle vous devez récupérer les rapports.
Si vous devez mettre à jour régulièrement des comptes, nous vous recommandons de limiter le nombre de ces comptes à un petit ensemble, par exemple, uniquement les 20 premiers comptes Google Ads. Les autres peuvent ê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 de 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 grand compte Google Ads, il peut surcharger les serveurs de l'API Google Ads, ce qui entraîne une limitation du débit et une limitation.
Une meilleure approche consiste à exécuter un seul rapport et à le traiter localement. Une approche de ce type utilisant une carte en mémoire est présentée.
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(customer_id, query);
var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
for each (GoogleAdsRow row in rows)
{
var adGroupId = row.AdGroup.Id;
if (adGroupIds.Contains(adGroupId))
{
CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
}
}
foreach (long adGroupId in memoryMap.Keys())
{
InsertRowsIntoStatsTable(adGroupId, rows);
}
Cela réduit la charge sur les serveurs de l'API Google Ads en raison du nombre moins élevé de rapports exécutés.
Si vous constatez que le rapport est trop volumineux pour être conservé en mémoire, vous pouvez également diviser 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 rapport. 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 tenir compte des colonnes que vous incluez dans vos requêtes. Prenons l'exemple suivant, qui est programmé 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 pas du tout. 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 les filtres appropriés.
Supprimer les comptes non utilisés
Si votre application gère des comptes client tiers, vous devez la développer en tenant compte du taux de désabonnement des clients. Vous devez régulièrement nettoyer vos processus et vos datastores pour supprimer les comptes des clients qui n'utilisent plus votre application. Lorsque vous nettoyez des comptes Google Ads non utilisés, tenez compte des consignes suivantes :
- 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 tâches hors connexion telles que les tâches cron et les pipelines de données 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 correctement et éviter d'envoyer des appels d'API non valides aux serveurs d'API de Google.
- Si le client a résilié son compte Google Ads, vous devez détecter le et éviter d'envoyer des appels d'API non valides aux serveurs d'API de Google.
- Supprimez les données que vous avez téléchargées à partir des comptes Google Ads du client de votre base de données locale après une période appropriée.