API-Limits und -Kontingente

Die Google Ads API erzwingt Limits für API-Vorgänge, z. B. für die Anzahl der Vorgänge, die in einer einzelnen Änderungsanfrage gesendet werden können. In der folgenden Tabelle sind einige der wichtigsten Limits und Kontingente zusammengefasst.

Tägliche Limits für API-Vorgänge

Die täglichen Limits für die API-Nutzung basieren auf der Anzahl der API-Vorgänge, die pro Entwicklertoken ausgeführt werden. API-Vorgänge sind die Gesamtsumme der Abrufanfragen und Änderungsvorgänge. Die Limits für tägliche API-Vorgänge hängen von der Zugriffsebene des Entwicklertokens ab. Im Leitfaden Zugriffsebenen und zulässige Nutzung finden Sie die spezifischen Limits für API-Vorgänge für jede Zugriffsebene.

Anfragen, die diese Limits verletzen, werden mit dem Fehler: RESOURCE_EXHAUSTED abgelehnt.

gRPC-Einschränkungen

Alle Google Ads API-Clientbibliotheken verwenden gRPC zum Generieren von Anfragen und Antworten. Standardmäßig hat gRPC eine Nachrichtengröße von 4 MB. Unsere Clientbibliotheken legen die maximale Nachrichtengröße jedoch auf 64 MB fest, um die Effizienz zu steigern.

Antworten dürfen dieses Limit nicht überschreiten. Eine Suchanfrage mit vielen Feldern kann beispielsweise eine Antwort mit einer Größe von mehr als 64 MB generieren. Um dieses Limit zu vermeiden, können Sie die Anzahl der ausgewählten Felder reduzieren oder Streamingverwenden. Senden Sie für Änderungen weniger Vorgänge pro Anfrage.

Anfragen, die dieses Limit verletzen, generieren keinen GoogleAdsError, sondern einen 429 Resource Exhausted gRPC Fehler. Eine Liste der gRPC-Fehlercodes und ‑Meldungen finden Sie hier.

Änderungsanfragen

Eine Änderungsanfrage wird nicht nur auf das tägliche Kontingent für Vorgänge des Nutzers angerechnet, sondern darf auch nicht mehr als 10.000 Vorgänge pro Anfrage enthalten.

Anfragen, die dieses Limit verletzen, werden mit dem Fehler: TOO_MANY_MUTATE_OPERATIONS abgelehnt.

Im Folgenden werden zusätzliche Limits und Überlegungen für bestimmte Dienste und Anfragetypen beschrieben.

Suchanfragen

Eine Search oder SearchStream Anfrage wird auf das tägliche Kontingent für Vorgänge des Nutzers als ein Vorgang angerechnet. Eine SearchStream-Anfrage wird unabhängig von der Anzahl der Batches als ein API-Vorgang angerechnet.

Paginierte Anfragen

Paginierte Anfragen (z. B. Anfragen mit einem gültigen next_page_token) werden nicht auf das tägliche Kontingent für Vorgänge des Nutzers angerechnet. Bei paginierten Anfragen mit einem abgelaufenen oder ungültigen Seitentoken wird jedoch eine Ausnahme generiert und sie werden auf das tägliche Kontingent für Vorgänge angerechnet.

Weitere Informationen zur Paginierung finden Sie unter In Ergebnissen suchen.

Andere Anfragetypen

Eine Anfrage, die keine Get-, Mutate-, Search- oder SearchStream-Anfrage ist wird auf das tägliche Kontingent für Vorgänge des Nutzers als ein Vorgang angerechnet.

Einige Beispiele für solche Anfragen:

• BatchJobService.ListMutateJobResults
• ConversionUploadService.UploadCallConversions
• ConversionUploadService.UploadClickConversions
• OfflineUserDataJobService.AddOfflineUserDataJobOperations
• OfflineUserDataJobService.CreateOfflineUserDataJob
• UserDataService.UploadUserData

Anfragen, die API-Ausnahmen zurückgeben

Anfragen, die mit einem GoogleAdsFailure abgelehnt werden, werden weiterhin auf das tägliche Kontingent für Vorgänge des Nutzers angerechnet.

Anfragen, die fehlschlagen, aber keinen GoogleAdsFailure zurückgeben, z. B. aufgrund eines Fehlers auf Netzwerkebene, werden nicht auf das tägliche Kontingent für Vorgänge des Nutzers angerechnet, da die Anfragen den Dienst nie erreichen. Ein Beispiel dafür ist ein Fehler bei der Netzwerkverbindung.

Keyword-Planung

Aufgrund der Kosten und Komplexität unterliegen die folgenden Methoden des Keyword-Planungsdienstes anderen Limits als andere Anfragetypen.

• Begrenzt auf 1 Anfrage pro Sekunde und Kundennummer:

  • KeywordPlanIdeaService.GenerateKeywordIdeas
  • KeywordPlanIdeaService.GenerateKeywordHistoricalMetrics
  • KeywordPlanIdeaService.GenerateKeywordForecastMetrics

  Anfragen, die diese Limits verletzen, werden mit dem Fehler: RESOURCE_EXHAUSTED abgelehnt.

• 1 QPS wird als 60 Anfragen pro 60 Sekunden berechnet.

• Begrenzt auf 2 Anfragen pro Sekunde und Kundennummer:

  • KeywordPlanIdeaService.GenerateAdGroupTheme

Beachten Sie diese Limits, wenn Sie einen Keyword-Plan erstellen.

Zielgruppeninformationen

Für die folgenden Methoden in AudienceInsightsService gelten bestimmte Kontingentlimits.

• Begrenzt auf ungefähr 200 Anfragen pro Tag und Kundennummer:
  • AudienceInsightsService.GenerateAudienceCompositionInsights
  • AudienceInsightsService.GenerateSuggestedTargetingInsights
• Begrenzt auf 2 Anfragen pro Sekunde und Entwicklertoken:
  • AudienceInsightsService.GenerateTargetingSuggestionMetrics

Conversion Upload Service

• Begrenzt auf 2.000 Anruf- oder Klick-Conversions pro Anfrage:

  • ConversionUploadService.UploadCallConversions
  • ConversionUploadService.UploadClickConversions

  Anfragen, die diese Limits verletzen, werden mit dem Fehler: TOO_MANY_CONVERSIONS_IN_REQUEST abgelehnt.

Conversion Adjustment Upload Service

• Begrenzt auf 2.000 Conversion-Anpassungen pro Anfrage:

  • ConversionAdjustmentUploadService.UploadConversionAdjustments

  Anfragen, die diese Limits verletzen, werden mit dem Fehler abgelehnt: TOO_MANY_ADJUSTMENTS_IN_REQUEST.

Conversion-Wert-Regeln

• Begrenzt auf 100.000 Conversion-Wert-Regeln pro Konto.

  Anfragen, die dieses Limit verletzen, werden mit dem Fehler ResourceCountLimitExceededError.ACCOUNT_LIMIT abgelehnt.

Wenn für das Konto bereits ein ConversionValueRuleSet mit einem attachment_type von CUSTOMER vorhanden ist, müssen Sie diesem Satz alle neuen Conversion-Wert-Regeln hinzufügen, damit sie aktiv werden. Wenn kein solcher Conversion-Wert-Regelsatz vorhanden ist, müssen Sie einen erstellen und Ihre Conversion-Wert-Regeln hinzufügen, wie unter Regelsätze erstellenbeschrieben.

Billing and Account Budget Services

• Änderungen können nur an Konten vorgenommen werden, die für die monatliche Rechnungsstellung konfiguriert sind.

  Anfragen, die dieses Limit verletzen, werden mit dem Fehler: MUTATE_NOT_ALLOWED abgelehnt.

• Für Änderungsanfragen ist nur 1 Vorgang zulässig.

  Anfragen, die dieses Limit verletzen, werden mit dem Fehler: TOO_MANY_MUTATE_OPERATIONS abgelehnt.

• Zwischen Änderungen an Budgetbestellungen für dasselbe Konto sollten mindestens 12 Stunden liegen. Wenn Sie Änderungen vornehmen, bevor 12 Stunden vergangen sind, kann dies zu nicht wiederherstellbaren Fehlern führen, die nur von Ihrem Google Ads-Kundenbetreuer behoben werden können.

Einladungen zu Kundenkonten

Mit dem CustomerUserAccessService können neue Nutzer zu bestehenden Kundenkonten eingeladen werden. Da mit dieser Funktion Einladungs-E-Mails an andere Nutzer gesendet werden, besteht die Gefahr des Missbrauchs. Daher gelten folgende Einschränkungen:

• Nutzer können nicht mehr als eine ausstehende Einladung für dasselbe Kundenkonto erhalten. Wenn eine nachfolgende Anfrage gesendet wird, um eine Einladung an einen Nutzer zu senden, der bereits eine ausstehende Einladung hat, wird dieser Fehler zurückgegeben: ACCESS_INVITATION_ERROR_EMAIL_ADDRESS_ALREADY_HAS_PENDING_INVITATION.

• Für Kundenkonten können nicht mehr als 70 Einladungen gleichzeitig ausstehen. Wenn eine Anfrage gesendet wird, die dazu führt, dass dieser Wert überschritten wird, wird dieser Fehler zurückgegeben: zurückgegeben: ACCESS_INVITATION_ERROR_PENDING_INVITATIONS_LIMIT_EXCEEDED.

Nutzerdaten

Nutzerdaten werden mit dem UserDataService und dem OfflineUserDataJobService verwaltet.

Jedes UserData-Objekt in einem create oder remove-Vorgang bezieht sich auf einen einzelnen Endnutzer. Das user_identifiers Feld in einem einzelnen UserData Objekt ist auf maximal 20 IDs begrenzt. Wenn dieses Limit in einem einzelnen UserData Objekt überschritten wird, wird der Fehler OfflineUserDataJobError.TOO_MANY_USER_IDENTIFIERS oder UserDataError.TOO_MANY_USER_IDENTIFIERS zurückgegeben.

Umgang mit Nutzern mit mehr als 20 IDs

Wenn ein einzelner Endnutzer mehr als 20 IDs hat, die Sie hochladen müssen, sollten Sie diese IDs auf mehrere UserData-Objekte verteilen. Damit Google alle diese IDs demselben Endnutzer zuordnen kann, muss jedes UserData-Objekt für diesen Nutzer mindestens eine gemeinsame user_identifier enthalten, z. B. dieselbe hashed_email, hashed_phone_number oder third_party_user_id. Google verwendet diese gemeinsamen IDs, um die Informationen aus den separaten UserData-Vorgängen mit dem richtigen Endnutzerprofil zu verknüpfen und zusammenzuführen.

Wenn Sie auf personenbezogene Daten wie gehashte E-Mail-Adressen oder Telefonnummern angewiesen sind, müssen diese gemäß den Anforderungen der Google Ads API normalisiert und gehasht werden (SHA-256, Kleinbuchstaben, keine Leerzeichen), um Verknüpfungsfehler zu vermeiden.

Wenn ein Nutzer beispielsweise 30 E-Mail-Adressen hat, können Sie zwei UserData-Objekte senden.

• UserData 1: {third_party_user_id: "user123", hashed_email: "email1@...", ... hashed_email: "email19@..."}
• UserData 2: {third_party_user_id: "user123", hashed_email: "email20@...", ... hashed_email: "email30@..."}

Das Gesamlimit für user_identifiers für alle Vorgänge in einem einzelnen OfflineUserDataJob bleibt 100.000.

Andere Arten von Limits

Ein wiederholtes Feld, z. B. eine Liste von Vorgängen, das zu viele Elemente in einer Anfrage enthält, kann den Fehler REQUEST_SIZE_LIMIT_EXCEEDED verursachen. Diese Fehlermeldung kann auch auf andere Probleme zurückzuführen sein.

Wenn Sie auf dieses Limit stoßen und Anfragen mit einem wiederholten Feld senden, versuchen Sie, die Anzahl der Elemente im wiederholten Feld zu reduzieren, indem Sie eine Liste von Vorgängen in einer Änderungsanfrage verwenden.

Bei einer GAQL-Abfrage beträgt die maximale Anzahl von Elementen in einer IN -Klausel 20.000. Wenn Sie dieses Limit überschreiten, wird der FILTER_HAS_TOO_MANY_VALUES Fehler zurückgegeben.