Cuotas de GA4 API: por qué Looker Studio se queda tan seco

Las cuotas GA4 API explican por qué muchos informes de Looker Studio, impecables a primera vista, terminan mostrando errores, gráficos vacíos o cargas eternas justo cuando alguien abre el panel para tomar una decisión. No es necesariamente un fallo del informe, ni una conspiración del conector, ni esa vieja superstición de que Google va peor los lunes. Looker Studio consulta los datos de Google Analytics 4 mediante la Google Analytics Data API, y esa API tiene límites por propiedad, por proyecto, por hora, por día, por solicitudes simultáneas y hasta por errores de servidor. Cuando el informe pide más de lo que la tubería permite, el agua deja de salir. Seco.

La idea importante es sencilla: cada gráfico puede consumir cuota, cada filtro puede lanzar una consulta nueva, cada cambio de rango de fechas puede abrir otra llave, y cada usuario viendo el mismo informe puede añadir presión si la caché no ayuda. Google mide ese consumo en tokens, una unidad interna que no equivale a una visita, ni a una fila, ni a un evento concreto, sino al coste de resolver una consulta. En una propiedad estándar, los límites Core llegan a 200.000 tokens por propiedad y día, 40.000 por propiedad y hora, 14.000 por proyecto y propiedad por hora y 10 solicitudes concurrentes por propiedad; en Analytics 360 los límites suben de forma notable, pero tampoco convierten la API en un pozo sin fondo.

El grifo de GA4 no se abrió para dashboards infinitos

GA4 nació en un ecosistema muy distinto al de Universal Analytics. Más eventos, más personalización, más datos cruzados, más informes hechos fuera de la interfaz nativa y más presión sobre herramientas de visualización. Looker Studio se convirtió en el salón bonito de esa casa: tablas de adquisición, embudos, campañas, conversiones, ingresos, páginas vistas, formularios, eventos clave, tráfico orgánico, tráfico de pago, comparativas interanuales, widgets para dirección y una portada con tarjetas de KPI que parece una cabina de avión.

El problema es que por debajo no hay magia, hay peticiones a una API. Y Google no deja que cada dashboard interrogue GA4 sin freno, porque la Data API sirve a millones de usuarios y aplicaciones. Para repartir recursos, usa un sistema de cubos de tokens: la solicitud entra, mira si queda cuota disponible, se ejecuta si puede, consume más o menos tokens según su complejidad y, si algún cubo está vacío, devuelve error. En la práctica, ese error se traduce en lo que el usuario ve como un informe roto, aunque el dato exista y aunque GA4 funcione dentro de su propia interfaz.

Aquí conviene matar una confusión frecuente: la cuota no se gasta solo por abrir Looker Studio. Se gasta por lo que el informe obliga a pedir. Un scorecard con sesiones del último día cuesta poco. Una tabla con muchas dimensiones, campañas, landing pages, eventos clave, filtros, búsquedas internas y un rango de 16 meses empieza a oler a atasco. Si además el panel está compartido con varias personas, incrustado en una intranet o usado por un equipo que pulsa filtros como quien cambia de canal con el mando, la cuota se evapora.

La metáfora del grifo funciona porque hay caudal y hay presión. Un dashboard pequeño bebe tranquilo. Uno pesado abre demasiados grifos a la vez. Y cuando varios informes tiran de la misma propiedad de GA4, compiten por la misma reserva. La cuota se aplica a la propiedad de Analytics y también al proyecto desde el que se llama a la API, de modo que no basta con culpar a una página concreta del informe; a veces el problema está repartido entre varios dashboards, conectores, automatizaciones, hojas, scripts y herramientas que nadie recuerda haber autorizado.

Tokens, concurrencia y esa palabra fea: cardinalidad

Las cuotas GA4 API se organizan en tres grandes familias: Core, Realtime y Funnel. Las consultas habituales de informes, tablas, métricas y dimensiones pasan por Core; los datos en tiempo real tienen su propio carril; los informes de embudo usan otro. Esa separación importa porque una petición no consume todas las categorías a la vez, pero sí puede chocar contra varios límites dentro de su categoría: tokens por día, tokens por hora, tokens por proyecto y propiedad, solicitudes concurrentes y errores de servidor.

La parte menos visible es la concurrencia. Looker Studio puede lanzar varias solicitudes al mismo tiempo para pintar una página. No espera a que el usuario admire un gráfico antes de cargar el siguiente. Si una página tiene demasiados componentes y todos piden datos a GA4, el panel se comporta como una mesa de restaurante donde veinte personas levantan la mano a la vez. Google permite 10 solicitudes concurrentes por propiedad en una propiedad estándar y 50 en Analytics 360. Cuando se supera ese límite, el mensaje es bastante literal: se han agotado las solicitudes simultáneas.

Luego está la cardinalidad, que suena a palabra de manual pero en analítica digital se entiende rápido: cuántos valores distintos tiene una dimensión. “País” suele ser manejable. “Ruta de página” puede ser un bosque. “URL completa con parámetros” ya es una selva húmeda con mosquitos. El coste en tokens aumenta con el número de filas, el número de dimensiones y métricas, la complejidad de los filtros, la longitud del periodo consultado, la cardinalidad de las dimensiones y el volumen de eventos de la propiedad. Por eso la misma tabla puede ser barata en una web pequeña y cara en un ecommerce con miles de URLs, campañas etiquetadas con entusiasmo de becario y parámetros UTM creciendo como hiedra.

También hay un límite para solicitudes potencialmente afectadas por umbrales cuando entran dimensiones sensibles, como edad, género, intereses o audiencias. No es el típico cuello de botella de un informe SEO, pero aparece en cuadros de mando de marketing cuando se mezclan audiencias, demografía y segmentación publicitaria. GA4 intenta impedir que un informe permita inferir información sobre usuarios individuales; esa protección, útil y razonable, añade otra capa de fricción cuando el dashboard busca granularidad extrema.

Por qué Looker Studio se seca antes que GA4

La interfaz de GA4 y Looker Studio no son la misma cosa, aunque beban del mismo lago. GA4 tiene sus propios informes, sus agregaciones, sus límites de exploración y su manera de presentar datos. Looker Studio, en cambio, funciona como una capa de visualización que pide datos mediante conectores. El conector nativo de Google Analytics permite visualizar campos disponibles en la Data API, pero los informes conectados a GA4 están sujetos a las cuotas de esa API, y además el propio conector no replica todo lo que puede hacerse en la interfaz de Analytics.

Esto explica una escena muy común: en GA4 el dato aparece, en Looker Studio el gráfico protesta. No hay contradicción. Hay dos caminos distintos para llegar a la información. El panel externo solicita datos bajo unas reglas de consumo. Si el informe combina demasiadas tarjetas, tablas, controles y fechas, la API puede cortar antes de que el lector vea nada coherente. Y la frustración aumenta porque el error no siempre dice “tu diseño es una hidra de consultas”. A veces habla de cuotas, a veces de configuración, a veces de solicitudes simultáneas, a veces de demasiadas peticiones en la última hora. Elegante no es.

Google permite ver el uso de tokens en Looker Studio desde el propio informe: en edición, el menú de uso de tokens de Google Analytics muestra consumo general, consumo por página y consumo por componente. Ese detalle es oro porque cambia la conversación. Ya no se trata de borrar gráficos al azar, sino de detectar qué tabla está haciendo de agujero negro. Una tabla de landing pages con consulta anual, buscador, filtros por canal y ordenaciones puede consumir bastante más que cinco tarjetas sencillas con métricas agregadas.

Hay otro matiz: la caché. Looker Studio puede servir consultas desde memoria cuando ya ha visto esa consulta y el umbral de actualización de datos sigue vigente. Eso acelera informes y reduce golpes contra cuotas. Pero la caché no es una garantía permanente. Si cambia el filtro, el rango de fechas, la combinación de campos o la credencial del usuario, puede lanzarse una consulta nueva contra la fuente. Con credenciales del propietario, varios usuarios tienden a compartir mejor ese comportamiento; con credenciales del visor, cada persona puede generar su propio circuito de consultas.

Los informes que más castigan la cuota

Los paneles que antes se rompen suelen compartir un patrón: mucho detalle, muchos controles y poco criterio de consumo. No hace falta que sean malos dashboards. A veces son demasiado ambiciosos. Quieren responderlo todo en una pantalla: adquisición, engagement, conversiones, ecommerce, campañas, páginas, formularios, buscador interno, comparativa anual, país, dispositivo, fuente, medio, campaña y contenido. Queda precioso en la reunión de presentación. Luego llega el lunes, lo abren ocho personas, ajustan fechas, cruzan canales, ordenan tablas y la Data API empieza a sudar.

Las tablas largas son candidatas habituales. Una tabla con páginas, fuente, medio, campaña, eventos clave, ingresos y usuarios por día puede pedir demasiadas filas y demasiadas combinaciones. Los gráficos con dimensiones de alta cardinalidad también cargan más. Los filtros encadenados, esos controles que prometen una libertad total al usuario, multiplican consultas nuevas. Y los rangos amplios, especialmente cuando se pide más de un año, elevan el coste. Más dimensiones, más rango temporal, más cardinalidad y más volumen de eventos suelen significar más tokens.

El modo edición también tiene su pequeño veneno. Al añadir componentes o modificar campos, Looker Studio solicita datos por defecto. Quien construye un informe pesado sin pausar actualizaciones puede gastar cuota mientras diseña, prueba, cambia una métrica, mueve una tabla, vuelve atrás, añade un filtro y decide que el color azul corporativo no era tan corporativo. La opción de pausar actualizaciones existe precisamente para reducir solicitudes durante la edición; no arregla un modelo de datos mal planteado, pero evita quemar tokens mientras se monta el escaparate.

La incrustación pública o semipública también merece respeto. Un informe de GA4 en Looker Studio embebido en una web con bastante tráfico puede convertir cada visita en presión sobre la cuota, salvo que la caché amortigüe el golpe. Para un comité interno con cinco lectores, el panel puede sobrevivir. Para una pantalla consultada por comerciales, dirección, agencia, cliente, becario, freelance y medio departamento de marketing, conviene pensar en extractos, BigQuery o una arquitectura menos dependiente de la API en vivo.

Cómo leer el consumo sin hacer espiritismo

El diagnóstico serio empieza mirando dónde se consume la cuota. En Looker Studio, el visor de Google Analytics token usage permite ver el consumo del informe, por página y por componente, además de distinguir si una petición se sirvió desde memoria o desde la fuente subyacente. Esa diferencia no es cosmética: cuando aparece servida desde memoria, el panel respira; cuando cada interacción golpea GA4, el informe está viviendo al día, sin colchón.

En GA4 también se puede consultar el historial de cuotas de la Data API desde administración, siempre que el usuario tenga rol de administrador. Ese registro permite auditar qué usuarios o aplicaciones acceden a los datos, qué categoría de cuota consumen —Core, Realtime o Funnel— y cuántos tokens de propiedad se han consumido. Es una herramienta especialmente útil cuando el culpable no es un único dashboard, sino una fauna de conectores, integraciones y scripts que se han ido acumulando con los años, como cables detrás de una televisión vieja.

Para desarrollos propios, la Data API permite incluir el parámetro returnPropertyQuota: true y recibir en la respuesta un objeto con consumo y cuota restante. Esto no sirve para que un editor de marketing arregle un panel con dos clics, pero sí para que un equipo técnico construya aplicaciones más educadas: caché, colas, carga diferida, avisos antes de consultas caras y menos entusiasmo lanzando peticiones simultáneas. La recomendación de fondo es elemental: enviar menos solicitudes y hacerlas menos complejas. No es poesía, pero funciona.

Lo que no conviene hacer es intentar “repartir” artificialmente llamadas entre varios proyectos para esquivar cuotas. Google desaconseja fragmentar tokens entre múltiples proyectos de API, y lo enmarca como una práctica contraria a sus términos. Dicho en castellano de oficina: no conviertas un problema de diseño en un problema de cumplimiento. Si el informe necesita más músculo, se rediseña el consumo, se usa caché, se extraen datos, se pasa a BigQuery o se evalúa Analytics 360. Hacer trampas con proyectos no es una estrategia; es una factura con retraso.

Extractos, BigQuery y caché: cuando el panel deja de ser ligero

Looker Studio ofrece una salida intermedia con los datos extraídos. En lugar de consultar siempre en vivo, se crea una fuente extraída con un subconjunto de campos, filtros y rango temporal. Eso puede hacer que los informes carguen más rápido y respondan mejor al aplicar filtros y fechas, porque el panel trabaja sobre una copia preparada, no siempre contra la conexión viva. Para informes ejecutivos, reportes semanales o cuadros de control donde no hace falta el dato al minuto, esta vía suele ser más sensata que seguir golpeando GA4 como si fuese una máquina de café.

La frescura de datos también se puede ajustar. En fuentes de Google Analytics, Looker Studio contempla ventanas de actualización de una, cuatro o doce horas, con doce horas como valor por defecto marcado en la documentación. Cuanto más agresiva sea la actualización, más probable es que el informe consulte la fuente; cuanto más razonable sea la frescura de datos, más margen hay para que la memoria reduzca coste y latencia. La pregunta real no es si el panel puede refrescar más, sino si el negocio necesita que refresque tanto. Muchas decisiones de SEO, contenidos o ecommerce no cambian por mirar cada diez minutos una cifra que todavía está asentándose.

BigQuery es el siguiente escalón. GA4 permite exportar eventos brutos a BigQuery, donde los datos pasan a estar bajo control del proyecto de Google Cloud y pueden consultarse con SQL, combinarse con otras fuentes y prepararse para visualización. En propiedades estándar, la exportación diaria tiene un límite de un millón de eventos al día, mientras que Analytics 360 eleva ese techo de forma drástica; la exportación en streaming está disponible para propiedades estándar y 360, ofrece datos en minutos, no tiene límite de volumen operativo comparable al de una consulta corriente, pero implica costes adicionales y no conviene tratarla como una copia perfecta para todos los usos de atribución.

Para seoetico.com y cualquier medio, ecommerce o agencia que viva de informes recurrentes, la enseñanza es bastante terrenal: Looker Studio no debería ser el almacén, sino el escaparate. Si el escaparate tiene que calcularlo todo al abrir la puerta, tarde o temprano se rompe la bisagra. Lo razonable es preparar capas de datos: GA4 para captura y análisis operativo, BigQuery para histórico y mezcla seria, tablas agregadas para dashboards, Looker Studio para lectura. Menos romanticismo del panel universal y más fontanería de datos, que es donde se gana la paz.

También hay una frontera económica. Analytics 360 aumenta cuotas, pero no está pensado para arreglar dashboards mal diseñados en proyectos pequeños. BigQuery añade poder, aunque introduce costes, gobierno de datos y necesidad técnica. Los extractos son más simples, pero no sirven para todas las preguntas. La caché ayuda, pero no salva una página con treinta gráficos histéricos. La solución buena rara vez es una sola palanca. Suele ser una mezcla de limpieza, arquitectura y algo de disciplina. Sí, esa palabra tan poco sexy.

El dato no falla: falla la forma de pedirlo

Las cuotas GA4 API han convertido Looker Studio en una herramienta menos inocente. Antes muchos equipos construían paneles como quien llena una pared de pósits: otro gráfico, otra tabla, otro filtro, otra comparación, por si acaso. Con GA4, ese “por si acaso” tiene coste. No siempre económico, pero sí operativo. Cada componente pide algo. Cada consulta pesa. Cada usuario suma. El informe que no distingue entre lo útil y lo ornamental termina pareciéndose a una feria: luces por todas partes y el generador al límite.

El enfoque maduro no consiste en renunciar a Looker Studio, sino en usarlo con cabeza. Menos páginas cargadas de ruido, más métricas agregadas, menos dimensiones de alta cardinalidad cuando no aportan decisión, rangos temporales razonables, credenciales bien planteadas, caché aprovechada, extractos cuando el dato no necesita latido en directo y BigQuery cuando el proyecto ya juega en otra liga. La Data API no está castigando la analítica; está recordando que medir también consume recursos.

Lo seco de Looker Studio, al final, no es sequía informativa. Es exceso de sed. GA4 tiene datos, la API tiene normas y el dashboard debe aprender a pedir con educación. En un ecosistema donde cada clic quiere su gráfico y cada gráfico quiere su filtro, la verdadera sofisticación no está en llenar la pantalla, sino en hacer que el dato llegue entero, rápido y sin romper la tubería.