Cuotas

Las cuotas protegen la infraestructura de Google de los procesos automatizados que utilizan la API de Google Bid Manager de forma inapropiada. Garantizan que las acciones de un desarrollador no puedan afectar negativamente a la comunidad en general.

Límites de cuota

Todos los recursos y métodos de la API de Bid Manager comparten los siguientes límites predeterminados de cuota.

• 2,000 solicitudes diarias por proyecto; se pueden aumentar.
• 4 consultas por segundo (QPS) por proyecto
  • En la Consola de API de Google, esta cuota se conoce como Consultas por minuto por usuario y se establece en 240.

Nota: Las cuotas diarias se actualizan a la medianoche (PST).

Se superaron los límites de cuota

En el caso improbable de que la solicitud falle debido a que se superó un límite de cuota, la API mostrará un código de estado HTTP y el motivo del error. Además, el cuerpo de la respuesta contiene una descripción detallada de lo que causó el error. Consulta la guía de Mensajes de error para ver una respuesta de error de ejemplo.

En la siguiente lista, se muestran los posibles errores y las acciones recomendadas para las fallas en las solicitudes a causa de exceder los límites de cuota.

Código	Motivo	Mensaje	Acción recomendada
403	dailyLimitExceeded	Se superó el límite diario	No vuelvas a intentar la operación sin solucionar el problema. Examina tu uso en la Consola de API de Google y modifica tu flujo de trabajo para realizar menos solicitudes. Puedes solicitar una cuota adicional si consideras que el uso es razonable.
403	userRateLimitExceeded	Se superó el límite de frecuencia de usuarios	Reduce la velocidad a la que envías las solicitudes con la retirada exponencial.

¿Qué es la retirada exponencial?

La retirada exponencial es una estrategia estándar de manejo de errores para aplicaciones de red en la que el cliente reintenta de forma periódica una solicitud con errores durante un período creciente. Si el servidor presenta errores debido a un gran volumen de solicitudes o tráfico de red, la retirada exponencial puede ser una buena estrategia para manejar estos errores. Por el contrario, esta estrategia no se recomienda para lidiar con errores que no estén relacionados con el volumen de la red o los tiempos de respuesta, como credenciales de autorización no válidas o errores de archivos no encontrados.

Si se la utiliza de forma correcta, la retirada exponencial aumenta la eficiencia del uso del ancho de banda, reduce la cantidad de solicitudes que se requieren para obtener una respuesta correcta y maximiza la capacidad de procesamiento de las solicitudes en entornos simultáneos.

A continuación, se muestra el flujo para implementar una retirada exponencial simple:

1. Realizar una solicitud a la API
2. Recibir una respuesta HTTP 503, que indica que debes reintentar la solicitud
3. Esperar 1 segundo + random_number_milliseconds y reintentar la solicitud
4. Recibir una respuesta HTTP 503, que indica que debes reintentar la solicitud
5. Esperar 2 segundos + random_number_milliseconds y reintentar la solicitud
6. Recibir una respuesta HTTP 503, que indica que debes reintentar la solicitud
7. Esperar 4 segundos + random_number_milliseconds y reintentar la solicitud
8. Recibir una respuesta HTTP 503, que indica que debes reintentar la solicitud
9. Esperar 8 segundos + random_number_milliseconds y reintentar la solicitud
10. Recibir una respuesta HTTP 503, que indica que debes reintentar la solicitud
11. Esperar 16 segundos + random_number_milliseconds y reintentar la solicitud
12. Detenerse. Informar o registrar un error

En el flujo anterior, random_number_milliseconds es una cantidad aleatoria de milisegundos menor o igual que 1,000. Esta es necesaria, ya que agregar un pequeño retraso aleatorio ayuda a distribuir la carga de manera más uniforme y a evitar la posibilidad de marcar el servidor. El valor de random_number_milliseconds se debe volver a definir tras cada espera.

Nota: La espera siempre es (2 ^ n) + random_number_milliseconds, en la que n es un número entero, que crece de forma monotónica, definido en un inicio como 0. El número entero n aumenta de a 1 por cada iteración (cada solicitud).

El algoritmo está configurado para terminar cuando n sea 5. Este límite impide que los clientes reintenten las solicitudes de forma infinita y genera una demora total de alrededor de 32 segundos antes de que una solicitud se considere “un error irrecuperable”. Un límite de reintentos mayor es aceptable, sobre todo si hay una carga larga en progreso. Solo asegúrate de limitar la demora de reintentos a un valor razonable, por ejemplo, menos de un minuto.

Solicita una cuota diaria adicional

Si crees que tu aplicación requiere una cuota diaria adicional, puedes seguir las instrucciones que se indican a continuación para solicitar más.

Las siguientes instrucciones solo se aplican a los proyectos que encontraron un error dailyLimitExceeded. Las acciones recomendadas para otros errores de cuota se abordan en la tabla anterior.

1. Navega a la API de Bid Manager en la Consola de API de Google.
2. Revisa las estadísticas de uso en la página Métricas para asegurarte de que tu aplicación tenga el comportamiento esperado. Presta mucha atención a los métodos a los que se llamó y aborda cualquier uso inesperado o excesivo antes de continuar.
3. Si el uso parece normal, ve a la página Cuotas, haz clic en el ícono de edición junto a Consultas por día y en el vínculo "Solicitar una cuota mayor".

Asegúrate de revisar la información y seguir las instrucciones incluidas en el formulario de solicitud de cuota antes de enviar una solicitud de aumento.

Nota: La dirección de correo electrónico que proporciones debe ser una que supervises activamente, ya que un representante podría comunicarse para recopilar información adicional.