API-Limits und -Kontingente

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

Anfragetyp, Limitierung und Fehlercode
Vorgänge mit Zugriffsebene „Explorer“ 2.880 API-Vorgänge pro Tag für Produktionskonten
15.000 API-Vorgänge pro Tag für Testkonten 		RESOURCE_EXHAUSTED
Vorgänge mit Zugriffsebene „Basic“ 15.000 API-Vorgänge pro Tag für Test- und Produktionskonten RESOURCE_EXHAUSTED
Mutationsanfragen 10.000 Mutationsvorgänge pro Anfrage
100 Aktionsvorgänge pro Anfrage 		TOO_MANY_MUTATE_OPERATIONS
TOO_MANY_ACTION_OPERATIONS
Anfragen an den Planungsdienst 1 QPS RESOURCE_EXHAUSTED
Anfragen an den Conversion-Upload-Dienst 2.000 Conversions pro Anfrage TOO_MANY_CONVERSIONS_IN_REQUEST
Anfragen an den Abrechnungs- und Kontobudgetdienst 1 Vorgang pro Mutationsanfrage TOO_MANY_MUTATE_OPERATIONS

Limits für API-Vorgänge pro Tag

Die Limits für die tägliche API-Nutzung basieren auf der Anzahl der API-Vorgänge , die von Ihrem Google Cloud-Projekt ausgeführt werden. API-Vorgänge sind die Gesamtsumme der Abrufanfragen und Mutationsvorgänge. Die Limits für API-Vorgänge pro Tag hängen von der API-Zugriffsebene Ihres Google Cloud-Projekts 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 Mutationen weniger Vorgänge pro Anfrage.

Anfragen, die gegen diese Einschränkung verstoßen, generieren keinen GoogleAdsError, sondern einen 429 Resource Exhausted gRPC-Fehler. Eine Liste der gRPC-Fehlercodes und ‑meldungen finden Sie hier.

Mutationsanfragen

Mutationsanfragen werden nicht nur auf das tägliche Kontingent für Vorgänge des Nutzers angerechnet, sondern dürfen auch nicht mehr als 10.000 Vorgänge pro Anfrage enthalten.

Anfragen, die diese Einschränkung verletzen, werden mit dem Fehler abgelehnt: TOO_MANY_MUTATE_OPERATIONS.

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 angerechnet. Eine SearchStream-Anfrage wird unabhängig von der Anzahl der Batches als ein API-Vorgang gezählt.

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 angerechnet.

Einige Beispiele für solche Anfragen:

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, 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 hierfür ist ein Fehler bei der Netzwerkverbindung.

Keyword-Planungsdienst

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

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

Keyword-Plan-Objekt Maximale Anzahl
KeywordPlan pro Konto 10.000
KeywordPlanAdGroup pro KeywordPlan 200
KeywordPlanAdGroupKeyword pro KeywordPlan 10.000
KeywordPlanCampaignKeyword (auszuschließende Keywords) 1.000
KeywordPlanCampaign pro KeywordPlan 1

Zielgruppeninformationen-Dienst

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

Conversion-Upload-Dienst

Conversion-Anpassungs-Upload-Dienst

Conversion-Wert-Regeln

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 erstellen beschrieben.

Abrechnungs- und Kontobudgetdienste

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

    Anfragen, die diese Einschränkung verletzen, werden mit dem Fehler: MUTATE_NOT_ALLOWED abgelehnt.

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

    Anfragen, die diese Einschränkung verletzen, werden mit dem Fehler abgelehnt: TOO_MANY_MUTATE_OPERATIONS.

  • 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, dass sie missbraucht wird. 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 ausstehende Einladungen gleichzeitig vorhanden sein. 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 Google Ads API-Anforderungen 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 diese Einschränkung 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 Mutationsanfrage bereitstellen.

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.

Zurück
Übersicht
Weiter
Systemlimits