Lo primero, ¿por qué hacemos esto en una agencia?
En una agencia de marketing digital, los datos vienen de demasiados sitios: Google Ads, Meta, Analytics, Search Console, CRMs, Programática… Cada con su propia interfaz, su propio ritmo de actualización y su propia forma de nombrar las cosas. El problema no es que los datos no existan, el problema es que los tenemos que consultar por separado. Cuando un cliente pregunta cuánto ha invertido en total y qué ha generado, la respuesta exige abrir varias pestañas, exportar varios archivos, hacer cálculos manuales con riesgo al error y todo ello consumiendo una buena cantidad de nuestro de tiempo.
BigQuery resuelve eso. Es una base de datos de Google Cloud que permite importar datos de fuentes distintas y almacenarlos de una manera estructurada. A partir de ahí, podemos conectar Looker Studio directamente con BigQuery y mostrar esos datos en informes visuales, sin necesidad de tocar nada más.
El objetivo no es tener más datos. Es tener los datos correctos en el mismo sitio, accesibles de forma fiable, para poder responder preguntas de negocio sin depender de exportaciones manuales.
¿Qué beneficios tiene?
Visualización más limpia y flexible
Cuando conectamos Looker Studio a BigQuery, los informes dejan de depender de conectores independientes con sus propias limitaciones. Se pueden crear gráficos, tablas y métricas calculadas sobre datos que ya están limpios y estructurados en la base de datos. El resultado es un informe más preciso y más fácil de mantener.
Velocidad de carga
BigQuery está diseñado para procesar grandes volúmenes de datos con rapidez. Las consultas sobre millones de filas se ejecutan en segundos. En la práctica, esto significa que un informe en Looker Studio que antes tardaba en cargar porque tiraba de un conector directo a Google Ads, una hoja de cálculo grande o una combinación de varias fuentes, con BigQuery carga a una velocidad casi instantánea.
Fiabilidad del dato
Los conectores nativos de Looker Studio dependen de APIs que tienen cuotas, cambios de versión y caídas ocasionales. Si un conector falla, el informe muestra un error o datos en blanco. Con BigQuery, los datos ya están almacenados: aunque la fuente original tenga un problema puntual, el informe sigue funcionando con los datos que ya se importaron.
Además, al centralizar en BigQuery podemos estandarizar nombres de campañas, KPI´s, eliminar duplicados, corregir atribuciones o ajustar métricas antes de que aparezcan en pantalla.
Retención histórica de datos que las plataformas no guardan
Algunas plataformas limitan el histórico accesible. Google Ads permite consultar datos de los últimos 36 meses desde su interfaz. Meta tiene restricciones similares. Search Console solo conserva 16 meses de datos de rendimiento de búsqueda. Importar esos datos a BigQuery de forma periódica garantiza que el histórico se almacene en una base de datos, aunque la plataforma original ya no lo muestre. Eso permite hacer análisis comparativos de año contra año, o detectar tendencias a largo plazo, que de otro modo serían imposibles.
3. Cómo se hace
Paso 1: Importar los datos a BigQuery
El primer paso es llevar los datos desde las fuentes originales hasta BigQuery. Hay varias formas de hacerlo:
- Conectores nativos de Google: Google Ads, Analytics 4, Search Console y YouTube tienen integración directa con BigQuery a través de BigQuery Data Transfer Service.
- Conectores de terceros: Herramientas como Supermetrics, Fivetran, Airbyte o Windsor.ai permiten importar datos de Meta, TikTok, LinkedIn, plataformas de email y otras fuentes que no tienen integración nativa con BigQuery.
- Cargas manuales o scripts: Para fuentes muy específicas o datos propios del cliente, se pueden cargar archivos CSV o configurar scripts en Python que escriban directamente en BigQuery mediante la API de Google Cloud.
En todos los casos, el proceso consiste en definir un dataset dentro del proyecto de BigQuery (equivale a una carpeta que agrupa tablas) y dentro de ese dataset crear las tablas donde se almacenan los datos. Cada tabla tiene un esquema: una definición de qué columnas contiene y qué tipo de dato almacena cada una (fecha, número entero, texto, etc.).
Un detalle técnico relevante: BigQuery trabaja mejor con datos en formato columnar. Cuando se diseña el esquema de las tablas, conviene separar bien las dimensiones (campaña, canal, fecha, país) de las métricas (impresiones, clics, conversiones, coste). Usar tablas particionadas por fecha reduce el volumen de datos procesado en cada consulta y, por tanto, también el coste.
Paso 2: Transformar y estructurar el dato
Una vez que los datos están en BigQuery, el paso siguiente es normalizarlos. Las distintas plataformas pueden nombrar las mismas acciones del usuario de una forma diferente, lo que para Google Ads puede ser una Conversion en Meta puede ser por ejemplo una Website conversión, y llegan con nombres y estructuras distintas. En BigQuery se puede crear una tabla combinada que alamacene el gasto de Google Ads y el de Meta en una misma tabla, con las mismas columnas y los mismos nombres, lista para ser consultada desde Looker Studio.
Paso 3: Conectar BigQuery con Looker Studio
Looker Studio tiene un conector nativo para BigQuery. Al crear una fuente de datos nueva, se selecciona BigQuery, se elige el proyecto, el dataset y la tabla o vista que se quiere usar, y ya está disponible para construir el informe. Desde ese momento, cualquier gráfico o tabla del informe está consultando directamente la base de datos. Si los datos en BigQuery se actualizan (porque el Transfer Service ha traído datos nuevos de la noche anterior, por ejemplo), el informe refleja esa actualización automáticamente la próxima vez que se carga.
Lo que esto permite hacer y que Looker Studio solo no puede
Looker Studio tiene una funcionalidad llamada combinación de datos que permite cruzar fuentes distintas en un mismo gráfico. Funciona, pero tiene límites: no admite combinaciones complejas, máximo de 5 fuentes por combinación, falla con volúmenes grandes de datos y no permite aplicar lógica de negocio sofisticada.
Con BigQuery como capa central, esas combinaciones se hacen en las propias tablas antes de que el dato llegue al informe. Algunas cosas concretas que esto habilita:
- Comparar el rendimiento de campañas entre Google Ads y Meta en un mismo gráfico, con métricas calculadas de forma consistente bajo la misma definición de conversión.
- Cruzar datos de rendimiento de medios de pago con datos de ventas del CRM del cliente para calcular el ROAS real, no el que reporta cada plataforma por separado.
- Analizar periodos de más de 16 meses de Search Console o más de 36 meses de Google Ads, que las plataformas originales ya no muestran pero que están almacenados en BigQuery.
- Aplicar reglas de negocio propias: excluir campañas de marca del cómputo de coste total, reasignar conversiones según criterios acordados con el cliente o calcular métricas compuestas que ninguna plataforma ofrece de forma nativa.
Todo esto ocurre en la capa de datos, no en el informe. El informe solo muestra el resultado. Eso significa que los informes son más limpios, más rápidos de construir y más fáciles de mantener, porque la lógica está en un solo sitio y no distribuida entre múltiples fuentes configuradas directamente en Looker Studio.
El coste de mantener esta infraestructura es bajo. BigQuery tiene un modelo de precios basado en almacenamiento y consultas. Para el volumen de datos habitual de una agencia mediana, el gasto mensual raramente supera unos pocos euros si se diseña bien la estructura desde el inicio. El tiempo de configuración inicial es mayor que conectar Looker Studio directamente a cada plataforma, pero se amortiza pronto: una vez montada la infraestructura, añadir un cliente nuevo o una fuente nueva es cuestión de replicar la estructura, añadiendo o quitando KPI´s necesarios, y ajustar las consultas.
