Se aplican los siguientes límites y cuotas a la API de datos.
Cómo se aplican las cuotas
Todas las solicitudes a la API de Google Analytics Data v1 requieren un proyecto de Google Cloud y están sujetas a las cuotas que se describen en esta página. Las cuotas se consumen independientemente del método que se use para identificar el proyecto que realiza la llamada, incluidos los siguientes:
- Solicitudes autenticadas con credenciales de OAuth 2.0
- Solicitudes autenticadas con solo una clave de API
Las claves de API se usan para asociar una solicitud con un proyecto específico de Google Cloud para fines de cuota y facturación. Todas las llamadas a la API que se realicen con credenciales o una clave de API de tu proyecto se descontarán de las cuotas aplicables de tu proyecto y de la propiedad de Google Analytics.
Categorías de cuotas
La API de datos tiene cuatro categorías de cuotas de solicitud: Núcleo, Tiempo real, Embudo y Chat.
Las solicitudes a la API para los métodos de Núcleo consumen cuotas de Núcleo. Las solicitudes a la API para los métodos de Tiempo real consumen cuotas de Tiempo real. Las solicitudes a la API para los métodos de Embudo consumen cuotas de Embudo. Las solicitudes a la API para los métodos de Chat consumen cuotas de Chat. Cada solicitud consume solo un tipo de cuota.
| Categoría de cuota | Métodos de la API |
|---|---|
| Núcleo | runReport, runPivotReport, batchRunReports, batchRunPivotReports, runAccessReport, getMetadata, checkCompatibility, createAudienceExports |
| Tiempo real | runRealtimeReport |
| Embudo | runFunnelReport |
| Chat | properties.chat |
Cuotas de propiedades de Analytics
Todas las solicitudes consumen cuotas de propiedades.
| Nombre de la cuota | Límite de propiedades estándares | Límite de propiedades de Analytics 360 |
|---|---|---|
| Tokens de núcleo por propiedad por día | 200,000 | 2,000,000 |
| Tokens de núcleo por propiedad por hora | 40,000 | 400,000 |
| Tokens de núcleo por proyecto por propiedad por hora | 14,000 | 140,000 |
| Solicitudes simultáneas de núcleo por propiedad | 10 | 50 |
| Errores de servidor de núcleo por proyecto por propiedad por hora | 10 | 50 |
| Tokens de tiempo real por propiedad por día | 200,000 | 2,000,000 |
| Tokens de tiempo real por propiedad por hora | 40,000 | 400,000 |
| Tokens de tiempo real por proyecto por propiedad por hora | 14,000 | 140,000 |
| Solicitudes simultáneas de tiempo real por propiedad | 10 | 50 |
| Errores de servidor de tiempo real por proyecto por propiedad por hora | 10 | 50 |
| Tokens de embudo por propiedad por día | 200,000 | 2,000,000 |
| Tokens de embudo por propiedad por hora | 40,000 | 400,000 |
| Tokens de embudo por proyecto por propiedad por hora | 14,000 | 140,000 |
| Solicitudes simultáneas de embudo por propiedad | 10 | 50 |
| Errores de servidor de embudo por proyecto por propiedad por hora | 10 | 50 |
| Tokens de chat por propiedad por día | 3,750,000 | 3,750,000 |
| Tokens de chat por propiedad por hora | 500,000 | 500,000 |
- Las solicitudes simultáneas se miden por la cantidad de solicitudes que se ejecutan de forma simultánea. Para reducir la simultaneidad de las solicitudes, espera a que se completen las solicitudes anteriores antes de enviar solicitudes adicionales.
- Los errores de servidor son los códigos 500 y 503. Las cuotas de errores de servidor solo se cobran cuando una solicitud genera un error de servidor. Cuando se agotan las cuotas de errores de servidor para un par de proyecto y propiedad, se bloquean todas las solicitudes a la propiedad desde el proyecto. Para obtener una lista completa de las respuestas de error, consulta Error Responses.
- Cada solicitud consume cuota tanto para Tokens por propiedad por hora como para Tokens por proyecto por propiedad por hora. Esto significa que se debe acceder a una propiedad desde más de 3 proyectos antes de que se pueda agotar la cuota de "Tokens por propiedad por hora" antes que la cuota de "Tokens por proyecto por propiedad por hora".
Las propiedades permiten 120 solicitudes potencialmente umbralizadas por hora. Las dimensiones userAgeBracket, userGender, brandingInterest, audienceId y audienceName pueden estar umbralizadas. Se aplican umbrales para evitar que las personas que vean un informe infieran los datos demográficos o los intereses de usuarios individuales.
Cuota de tokens de propiedad
Los tokens se consumen con cada solicitud a la API de Google Analytics Data v1.
La cantidad de tokens que se cobran depende de la complejidad de la solicitud. Si bien la mayoría de las
solicitudes cobrarán 10 tokens o menos, las solicitudes más complejas (como las
consultas chat
de Ask Advisor) consumirán más.
Factores que influyen en el consumo de tokens
El costo exacto de tokens para una solicitud se determina en el momento de la ejecución, lo que dificulta el cálculo previo preciso. El costo se ve afectado por una combinación de factores relacionados con la solicitud en sí y los datos subyacentes de la propiedad de Google Analytics. Estos factores pueden generar costos más altos:
- Cantidad de filas: Solicitar una mayor cantidad de filas.
- Cantidad de dimensiones y métricas: Incluir una mayor cantidad de dimensiones y métricas.
- Complejidad del filtro: Emplear expresiones de filtro complejas.
- Duración del período: Realizar consultas durante períodos más largos.
- Cardinalidad de los datos: Las dimensiones con alta cardinalidad (muchos valores únicos, como
pagePath, dimensiones personalizadas) pueden aumentar significativamente el costo de los tokens. - Volumen de eventos de la propiedad: Las consultas en propiedades con un mayor volumen de eventos pueden consumir más tokens que la misma consulta en una propiedad con menos datos.
Supervisión del uso de tokens
La forma más eficaz de determinar el costo de tokens para tus llamadas a la API específicas
es incluir el parámetro
"returnPropertyQuota": true
en el cuerpo de la solicitud (compatible con
runReport,
batchRunReports,
runPivotReport,
batchRunPivotReports,
runRealtimeReport y
runFunnelReport). La
respuesta de la API incluirá el objeto
PropertyQuota, que detalla los
tokens consumidos por esa solicitud específica y los saldos de cuota restantes.
Ejemplo de solicitud con returnPropertyQuota
POST https://analyticsdata.googleapis.com/v1beta/properties/GA_PROPERTY_ID:runReport
{
"dateRanges": [
{ "startDate": "7daysAgo", "endDate": "yesterday" }
],
"dimensions": [
{ "name": "country" }
],
"metrics": [
{ "name": "activeUsers" }
],
"returnPropertyQuota": true
}
Ejemplo de carga útil de respuesta propertyQuota
Cuando "returnPropertyQuota": true se establece, la respuesta incluye un
propertyQuota objeto en el que cada campo
contiene un QuotaStatus con
consumed y remaining números enteros:
{
"dimensionHeaders": [
{ "name": "country" }
],
"metricHeaders": [
{ "name": "activeUsers", "type": "TYPE_INTEGER" }
],
"rows": [
{
"dimensionValues": [{ "value": "United States" }],
"metricValues": [{ "value": "4820" }]
}
],
"propertyQuota": {
"tokensPerDay": {
"consumed": 1,
"remaining": 199999
},
"tokensPerHour": {
"consumed": 1,
"remaining": 39999
},
"concurrentRequests": {
"consumed": 0,
"remaining": 10
},
"serverErrorsPerProjectPerHour": {
"consumed": 0,
"remaining": 10
},
"potentiallyThresholdedRequestsPerHour": {
"consumed": 0,
"remaining": 120
},
"tokensPerProjectPerHour": {
"consumed": 1,
"remaining": 13999
}
}
}
Cada campo de propertyQuota corresponde a una cuota en
las cuotas de propiedades de Analytics. El cargo de tokens de una sola solicitud a la API se deduce simultáneamente de tokensPerDay, tokensPerHour y tokensPerProjectPerHour. Si algún bucket de cuota alcanza el valor 0 restante, las solicitudes posteriores a esa propiedad muestran un error 429 RESOURCE_EXHAUSTED.
Prácticas recomendadas para evitar errores 429 RESOURCE_EXHAUSTED
- Supervisa los saldos
remainingde forma dinámica: InspeccionapropertyQuota.tokensPerProjectPerHour.remainingypropertyQuota.tokensPerHour.remainingen las respuestas, y limita o pausa los trabajos en segundo plano que no sean urgentes cuando los tokens restantes caigan por debajo de un umbral de seguridad. - Agrupa las consultas relacionadas: Usa
batchRunReportsobatchRunPivotReportspara agrupar hasta 5 informes en una sola llamada HTTP y reducir la sobrecarga de ida y vuelta de HTTP (ten en cuenta que cada informe de un lote sigue contando individualmente para las cuotas de tokens yconcurrentRequests). - Reduce la complejidad y la cardinalidad de las consultas: Limita las solicitudes solo a las dimensiones y métricas que necesitas, acorta los
dateRangescuando sea posible y evita combinar varias dimensiones de alta cardinalidad (comopagePathofullPageUrl) en consultas de sondeo frecuentes. - Controla la simultaneidad de las solicitudes: Pon en cola las solicitudes o limita el tamaño del grupo de trabajadores para que las solicitudes en curso permanezcan por debajo del límite de
concurrentRequests(10 para Estándar y 50 para Analytics 360). - Implementa una retirada exponencial con límites de reintento: Si una solicitud falla con
429 RESOURCE_EXHAUSTED,500 INTERNAL, o503 UNAVAILABLE, vuelve a intentarlo con una retirada exponencial truncada como se describe en Respuestas de error.
Consumo y supervisión de tokens de chat
Para las solicitudes chat
de Ask Advisor, los tokens representan los costos de procesamiento, razonamiento y recuperación de datos
subyacentes del modelo. El consumo de tokens de chat se ve afectado por lo siguiente:
- Alcance analítico y de consultas: Complejidad y amplitud del análisis solicitado.
- Tokens de entrada y salida del modelo: Volumen de datos contextuales procesados y narrativa de respuesta generada.
- Tokens de razonamiento: Pasos de razonamiento del modelo necesarios para sintetizar los resultados.
- Latencia de ejecución: Tiempo de procesamiento necesario para las exploraciones de datos de varios pasos.
Para supervisar el uso de tokens de chat, establece "returnPropertyQuota": true
en tu
ChatRequest. La
respuesta incluirá el
PropertyChatQuota
objeto que contiene los campos
tokensPerDay
y
tokensPerHour
con los saldos consumidos y restantes.