Límites y cuotas de la API de datos

Los siguientes límites y cuotas se aplican 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 solo con una clave de API.

Las claves de API se usan para asociar una solicitud con un proyecto de Google Cloud específico con 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 cuota de solicitudes: Core, Realtime, Funnel y Chat.

Las solicitudes a la API para los métodos principales consumen cuotas principales. Las solicitudes a la API para los métodos de Realtime consumen cuotas de Realtime. Las solicitudes a la API para los métodos de embudo cobran 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 las propiedades de Analytics

Todas las solicitudes consumen cuotas de la propiedad.

Nombre de la cuota Límite de propiedades estándares Límite de propiedades de Analytics 360
Tokens principales por propiedad por día 200,000 2,000,000
Tokens principales por propiedad por hora 40,000 400,000
Tokens principales por proyecto, por propiedad y por hora 14,000 140,000
Solicitudes simultáneas principales por propiedad 10 50
Errores de servidor principales por proyecto, por propiedad y por hora 10 50
Tokens en tiempo real por propiedad por día 200,000 2,000,000
Tokens en tiempo real por propiedad por hora 40,000 400,000
Tokens en tiempo real por proyecto, por propiedad y por hora 14,000 140,000
Solicitudes simultáneas en tiempo real por propiedad 10 50
Errores de servidor de Realtime por proyecto, por propiedad y 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 y por hora 14,000 140,000
Solicitudes simultáneas de embudo por propiedad 10 50
Errores de servidor del embudo por proyecto, por propiedad y 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 según la cantidad de solicitudes que se ejecutan al mismo tiempo. Para reducir la simultaneidad de solicitudes, espera a que se completen las solicitudes anteriores antes de enviar otras 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 Respuestas de error.
  • Cada solicitud consume cuota de tokens por propiedad por hora y de 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 de la cuota de "Tokens por proyecto por propiedad por hora".

Las propiedades pueden tener 120 solicitudes potencialmente sujetas a umbrales por hora. Es posible que se apliquen umbrales a las dimensiones userAgeBracket, userGender, brandingInterest, audienceId y audienceName. Los umbrales se aplican para evitar que cualquier persona que vea un informe infiera los datos demográficos o los intereses de los 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 de Ask Advisor chat) consumirán más.

Factores que influyen en el consumo de tokens

El costo exacto de los 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 influenciado por una combinación de factores relacionados con la solicitud en sí y los datos subyacentes en la propiedad de Google Analytics. Estos factores pueden generar costos más altos:

  • Cantidad de filas: Solicita una mayor cantidad de filas.
  • Cantidad de dimensiones y métricas: Incluye una mayor cantidad de dimensiones y métricas.
  • Complejidad del filtro: Se emplean expresiones de filtro complejas.
  • Duración del período: Realiza consultas en 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 volumen de eventos más alto pueden consumir más tokens que la misma consulta en una propiedad con menos datos.

Supervisa el uso de tokens

La forma más eficaz de determinar el costo de los 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). Luego, la respuesta de la API incluirá el objeto PropertyQuota, que detalla los tokens que consumió 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 de propertyQuota

Cuando se establece "returnPropertyQuota": true, la respuesta incluye un objeto propertyQuota en el que cada campo contiene un QuotaStatus con números enteros consumed y remaining:

{
  "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 Cuotas de la propiedad de Analytics. El cargo de tokens de una sola solicitud a la API se deduce de forma simultánea de tokensPerDay, tokensPerHour y tokensPerProjectPerHour. Si algún bucket de cuota alcanza el valor 0 restante, las solicitudes posteriores a esa propiedad devuelven un error 429 RESOURCE_EXHAUSTED.

Prácticas recomendadas para evitar errores 429 RESOURCE_EXHAUSTED
  • Supervisa los saldos de remaining de forma dinámica: Inspecciona propertyQuota.tokensPerProjectPerHour.remaining y propertyQuota.tokensPerHour.remaining en las respuestas y limita o pausa los trabajos en segundo plano no urgentes cuando los tokens restantes caigan por debajo de un umbral de seguridad.
  • Consultas relacionadas con lotes: Usa batchRunReports o batchRunPivotReports para 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 se sigue contando de forma individual para las cuotas de tokens y concurrentRequests).
  • Reduce la complejidad y la cardinalidad de las consultas: Limita las solicitudes solo a las dimensiones y métricas que necesites, acorta el dateRanges cuando sea posible y evita combinar varias dimensiones de alta cardinalidad (como pagePath o fullPageUrl) 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 se mantengan por debajo del límite de concurrentRequests (10 para Standard, 50 para Analytics 360).
  • Implementa la retirada exponencial con límites de reintentos: Si una solicitud falla con 429 RESOURCE_EXHAUSTED, 500 INTERNAL o 503 UNAVAILABLE, vuelve a intentarlo con la retirada exponencial truncada, como se describe en Respuestas de error.

Consumo y supervisión de tokens de chat

Para las solicitudes de Ask Advisor chat, los tokens representan los costos de procesamiento, razonamiento y recuperación de datos subyacentes del modelo. El consumo de tokens de chat se ve influenciado por los siguientes factores:

  • Alcance analítico y de la consulta: Complejidad y amplitud del análisis solicitado.
  • Tokens de entrada y salida del modelo: Es el volumen de datos contextuales procesados y la narrativa de respuesta generada.
  • Tokens de razonamiento: Son los pasos de razonamiento del modelo necesarios para sintetizar los hallazgos.
  • Latencia de ejecución: Es el 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 objeto PropertyChatQuota que contiene los campos tokensPerDay y tokensPerHour con los saldos consumidos y restantes.