Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Kontingente schützen die Infrastruktur von Google vor automatisierten Prozessen, die die Google Bid Manager API auf unzulässige Weise nutzen. Sie stellen sicher, dass die Aktionen eines Entwicklers keine negativen Auswirkungen auf die gesamte Community haben.
Kontingentlimits
Die folgenden standardmäßigen Kontingentlimits werden von allen Ressourcen und Methoden der Bid Manager API gemeinsam genutzt.
In der Google API Console wird dieses Kontingent als Abfragen pro Minute pro Nutzer bezeichnet und ist auf 240 festgelegt.
Kontingentlimits überschreiten
In dem unwahrscheinlichen Fall, dass Ihre Anfrage aufgrund einer Überschreitung eines Kontingentlimits fehlschlägt, gibt die API einen HTTP-Statuscode und die Ursache für den Fehler zurück. Darüber hinaus enthält der Text der Antwort eine detaillierte Beschreibung der Fehlerursache. Im Leitfaden zu Fehlermeldungen finden Sie ein Beispiel für eine Fehlerantwort.
Die folgende Liste enthält mögliche Fehler und empfohlene Maßnahmen für Anfragefehler, die durch das Überschreiten von Kontingentlimits verursacht werden.
Code
Grund
die Botschaft und
Empfohlene Maßnahme
403
dailyLimitExceeded
Tageslimit überschritten
Wiederholen Sie den Vorgang nur, wenn das Problem behoben ist. Untersuchen Sie Ihre Nutzung über die Google API Console und ändern Sie Ihren Workflow so, dass weniger Anfragen gestellt werden. Sie können ein zusätzliches Kontingent anfordern, wenn Sie der Meinung sind, dass Ihre Nutzung angemessen ist.
403
userRateLimitExceeded
Grenzwert für Benutzerrate überschritten
Verlangsamen Sie die Geschwindigkeit, mit der Anfragen gesendet werden, mithilfe des exponentiellen Backoffs.
Was ist ein exponentieller Backoff?
Exponentielle Backoffs bilden eine Standard-Fehlerbehandlungsstrategie für Netzwerkanwendungen, bei denen der Client eine fehlgeschlagene Anfrage über einen immer länger werdenden Zeitraum periodisch wiederholt. Wenn bei sehr vielen Anfragen oder bei hohem Netzwerktraffic der Server Fehler ausgibt, kann ein exponentieller Backoff eine hilfreiche Strategie zur Fehlerbehandlung sein. Dagegen ist ein exponentieller Backoff keine gute Strategie für die Handhabung von Fehlern, die nicht aufgrund des Netzwerkvolumens oder von Antwortzeiten auftreten, z. B. Fehler wegen ungültiger Autorisierungsdaten oder nicht gefundener Dateien.
Bei richtigem Einsatz erhöht der exponentielle Backoff die Effizienz der Bandbreitennutzung, verringert die Anzahl der Anfragen, die für den Erhalt einer erfolgreichen Antwort erforderlich sind, und maximiert den Durchsatz von Anfragen in Umgebungen mit Gleichzeitigkeit.
Der Ablauf für das Implementieren eines einfachen exponentiellen Backoffs sieht so aus:
Stellen Sie eine Anfrage an die API.
Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
Warten Sie 1 Sekunde + random_number_milliseconds und wiederholen Sie die Anfrage.
Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
Warten Sie 2 Sekunden + random_number_milliseconds und wiederholen Sie die Anfrage.
Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
Warten Sie 4 Sekunden + random_number_milliseconds und wiederholen Sie die Anfrage.
Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
Warten Sie 8 Sekunden + random_number_milliseconds und wiederholen Sie die Anfrage.
Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
Warten Sie 16 Sekunden + random_number_milliseconds Millisekunden und wiederholen Sie die Anfrage.
Beenden Sie den Vorgang. Melden oder protokollieren Sie einen Fehler.
Im oben beschriebenen Ablauf steht random_number_milliseconds für eine zufällige Anzahl von Millisekunden, deren Wert größer oder gleich 1.000 ist. Dies ist erforderlich, da eine kurze zufällige Verzögerung die Last gleichmäßiger verteilt und verhindert, dass der Server blockiert wird. Der Wert von random_number_milliseconds muss nach jeder Wartezeit neu definiert werden.
Hinweis: Die Wartezeit beträgt immer (2 ^ n) + random_number_milliseconds Millisekunden, wobei n eine gleichförmig ansteigende Ganzzahl ist, die anfänglich auf 0 gesetzt ist. Die Ganzzahl n wird bei jeder Iteration bzw. Anfrage um 1 erhöht.
Der Algorithmus ist so eingerichtet, dass er endet, wenn n = 5. Diese Obergrenze verhindert, dass die Clients unendlich fortfahren, und führt zu einer Verzögerung von insgesamt 32 Sekunden, bevor eine Anfrage als "nicht zu behebender Fehler" gilt. Sie können eine größere maximale Anzahl an Wiederholungen angeben, insbesondere wenn es sich um einen langen Upload handelt. Wichtig ist nur, dass die Wiederholungsverzögerung bei einem akzeptablen Wert liegt, zum Beispiel bei unter einer Minute.
Zusätzliches Tageskontingent anfordern
Wenn Sie der Meinung sind, dass für Ihre Anwendung ein zusätzliches Tageskontingent erforderlich ist, können Sie anhand der folgenden Anleitung ein höheres Kontingent anfordern.
Die folgende Anleitung gilt nur für Projekte, bei denen der Fehler dailyLimitExceeded aufgetreten ist. Empfohlene Maßnahmen für andere Kontingentfehler finden Sie in der Tabelle oben.
Rufen Sie in der Google API Console die Bid Manager API auf.
Überprüfen Sie die Nutzungsstatistiken auf der Seite Messwerte, um sicherzustellen, dass sich Ihre Anwendung erwartungsgemäß verhält. Achten Sie genau auf die aufgerufenen Methoden und beheben Sie unerwartete oder übermäßige Verwendung, bevor Sie fortfahren.
Wenn die Nutzung normal aussieht, rufen Sie die Seite Kontingente auf. Klicken Sie auf das Bearbeitungssymbol neben Abfragen pro Tag und dann auf den Link „Höheres Kontingent beantragen“.
Lesen Sie die Informationen und folgen Sie der Anleitung im Formular zum Anfordern einer Kontingenterhöhung, bevor Sie eine Erhöhung beantragen.
[null,null,["Zuletzt aktualisiert: 2025-08-31 (UTC)."],[[["\u003cp\u003eGoogle Bid Manager API uses quotas to protect its infrastructure and ensure fair usage for all developers.\u003c/p\u003e\n"],["\u003cp\u003eDefault quota limits include 2,000 requests per project per day and 4 queries per second per project.\u003c/p\u003e\n"],["\u003cp\u003eExceeding quota limits results in specific error codes, requiring actions like reducing requests or using exponential backoff.\u003c/p\u003e\n"],["\u003cp\u003eExponential backoff is a retry strategy for handling temporary errors by gradually increasing wait times between requests.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers can request additional daily quota through the Google API Console if needed.\u003c/p\u003e\n"]]],["Google Bid Manager API uses quotas to protect its infrastructure, limiting projects to 2,000 daily requests and 4 queries per second. Exceeding these results in errors; `dailyLimitExceeded` requires usage examination and possible quota increase, while `userRateLimitExceeded` needs rate slowdown via exponential backoff. Exponential backoff retries failed requests with increasing delays (e.g., 1, 2, 4 seconds) and randomized milliseconds, terminating after a set number of attempts. Additional daily quota can be requested through the Google API Console.\n"],null,["# Quotas protect Google's infrastructure from automated processes that use the Google Bid Manager API in an inappropriate way. They ensure that one developer's actions cannot negatively impact the larger community.\n\nQuota limits\n------------\n\nThe following default quota limits are shared by all Bid Manager API resources and methods.\n\n- 2,000 requests per project per day - [can be increased](#additional_quota).\n- 4 queries per second (QPS) per project.\n - In the Google API Console this quota is referred to as **Queries per minute per user**, and is set to 240.\n\n| **Note:** Daily quotas refresh at midnight PST.\n\nExceeding quota limits\n----------------------\n\nIn the unlikely event that your request fails due to exceeding a quota limit, the API returns an HTTP status code and reason for the error. Additionally, the body of the response contains a detailed description of what caused the error. See the [Error Messages](/bid-manager/core_errors) guide for an example error response.\n\nThe following list shows the possible errors and recommended actions for request failures caused by exceeding quota limits.\n\n| Code | Reason | Message | Recommended Action |\n|------|-----------------------|--------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 403 | dailyLimitExceeded | Daily Limit Exceeded | Do not retry without fixing the problem. [Examine your usage](https://console.developers.google.com/project/_/apiui/apiview/doubleclickbidmanager/metrics) from the Google API Console and modify your workflow to make fewer requests. You can [request additional quota](#additional_quota) if you believe your usage is reasonable. |\n| 403 | userRateLimitExceeded | User Rate Limit Exceeded | Slow down the rate at which you are sending requests using [exponential backoff](#exponential_backoff). |\n\n#### What is exponential backoff?\n\nExponential backoff is a standard error handling strategy for network applications in which the client periodically retries a failed request over an increasing amount of time. If a high volume of requests or heavy network traffic causes the server to return errors, exponential backoff may be a good strategy for handling those errors. Conversely, it is not a relevant strategy for dealing with errors unrelated to network volume or response times, such as invalid authorization credentials or file not found errors.\n\nUsed properly, exponential backoff increases the efficiency of bandwidth usage, reduces the number of requests required to get a successful response, and maximizes the throughput of requests in concurrent environments.\n\nThe flow for implementing simple exponential backoff is as follows:\n\n1. Make a request to the API.\n2. Receive an `HTTP 503` response, which indicates you should retry the request.\n3. Wait 1 second + random_number_milliseconds and retry the request.\n4. Receive an `HTTP 503` response, which indicates you should retry the request.\n5. Wait 2 seconds + random_number_milliseconds, and retry the request.\n6. Receive an `HTTP 503` response, which indicates you should retry the request.\n7. Wait 4 seconds + random_number_milliseconds, and retry the request.\n8. Receive an `HTTP 503` response, which indicates you should retry the request.\n9. Wait 8 seconds + random_number_milliseconds, and retry the request.\n10. Receive an `HTTP 503` response, which indicates you should retry the request.\n11. Wait 16 seconds + random_number_milliseconds, and retry the request.\n12. Stop. Report or log an error.\n\nIn the above flow, random_number_milliseconds is a random number of milliseconds less than or equal to 1000. This is necessary, since introducing a small random delay helps distribute the load more evenly and avoid the possibility of stampeding the server. The value of random_number_milliseconds must be redefined after each wait.\n\n**Note:**The wait is always (2 \\^ n) + random_number_milliseconds, where n is a monotonically increasing integer initially defined as 0. The integer n is incremented by 1 for each iteration (each request).\n\nThe algorithm is set to terminate when n is 5. This ceiling prevents clients from retrying infinitely, and results in a total delay of around 32 seconds before a request is deemed \"an unrecoverable error.\" A larger maximum number of retries is fine, especially if a long upload is in progress; just be sure to cap the retry delay at something reasonable, say, less than one minute.\n\nRequesting additional daily quota\n---------------------------------\n\nIf you think that your application requires additional daily quota, you can request more by following the instructions below.\n\nThe following instructions only apply to projects that have encountered a `dailyLimitExceeded` error. Recommended actions for other quota errors are covered in the [table above](#exceeding_limits).\n\n1. Navigate to the [Bid Manager API](https://console.developers.google.com/project/_/apiui/apiview/doubleclickbidmanager/quotas) in the Google API Console.\n2. Review your usage statistics from the **Metrics** page to ensure your application is behaving as expected. Pay close attention to the methods that have been called and address any unexpected or excessive usage before proceeding.\n3. If usage looks normal, navigate to the **Quotas** page, click the edit icon next to **Queries per day** and click the link to \"Apply for higher quota\".\n\nMake sure to review the information and follow the instructions included in the quota request form before submitting an increase request.\n| **Note:** The email address you provide must be one that you actively monitor, as a representative may reach out to gather additional information."]]
