Une fonction essentielle de nombreuses applications Google Ads consiste à récupérer les données des comptes à utiliser comme l'analyse de données, les demandes des clients et les contrôles de conformité avec le règlement. Lorsque vous récupérez les données, vous devez optimiser votre utilisation afin de ne pas surcharger serveurs Google, ou risque d'être soumis à une limitation du débit. Pour en savoir plus, consultez les guides sur limitation du débit et le maintien 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
GoogleAdsService.Search et
GoogleAdsService.SearchStream schémas de requête qui consomment
de ressources d'API. Si un schéma de requête spécifique est limité,
les services, méthodes et schémas de requête continueront de fonctionner. La
Les erreurs suivantes sont générées pour les requêtes limitées:
| Version de l'API | Code d'erreur |
|---|---|
| <= v17 | QuotaError.RESOURCE_EXHAUSTED |
| Version 18 ou ultérieure | QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION
ou QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION selon
sur la durée d'utilisation intensive des ressources. |
Pour vous aider à identifier et à surveiller vos rapports coûteux, nous vous renverrons également une pour les rapports individuels.
| Méthode | Champ "Cost" (Coût) |
|---|---|
GoogleAdsService.Search |
SearchGoogleAdsResponse.query_resource_consumption |
GoogleAdsService.SearchStream |
SearchGoogleAdsStreamResponse.query_resource_consumption |
La métrique "Coût" renvoyée par ces champs dépend de différents facteurs :
- Taille de vos comptes
- Vues et colonnes extraites dans vos rapports
- Charge supportée par les serveurs de l'API Google Ads.
Pour vous aider à suivre les requêtes coûteuses, nous publions les données agrégées initiales des statistiques sur la consommation des ressources pour les différents schémas de requête que nous voyons nos serveurs. Nous publierons régulièrement des chiffres actualisés pour vous aider à les ajuster vos requêtes.
| Période | Moyenne (p50). | P70 (Moyennement élevé) | P95 (très élevé) |
|---|---|---|---|
| Court terme (5 min) | 6000 | 30000 | 1800000 |
| Long terme (24 h). | 16000 | 90000 | 8400000 |
Par exemple, supposons que vous exécutiez le schéma de requête suivant, 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 qu'elle substitue des valeurs différentes pour segments.date ;
filtre. Le tableau suivant indique le nombre de rapports que vous pouvez générer dans un
période de sorte que votre utilisation des ressources s'intègre dans diverses
Cloud Storage.
| Période | Moyen | Moyennement élevée | Très élevé |
|---|---|---|---|
| Court terme (5 min) | 10 | 50 | 3000 |
| Long terme (24 h). | 26 | 150 | 14000 |
Exécuter ce schéma de requête 10 fois en 5 minutes compte comme une moyenne alors que l'exécution de 3 000 rapports en 5 minutes est considérée comme une utilisation très élevée.
Il existe plusieurs stratégies pour optimiser la consommation des ressources de votre rapports. Le reste de ce guide aborde certaines de ces stratégies.
Mettre vos données en cache
Vous devez mettre en cache les détails de l'entité récupérée sur les serveurs d'API dans un emplacement base de données 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 rarement. Utilisez change-event et change-status où de 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 relatives à la fraîcheur des données et au fonctionnement fréquemment les données sont mises à jour. Vous devez utiliser ces conseils pour déterminer comment fréquemment pour récupérer des rapports.
Si vous avez besoin de mettre à jour vos comptes régulièrement, nous vous recommandons de limiter d'un nombre limité de comptes. Par exemple, seuls les 20 premiers Google Cloud. Le reste peut être mis à jour à une fréquence moins élevée, par exemple, une fois 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 de petits rapports. Un des facteurs qui influencent ce choix est le compte limites.
Prenons l'exemple du code suivant, qui extrait les statistiques d'une annonce spécifique groupes et mettre à 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 test. Toutefois, Google Ads accepte jusqu'à 20 000 groupes d'annonces par campagne et 10 000 campagnes par compte Si ce code s'exécute sur un compte Google Ads volumineux, il peut surcharger les serveurs de l'API Google Ads, ce qui entraîne une limitation et une limitation du débit.
Une meilleure approche serait de générer un seul rapport et de le traiter localement. Un cette approche 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 permet de réduire la charge pesant sur les serveurs de l'API Google Ads, car le nombre de rapports est moins élevé. en cours d'exécution.
Si vous trouvez que le rapport est trop volumineux pour être conservé en mémoire, vous pouvez également interrompre
réduire la requête en groupes plus petits en ajoutant une clause LIMIT comme celle-ci:
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 les entités et de réduire le nombre de rapports requêtes. Pour en savoir plus, consultez le guide des libellés.
Optimisez ce que vous récupérez
Lorsque vous générez des rapports, vous devez faire attention aux colonnes que vous incluez dans vos requêtes. Prenons l'exemple suivant, dont l'exécution est programmée heure:
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 ne sont pas mises à jour fréquemment
il est donc très inefficace de les récupérer toutes les heures. Vous pourriez les stocker
d'une base de données locale et exécuter un événement de modification, ou
un rapport sur l'état des modifications 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.
Éliminer les comptes inutilisés
Si votre application gère des comptes d'annonceurs tiers, développer votre application en gardant à l'esprit la perte de clients. Vous devez régulièrement nettoyer vos processus et data stores afin de supprimer les comptes des clients n'utiliseront plus votre application. Lorsque vous nettoyez les comptes Google Ads inutilisés, gardez à l'esprit les conseils suivants:
- Révoquer l'autorisation de gestion accordée par votre client à votre client leur compte.
- Arrêtez d'effectuer des appels d'API vers les comptes Google Ads du client. Ceci s'applique en particulier pour les jobs hors connexion, comme les jobs Cron et les pipelines de données conçues pour s'exécuter sans l'intervention de l'utilisateur.
- Si le client a révoqué son autorisation, votre application doit alors gérer la situation de façon optimale et éviter d'envoyer des appels d'API non valides à les serveurs d'API de Google.
- Si le client a désactivé son compte Google Ads, vous devez détecter le et d'éviter d'envoyer des appels d'API non valides aux serveurs d'API de Google.
- Supprimez les données téléchargées depuis les comptes Google Ads du client de votre base de données locale après une période appropriée.