Cómo administrar la cuota para la API de datos de Google Analytics

Minhaz Kazi, Developer Advocate, Google Analytics – Febrero de 2023

Si desarrollas aplicaciones con la API de datos de Google Analytics, puedes deberían entender cómo funcionan las cuotas y los límites de la API. Si el aplicación está bien diseñada, es menos probable que los usuarios alcancen los límites de cuota. Algunos de y las prácticas recomendadas relevantes también generan consultas de buen rendimiento a la API. Esto puede aceleran los informes y paneles en tu aplicación y dan como resultado una experiencia una experiencia del usuario deseable. Este artículo analiza el sistema de cuotas y las para implementar la API de datos de Google Analytics.

Explicación del sistema de cuotas para la API de datos de Google Analytics

Como millones de desarrolladores y usuarios usan Google Analytics, la cuota de APIs solicitudes evitan que el sistema procese más datos de los que puede manejar y garantizar una distribución equitativa de los recursos del sistema. La API de datos para Google Las propiedades Analytics 4 usan un sistema de buckets de tokens para administrar las cuotas de la API. Para entender el concepto: imagine que hay un bucket que puede contener hasta un máximo cantidad de tokens. Cualquier solicitud a la API primero verificará el bucket. Si no hay tokens restantes, la solicitud fallará. De lo contrario, la solicitud se ejecutará consumirán uno o más tokens del bucket, según la complejidad del la solicitud. Los tokens se restablecen en el bucket con el máximo al tiempo fijo en intervalos de tiempo.

Según el método de la API de datos que uses, existen tres cuotas categorías:

• En tiempo real (durante runRealtimeReport)
• Embudo (para runFunnelReport)
• Core (para todos los demás métodos)

Y los métodos de la API de datos comprobarán que varios buckets Tokens de cuota:

1. Por propiedad por día
2. Por propiedad por hora
3. Por proyecto, por propiedad y por hora
4. Solicitudes simultáneas por propiedad
5. Errores de servidor por proyecto, por propiedad y por hora

Estos cinco buckets se verifican cada vez que entra una solicitud a la API de datos para un propiedad. Si cualquiera de los buckets está vacío, la solicitud fallará de inmediato. con un error 429. Si ninguno de los buckets está vacío, se crea token se consumirá del bucket Solicitudes simultáneas por propiedad y entonces, se ejecutará la solicitud a la API. Según la complejidad de la solicitud, se consumirá una cierta cantidad de tokens de cada uno de los tres primeros buckets una vez que se completa la ejecución. La pestaña Solicitudes simultáneas por propiedad también que el token se reabastezca en ese momento.

La cuota por proyecto, por propiedad y por hora garantiza que se agote la cuota uno o más usuarios no afectarán a otros usuarios de tu aplicación. Aquí, project se refiere al proyecto de GCP de tu aplicación. La cuota por propiedad por hora es de generalmente cuatro veces la cuota por proyecto por propiedad por hora. Para finalizar, usuarios, a una propiedad deben acceder al menos cuatro proyectos diferentes antes se puede agotar la cuota por propiedad por hora. Aplicación de la cuota en ambos a nivel del proyecto y de la propiedad garantiza que los problemas de cuota se limiten a un solo y no afectará otras propiedades a las que acceda tu aplicación.

Advertencia: No se recomienda a los desarrolladores fragmentar tokens de cuota en varios proyectos de API. Esto constituye un incumplimiento de las Condiciones del Servicio de las APIs de Google.

La cuota de Errores de servidor se refiere a las respuestas de la API con 500. 503. Si tu aplicación genera demasiados errores si accedes a una propiedad, se agotarán los errores de servidor por proyecto propiedad por hora.

Todos los tokens de cuota se restablecen con el límite en los intervalos indicados. Consulta Consulta Cuotas de la API de datos de Google Analytics para obtener información actualizada sobre las cuotas. Por ejemplo: Los métodos Core obtienen 1,250 tokens de cuota en la sección Por proyecto por propiedad por hora. bucket. Suponer que una solicitud promedio de tu aplicación consume 10 cuotas tokens, la aplicación podrá realizar 125 solicitudes principales por hora por un propiedad estándar y 10 veces esa cantidad (1,250 solicitudes principales) para cualquier instancia de Analytics propiedad de 360. El límite más alto de tokens de cuota es uno de los de las propiedades de Analytics 360.

Dado que el consumo de tokens para los tres primeros buckets depende de la complejidad de la solicitud, es difícil predecir el uso exacto del token antes de la solicitud ejecución. Lo siguiente generalmente aumentará la complejidad de una solicitud, por lo que lo que genera el uso del token:

• Cómo solicitar más dimensiones
• Consulta un intervalo de tiempo más alto
• Incluir dimensiones con mayor cardinalidad
• Consulta una propiedad con un recuento de eventos más alto

Por lo tanto, la misma consulta para dos propiedades diferentes podría generar uso de tokens completamente diferente, ya que la cardinalidad de las dimensiones podría varían o el volumen de tráfico puede ser diferente. Sin embargo, puedes esperar propiedades con niveles similares de tráfico y configuración parecidas un uso de token similar. Puedes usar esta suposición para predecir el uso del token del cliente durante las fases de planificación y diseño de la aplicación.

Nota: Si ya usaste la API de Reporting para Universal Analytics, debes notarás que la cuota aplicada de la API de Reporting en el proyecto de Aplicación/API a nivel de organización. Sin embargo, para la API de datos, la aplicación se realiza en la propiedad de Google Analytics. así como a nivel de proyecto de API.

Cómo supervisar el uso de la cuota

Para supervisar el uso de la cuota y transmitir esa información al usuario final, puedes agregar "returnPropertyQuota": true al cuerpo de la solicitud a la API. Esto mostrará el PropertyQuota junto con la respuesta de la API. El objeto PropertyQuota contendrá los importes de consumo y los estados de cuota restantes para los cinco buckets. A continuación, se muestra un ejemplo de cuerpo de solicitud y respuesta:

Solicitud

{
  "dimensions": [
    {
      "name": "medium"
    }
  ],
  "metrics": [
    {
      "name": "activeUsers"
    }
  ],
  "dateRanges": [
    {
      "startDate": "yesterday",
      "endDate": "yesterday"
    }
  ],
  "returnPropertyQuota": true
}

Respuesta

{
  "dimensionHeaders": [
    {
      "name": "medium"
    }
  ],
  "metricHeaders": [
    {
      "name": "activeUsers",
      "type": "TYPE_INTEGER"
    }
  ],
  ...
  
  "propertyQuota": {
    "tokensPerDay": {
      "consumed": 1,
      "remaining": 24997
    },
    "tokensPerHour": {
      "consumed": 1,
      "remaining": 4997
    },
    "concurrentRequests": {
      "consumed": 0,
      "remaining": 10
    },
    "serverErrorsPerProjectPerHour": {
      "consumed": 0,
      "remaining": 10
    },
    "potentiallyThresholdedRequestsPerHour": {
      "consumed": 0,
      "remaining": 120
    },
    "tokensPerProjectPerHour": {
      "consumed": 1,
      "remaining": 1247
    }
  },
  
  "kind": "analyticsData#runReport",
  ...
}

Por lo tanto, después de cada solicitud exitosa a la API de Data, puedes esperar ver la solicitud consumida y cuánta cuota queda para la propiedad. Sí también es posible mostrar esta información al usuario a través de tu aplicación interfaz de usuario.

Nota: En la etapa actual de la API de datos, debes ejecutar correctamente una Solicitud a la API para recuperar el objeto PropertyQuota. Si la propiedad ya tiene agotado un bucket de tokens de cuota, tu solicitud fallará con un error 429 y el esta respuesta no contendrá el objeto PropertyQuota. Si te afecta y piensas que tu aplicación se beneficiaría de tener una forma independiente de acceder a la información de la cuota, hacer +1 esta solicitud de función en la Herramienta de seguimiento de errores.

Administración de la cuota

Sugerimos implementar las prácticas recomendadas de administración de cuotas que se detallan a continuación para obtener aprovechar al máximo la API de datos. También actualizar tus propiedades al nivel de experiencia 360 puede aumentar la cantidad de datos a los que se accede a través de la API.

Prácticas recomendadas

En términos generales, existen dos maneras de reducir el uso de la cuota para tu aplicación:

• Envía menos solicitudes a la API
• Cómo enviar solicitudes a la API menos complejas

Con estos dos principios en mente, estas son las prácticas que puedes implementar:

• Almacenamiento en caché: La implementación de una capa de almacenamiento en caché beneficiará tanto a la usabilidad como la administración de cuotas para tu aplicación. Google Analytics almacenará en caché tus solicitudes a la API, pero las solicitudes repetidas aún generarán tokens de cuota. De almacenar en caché la respuesta de la API, puedes reducir drásticamente la cantidad de solicitudes. Por ejemplo, los datos intradía para las propiedades estándares pueden tener un valor de 4 horas o un período mayor de vencimiento de la caché. Consulta Actualidad de los datos de Google Analytics.
• Combina solicitudes: Intenta combinar varias solicitudes a la API en una sola. Por ejemplo, 5 solicitudes de datos en un período de 2 días podrían usarse 3 veces los tokens de cuota en comparación con 1 solicitud en un período de 10 días. Si tienes varias solicitudes que varían solo en una dimensión, considera combinar en una sola solicitud.
• Simplificación de las solicitudes: Limita tus solicitudes a la cantidad mínima de datos. que requieren tu aplicación y el usuario. Un gran número de filas o columnas, o los criterios de filtro complejos consumirán más tokens de cuota. Períodos más largos suelen ser más costosas (p.ej., cambian el período de 28 días a 365 puede consumir el triple de tokens de cuota). También puedes considerar usar dimensiones con menor cardinalidad siempre que sea posible (p.ej., solicita dateHour en lugar de dateHourMinute).
• Uso efectivo de limit: se cambia limit en la API. la solicitud para reducir el número de filas mostradas no afecta significativamente los tokens de cuota consumidos. Por ejemplo, 5 solicitudes con un límite de 10,000 filas consumen cinco veces los tokens de cuota en comparación con 1 solicitud con un límite de 50,000.
• Usa la categoría de método correcta: Como se mencionó antes, los límites de cuota son distribuida en tres categorías de métodos. Usar el método correcto para el público puede ahorrar cuota en otras categorías. Por ejemplo, en lugar de crear tu propio embudo en tu aplicación con datos de los métodos principales, Usa el método runFunnelReport para crear embudos.
• Actualizar la configuración predeterminada: Al crear o personalizar informes en tu es posible que los usuarios no actualicen las opciones predeterminadas que presenta tu de Compute Engine y solo las modificas en el tiempo de ejecución. Si tu aplicación tiene un elemento el período predeterminado de 365 días y el usuario suele consultar un informe de 28 días esto terminará consumiendo más cuota de lo necesario de forma habitual. Considera limitar los rangos y las selecciones en la configuración predeterminada a los usuarios a seleccionar la configuración óptima para sus casos de uso. O, en algunos casos, también puedes limitar los valores predeterminados que pueden cambiar los usuarios.
• Solicitudes en cola y carga diferida: Ten en cuenta la simultaneidad Límite de tokens de solicitudes por propiedad. Tu aplicación no debe enviar demasiadas solicitudes al mismo tiempo. Si tu aplicación tiene una gran cantidad de elementos de la IU que generan una cantidad significativa de solicitudes a la API, considera la paginación de la IU, la carga diferida y la puesta en cola de solicitudes con retirada para reintentos. Usa el método returnPropertyQuota para realizar acciones de manera agresiva supervisar el uso del token de solicitudes simultáneas por propiedad de tu aplicación

Administración de la experiencia y las expectativas del usuario

• Proporciona comentarios a los usuarios antes de que ejecuten consultas con un posible alto uso de tokens. Por ejemplo, las consultas con múltiples dimensiones de alta cardinalidad o con una un período largo podría usar una gran cantidad de tokens. Proporcionar una advertencia y un un mensaje de confirmación para esas consultas puede impedir que los usuarios realicen cambios innecesarios en los informes y los ayudan a limitar el alcance a sus para tus consultas.
• Para soluciones de informes personalizados, proporciona una forma para que los usuarios comprendan el uso de cada elemento en su informe. Por ejemplo, puedes proporcionar una vista de depuración en la que se enumera el uso del token de cuota para cada elemento del informe
• Proporcionar comentarios sobre el tipo específico de error de cuota y prescribir acción.
• Dado que las propiedades de Google Analytics 360 tienen entre 5 y 10 veces el límite de cuota en comparación en comparación con las propiedades estándares, obtiene más flexibilidad con Google Analytics 360 propiedades.

Los aumentos de cuota de API por encima de los límites predeterminados no están disponibles para la API de datos para Google Analytics 4. Google Analytics 360 proporciona cuotas más altas para los propiedades Google Analytics 4. Si tus usuarios alcanzan los límites de la cuota incluso después de implementar las prácticas recomendadas, deben considerar actualizar su propiedades a 360. Otra opción para los usuarios es usar Exportación de Google Analytics a BigQuery. Eso permitirá a los usuarios exportar datos a nivel del evento a BigQuery y ejecutar sus propios análisis.

Si tienes más preguntas sobre las cuotas de la API de datos, visita Discord de GA o haz una pregunta en Stack Overflow. Si tienes solicitudes de funciones específicas en torno a los API, puedes publicarlas en nuestra herramienta de seguimiento de errores.