Une fonction essentielle de nombreuses applications Google Ads consiste à récupérer les données de compte pour des cas d'utilisation tels que l'analyse de données, les requêtes des clients et la vérification du respect des règles. Lors de la récupération des données, vous devez optimiser votre utilisation de manière à ne pas surcharger les serveurs Google ni à ne pas limiter le débit. Pour en savoir plus, consultez les guides sur la limitation du débit et la mise à jour d'une adresse e-mail de contact à jour.
Comprendre les règles d'utilisation des ressources de Google pour les rapports
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 des quantités excessives de ressources API. Si un schéma de requête particulier est limité, les autres services, méthodes et modèles de requête continuent de fonctionner comme tels. Les erreurs suivantes sont générées pour les requêtes limitées:
| Version de l'API | Code d'erreur |
|---|---|
| <= v16 | QuotaError.RESOURCE_EXHAUSTED |
| >= v17 | QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION ou QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION en fonction de la durée d'utilisation intensive des ressources. |
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 "Cost" (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 différents facteurs, par exemple :
- La taille de vos comptes
- Vues et colonnes récupérées dans vos rapports
- Charge sur les serveurs de l'API Google Ads.
Pour vous aider à suivre les requêtes coûteuses, nous publions des statistiques initiales agrégées relatives à la consommation des ressources des différents schémas de requête observés sur nos serveurs. Nous publierons régulièrement des chiffres mis à jour pour vous aider à affiner vos requêtes.
| Période | Moyenne (p50). | P70 (moyennement élevé) | P95 (très élevé) |
|---|---|---|---|
| Court terme (5 min) | 6000 | 30000 | 1800000 |
| Long terme (24 heures). | 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 la modifiant pour remplacer différentes valeurs pour le filtre segments.date. Le tableau suivant indique le nombre de rapports que vous pouvez générer sur une période donnée, de sorte que votre utilisation des ressources s'adapte à différents buckets.
| Période | Moyen | Assez élevé | Très élevé |
|---|---|---|---|
| Court terme (5 min) | 10 | 50 | 3 000 |
| Long terme (24 heures). | 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 des ressources de vos rapports. Le reste de ce guide aborde certaines de ces stratégies.
Mettre en cache vos données
Vous devez mettre en cache les détails des entités que vous extrayez 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 modifiés depuis la dernière synchronisation des résultats.
Optimiser la fréquence de génération des rapports
Google Ads a publié des consignes concernant la fraîcheur des données et la fréquence de mise à jour des données. Suivez 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 comptes de ce type (par exemple, uniquement les 20 comptes Google Ads les plus performants). Le reste peut être mis à jour à une fréquence plus faible, 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 pris en compte 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. Ainsi, si ce code est exécuté sur un compte Google Ads volumineux, il peut surcharger les serveurs de l'API Google Ads, ce qui peut entraîner une limitation du débit et une limitation du débit.
Une meilleure approche consiste à générer un seul rapport et à le traiter localement. Nous allons voir ici une de ces approches 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(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 permet de réduire la charge sur les serveurs de l'API Google Ads, car le nombre de rapports générés est plus faible.
Si vous trouvez que le rapport est trop volumineux pour être conservé en mémoire, vous pouvez également diviser la requête en plus petits groupes 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 constituent 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 des étiquettes.
Optimiser les données récupérées
Lorsque vous générez des rapports, faites attention aux colonnes que vous incluez dans vos requêtes. Prenons l'exemple suivant, 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. Les autres colonnes ne sont pas mises à jour fréquemment, voire pas du tout. Il est donc très inefficace de les extraire 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.
Nettoyer les comptes inutilisés
Si votre application gère des comptes d'annonceurs tiers, vous devez la développer en tenant compte de la perte de clients. Vous devez nettoyer régulièrement vos processus et datastores afin de supprimer les comptes des clients qui n'utilisent plus votre application. Lorsque vous nettoyez les comptes Google Ads inutilisés, tenez compte des conseils suivants:
- Révoquez l'autorisation accordée par votre client à votre application pour gérer son compte.
- Cessez 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 correctement la situation 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 le détecter et éviter d'envoyer des appels d'API non valides aux serveurs d'API 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 au terme d'un délai approprié.