Limites et quotas des API

L'API Google Ads applique des limites aux opérations d'API, telles que le nombre d'opérations pouvant être envoyées dans une seule requête de modification. Le tableau suivant récapitule certaines des limites et certains des quotas importants à connaître.

Type de requête, limite et code d'erreur
Opérations avec le niveau d'accès Test 15 000 opérations d'API par jour sur les comptes de test RESOURCE_EXHAUSTED
Opérations avec le niveau d'accès Explorateur 2 880 opérations d'API par jour sur les comptes de production
15 000 opérations d'API par jour sur les comptes de test
RESOURCE_EXHAUSTED
Opérations avec le niveau d'accès de base 15 000 opérations d'API par jour pour les comptes de test et de production RESOURCE_EXHAUSTED
Opérations avec le niveau d'accès Standard Nombre illimité d'opérations d'API par jour pour les comptes de test et de production N/A
Requêtes de modification 10 000 opérations de modification par requête TOO_MANY_MUTATE_OPERATIONS
Demandes de service de planification 1 RPS RESOURCE_EXHAUSTED
Requêtes du service d'importation de conversions 2 000 conversions par requête TOO_MANY_CONVERSIONS_IN_REQUEST
Demandes de service de facturation et de budget du compte Une opération par requête de modification TOO_MANY_MUTATE_OPERATIONS

Limites quotidiennes d'opérations d'API

Les limites d'utilisation quotidienne de l'API sont basées sur le nombre d'opérations d'API effectuées par votre projet Google Cloud. Les opérations d'API correspondent à la somme totale des requêtes Search et SearchStream, des opérations de mutation individuelles et des autres demandes de service. Les limites des opérations d'API quotidiennes dépendent du niveau d'accès à l'API de votre projet Google Cloud. Le guide sur les niveaux d'accès et l'utilisation autorisée décrit les limites d'utilisation spécifiques de l'API pour chaque niveau d'accès.

Les requêtes qui ne respectent pas ces limites sont rejetées avec l'erreur RESOURCE_EXHAUSTED.

Limites de gRPC

Toutes les bibliothèques clientes de l'API Google Ads utilisent gRPC pour générer des requêtes et des réponses. Par défaut, gRPC a une taille de message de 4 Mo, mais nos bibliothèques clientes définissent la taille maximale des messages sur 64 Mo afin d'accroître l'efficacité.

Les réponses ne doivent pas dépasser cette limite. Par exemple, une requête de recherche incluant de nombreux champs peut générer une réponse dont la taille dépasse 64 Mo. Pour éviter cette limite, vous pouvez réduire le nombre de champs sélectionnés ou utiliser le streaming. Pour les mutations, envoyez moins d'opérations par requête.

Les requêtes qui ne respectent pas cette limite ne génèrent pas de GoogleAdsError, mais une erreur RESOURCE_EXHAUSTED (code gRPC 8/HTTP 429). Consultez la liste des codes et messages d'erreur gRPC.

Requêtes de modification

En plus d'être comptabilisée dans le quota d'opérations quotidiennes de l'utilisateur, une requête de modification ne peut pas contenir plus de 10 000 opérations de modification par requête. Les requêtes qui ne respectent pas cette limite sont rejetées avec l'erreur TOO_MANY_MUTATE_OPERATIONS.

Les limites et considérations supplémentaires pour des services et des types de requêtes spécifiques sont décrites ci-après.

Rechercher des requêtes

Une requête Search ou SearchStream est comptabilisée comme une opération dans le quota d'opérations quotidien de l'utilisateur. Une requête SearchStream est comptabilisée comme une opération d'API, quel que soit le nombre de lots.

Requêtes paginées

Les requêtes paginées (par exemple, les requêtes contenant un next_page_token valide) ne sont pas comptabilisées dans le quota d'opérations quotidiennes d'un utilisateur. Toutefois, les requêtes de pagination contenant un jeton de page expiré ou non valide génèrent une exception et sont comptabilisées dans le quota d'opérations quotidien.

Pour en savoir plus sur la pagination, consultez Parcourir les résultats.

Autres types de demandes

Une requête qui n'est pas une requête Mutate, Search ou SearchStream est comptabilisée comme une opération par rapport au quota d'opérations quotidien de l'utilisateur.

Voici quelques exemples de requêtes de ce type :

Requêtes qui renvoient des exceptions d'API

Les requêtes rejetées avec un code GoogleAdsFailure sont toujours comptabilisées dans le quota d'opérations quotidiennes de l'utilisateur.

Les requêtes qui échouent, mais ne renvoient pas de GoogleAdsFailure (par exemple, en raison d'une erreur au niveau du réseau), ne sont pas comptabilisées dans le quota d'opérations quotidien de l'utilisateur, car elles n'atteignent jamais le service. C'est le cas, par exemple, d'un échec de connectivité réseau.

Service de planification des mots clés

En raison de leur coût et de leur complexité, les méthodes de service de planification des mots clés suivantes sont soumises à des limites distinctes des autres types de requêtes.

Gardez ces limites à l'esprit lorsque vous créez un plan de mots clés.

Objet "Plan de mots clés" Nombre maximal
KeywordPlan par compte 10 000
KeywordPlanAdGroup par KeywordPlan 200
KeywordPlanAdGroupKeyword par KeywordPlan 10 000
KeywordPlanCampaignKeyword (mots clés à exclure) par KeywordPlan 1 000
KeywordPlanCampaign par KeywordPlan 1

Service d'insights sur l'audience

Les méthodes suivantes de AudienceInsightsService sont soumises à des limites de quota spécifiques.

Service d'importation de conversions

Service d'importation des ajustements de conversion

Règles de valeur de conversion

Si un ConversionValueRuleSet avec un attachment_type de CUSTOMER existe déjà pour le compte, vous devez ajouter toutes les nouvelles règles de valeur de conversion à cet ensemble pour qu'elles deviennent actives. Si aucun ensemble de règles de valeur de conversion n'existe, vous devez en créer un et y ajouter vos règles de valeur de conversion, comme décrit dans Créer des ensembles de règles.

Services de facturation et de budget du compte

  • Les mutations ne peuvent être effectuées que sur les comptes configurés pour la facturation mensuelle.

    Les requêtes qui ne respectent pas cette limite sont rejetées avec l'erreur MUTATE_NOT_ALLOWED.

  • Une seule opération est autorisée pour les requêtes de modification.

    Les requêtes qui ne respectent pas cette limite sont rejetées avec l'erreur TOO_MANY_MUTATE_OPERATIONS.

  • Vous devez attendre au moins 12 heures entre les modifications du budget du compte (AccountBudget ou AccountBudgetProposal) pour un même compte. Si vous effectuez des modifications avant que 12 heures ne se soient écoulées, vous risquez de rencontrer des erreurs irrécupérables qui ne pourront être résolues que par votre responsable de compte Google Ads.

Invitations à des comptes client

Vous pouvez inviter de nouveaux utilisateurs à rejoindre des comptes client existants à l'aide de la méthode CustomerUserAccessInvitationService. Étant donné que cette fonctionnalité envoie des e-mails d'invitation à d'autres utilisateurs, elle peut être utilisée de manière abusive. Son comportement est donc limité :

  • Les utilisateurs ne peuvent pas recevoir plus d'une invitation en attente pour un même compte client. Si une requête ultérieure est effectuée pour envoyer une invitation à un utilisateur qui a déjà une invitation en attente, l'erreur suivante est renvoyée : EMAIL_ADDRESS_ALREADY_HAS_PENDING_INVITATION.

  • Les comptes client ne peuvent pas avoir plus de 70 invitations en attente à la fois. Si une requête est envoyée et que cette valeur est dépassée, l'erreur suivante est renvoyée : PENDING_INVITATIONS_LIMIT_EXCEEDED.

Données utilisateur

Les données utilisateur sont gérées avec UserDataService et OfflineUserDataJobService.

Chaque objet UserData d'une opération create ou remove concerne un seul utilisateur final. Le champ user_identifiers d'un seul objet UserData est limité à 20 identifiants maximum. Le dépassement de cette limite dans un seul objet UserData entraîne une erreur OfflineUserDataJobError.TOO_MANY_USER_IDENTIFIERS ou UserDataError.TOO_MANY_USER_IDENTIFIERS.

Gérer les utilisateurs ayant plus de 20 identifiants

Si un seul utilisateur final possède plus de 20 identifiants que vous devez importer, vous devez répartir ces identifiants sur plusieurs objets UserData. Pour vous assurer que Google peut associer tous ces identifiants au même utilisateur final, chaque objet UserData de cet utilisateur doit inclure au moins un user_identifier commun, tel que le même hashed_email, hashed_phone_number ou third_party_user_id. Google utilise ces identifiants partagés pour associer et fusionner les informations des opérations UserData distinctes avec le profil d'utilisateur final approprié.

Si vous utilisez des informations permettant d'identifier personnellement l'utilisateur (comme des adresses e-mail ou des numéros de téléphone hachés), assurez-vous qu'elles sont normalisées et hachées conformément aux exigences de l'API Google Ads (SHA-256, minuscules, sans espace) pour éviter les échecs d'association.

Par exemple, si un utilisateur possède 30 adresses e-mail, vous pouvez envoyer deux objets UserData qui partagent un third_party_user_id commun (en plaçant thirdPartyUserId et les adresses e-mail 1 à 19 dans le premier objet pour respecter la limite de 20 identifiants, et thirdPartyUserId et les adresses e-mail 20 à 30 dans le second) :

{
  "userIdentifiers": [
    { "thirdPartyUserId": "user123" },
    { "hashedEmail": "SHA256_OF_EMAIL_1" },
    // Hashed emails 2 through 18 are omitted here.
    { "hashedEmail": "SHA256_OF_EMAIL_19" }
  ]
}
{
  "userIdentifiers": [
    { "thirdPartyUserId": "user123" },
    { "hashedEmail": "SHA256_OF_EMAIL_20" },
    // Hashed emails 21 through 29 are omitted here.
    { "hashedEmail": "SHA256_OF_EMAIL_30" }
  ]
}

La limite totale pour user_identifiers sur toutes les opérations d'un même AddOfflineUserDataJobOperationsRequest est de 100 000 (un OfflineUserDataJob peut accepter plusieurs appels AddOfflineUserDataJobOperationsRequest, jusqu'à un maximum recommandé de 1 000 000 d'opérations par job). Pour les importations synchrones à l'aide de UploadUserDataRequest (UserDataService.UploadUserData), chaque requête est limitée à un maximum de 10 opérations et 100 user_identifiers sur l'ensemble de la requête.

Autres types de limites

Un champ répété, tel qu'une liste d'opérations, qui comporte trop d'éléments dans une requête peut générer l'erreur REQUEST_SIZE_LIMIT_EXCEEDED. Ce même message d'erreur peut également être dû à d'autres problèmes.

Si vous rencontrez cette limitation et que vous effectuez des requêtes qui utilisent un champ répété, essayez de réduire le nombre d'éléments dans le champ répété en répartissant la liste des opérations sur plusieurs requêtes de modification.

Lorsque vous effectuez une requête GAQL, le nombre maximal d'éléments dans une clause IN est de 20 000. Si vous dépassez cette limite, une erreur FILTER_HAS_TOO_MANY_VALUES est renvoyée.