Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Le quote proteggono l'infrastruttura di Google dai processi automatizzati che utilizzano l'API Google Bid Manager in modo inappropriato. Assicurano che le azioni di uno sviluppatore non possano avere un impatto negativo sulla community più ampia.
Limiti di quota
I seguenti limiti di quota predefiniti sono condivisi da tutti i metodi e le risorse dell'API Bid Manager.
Nella Console API di Google questa quota è denominata Query al minuto per utente ed è impostata su 240.
Superamento dei limiti di quota
Nell'improbabile caso che la tua richiesta non vada a buon fine a causa del superamento di un limite di quota, l'API restituisce un codice di stato HTTP e il motivo dell'errore. Inoltre, il corpo della risposta contiene una descrizione dettagliata di ciò che ha causato l'errore. Per un esempio di risposta, consulta la guida sui messaggi di errore.
Il seguente elenco mostra i possibili errori e le azioni consigliate per gli errori delle richieste causati dal superamento dei limiti di quota.
Codice
Motivo
Messaggio
Azione consigliata
403
dailyLimitExceeded
Limite giornaliero superato
Non riprovare senza risolvere il problema. Esamina il tuo utilizzo dalla console API di Google e modifica il flusso di lavoro per effettuare meno richieste. Puoi richiedere una quota aggiuntiva se ritieni che il tuo utilizzo sia ragionevole.
403
userRateLimitExceeded
Limite di frequenza utenti superato
Riduci la frequenza con cui invii le richieste utilizzando il backoff esponenziale.
Che cos'è il backoff esponenziale?
Il backoff esponenziale è una strategia di gestione degli errori standard per le applicazioni di rete in cui il client riprova periodicamente a effettuare una richiesta non riuscita per un periodo di tempo crescente. Se un volume elevato di richieste o un traffico di rete intenso fa sì che il server restituisca errori, il backoff esponenziale può essere una buona strategia per la gestione di questi errori. Al contrario, non si tratta di una strategia pertinente per la gestione di errori non correlati al volume di rete o ai tempi di risposta, come credenziali di autorizzazione non valide o errori di file non trovato.
Se usato correttamente, il backoff esponenziale aumenta l'efficienza dell'utilizzo della larghezza di banda, riduce il numero di richieste necessarie per ottenere una risposta corretta e massimizza la velocità effettiva delle richieste in ambienti contemporanei.
Il flusso per l'implementazione di un backoff esponenziale semplice è il seguente:
Effettua una richiesta all'API.
Ricevi una risposta HTTP 503, che indica che devi ritentare la richiesta.
Attendi 1 secondo + numero_casuale_di_millisecondi e riprova.
Ricevi una risposta HTTP 503, che indica che devi ritentare la richiesta.
Attendi 2 secondi + numero_casuale_di_millisecondi e riprova.
Ricevi una risposta HTTP 503, che indica che devi ritentare la richiesta.
Attendi 4 secondi + numero_casuale_di_millisecondi e riprova.
Ricevi una risposta HTTP 503, che indica che devi ritentare la richiesta.
Attendi 8 secondi + numero_casuale_di_millisecondi e riprova.
Ricevi una risposta HTTP 503, che indica che devi ritentare la richiesta.
Attendi 16 secondi + numero_casuale_di_millisecondi e riprova.
Interrompi. Segnala o registra un errore.
Nel flusso precedente, numero_casuale_millisecondi è un numero casuale di millisecondi inferiore o uguale a 1000. Questa operazione è necessaria, poiché l'introduzione di un piccolo ritardo casuale consente di distribuire il carico in modo più uniforme ed evitare la possibilità di stampare in eccesso il server. Il valore di numero_casuale_millisecondi deve essere ridefinito dopo ogni attesa.
Nota : l'attesa è sempre (2 ^ n) + numero_casuale_millisecondi, dove n è un numero intero con aumento monotonico inizialmente definito come 0. Il numero intero n viene incrementato di 1 per ogni iterazione (ogni richiesta).
L'algoritmo è impostato per terminare quando n è 5. Questo limite impedisce ai client di effettuare nuovi tentativi all'infinito e genera un ritardo totale di circa 32 secondi prima che una richiesta venga considerata "un errore irreversibile". Un numero massimo di nuovi tentativi è sufficiente, soprattutto se è in corso un caricamento lungo; assicurati solo di limitare il ritardo tra tentativi a un valore ragionevole, ad esempio inferiore a un minuto.
Richiesta di quota giornaliera aggiuntiva
Se ritieni che la tua applicazione richieda una quota giornaliera aggiuntiva, puoi richiederne una maggiore seguendo le istruzioni riportate di seguito.
Le istruzioni seguenti si applicano solo ai progetti che hanno riscontrato un errore dailyLimitExceeded. Le azioni consigliate per altri errori di quota sono illustrate nella tabella precedente.
Esamina le statistiche sull'utilizzo dalla pagina Metriche per verificare che l'applicazione funzioni come previsto. Prima di procedere, presta molta attenzione ai metodi chiamati e affronta eventuali utilizzi imprevisti o eccessivi.
Se l'utilizzo sembra normale, vai alla pagina Quote, fai clic sull'icona di modifica accanto a Query giornaliere e poi sul link "Richiedi una quota più alta".
Assicurati di esaminare le informazioni e di seguire le istruzioni incluse nel modulo di richiesta della quota prima di inviare una richiesta di aumento.
[null,null,["Ultimo aggiornamento 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."]]
