BigQuery + Google Ads data pipeline 2026: construye tu data warehouse de reporting

Toda operación seria de Google Ads acaba superando la interfaz de la plataforma y las hojas de cálculo exportadas. Las preguntas de reporting que más importan — cuál es mi coste real por deal cerrado-ganado, qué campañas impulsan sesiones que convierten 60 días después, cómo se reconcilian Google, GA4 y el CRM — no pueden responderse dentro de Google Ads porque los datos viven en tres sistemas diferentes. Un warehouse de reporting de BigQuery es cómo los equipos de analítica resuelven esto en 2026, y Google ha hecho la entrada dramáticamente más fácil con el Data Transfer Service gestionado.

Este es un tutorial práctico para analistas e ingenieros. Construiremos el pipeline de extremo a extremo: aprovisionar el proyecto de Cloud, configurar el Data Transfer Service, activar la exportación de GA4, diseñar un esquema por capas, unir el ingreso del CRM por GCLID, programar el refresco diario, poner Looker Studio encima, y mantener los costes de BigQuery bajo control. Asumimos fluidez en SQL y familiaridad básica con Google Cloud. Si viene de una base centrada en el tracking, nuestra guía de configuración de GA4 e importación de conversiones es el prerrequisito correcto.

Por qué construir un pipeline de BigQuery para Google Ads

La interfaz de Google Ads es excelente para gestionar campañas y débil para el análisis cross-sistema. Tres límites estructurales empujan a los equipos hacia un warehouse.

Primero, la brecha de ingreso. Google Ads sabe lo que gastó y cuántas conversiones contó, pero no conoce su pipeline cerrado-ganado, la longitud de su ciclo de venta, ni su tasa de reembolso. Un lead que Google cuenta como un evento de conversión de 0 € podría convertirse en un deal enterprise de 40.000 € nueve meses después. Sin unir el ingreso del CRM de vuelta al clic, optimiza hacia el volumen de conversiones en lugar del beneficio — el fallo de reporting más común y más caro en el PPC B2B.

Segundo, la mezcla cross-channel. La adquisición moderna se ejecuta en Google, Meta, LinkedIn y más. Cada plataforma reporta en su propio walled garden con su propia atribución. Un warehouse es el único lugar para construir una única vista blended donde la inversión y los resultados de cada canal se sientan en la misma tabla con definiciones consistentes. Nuestra guía de atribución cross-channel cubre la metodología; BigQuery es donde la implementa.

Tercero, el techo de análisis. El testing de incrementalidad, el modelado del valor de vida del cliente, la retención por cohortes y el marketing mix modeling requieren todos datos a nivel de evento e históricos que la interfaz simplemente no expone. Un warehouse con dos a tres años de historial limpio es el sustrato sobre el que se asienta cada técnica de medición avanzada. El propio framework MMM open-source de Google, cubierto en nuestra guía de Meridian, lee directamente de BigQuery.

La economía es favorable. El Data Transfer Service es gratuito. Los primeros 10 GB de almacenamiento de BigQuery y el primer 1 TB de procesamiento de consultas cada mes son gratuitos, y más allá de eso el almacenamiento cuesta alrededor de 0,02 € por GB al mes y las consultas alrededor de 5-6 € por TB escaneado. Un warehouse de una sola cuenta bien construido rara vez supera los 150 €/mes y con frecuencia se ejecuta por debajo de 50 €. Contra el coste de la inversión publicitaria mal asignada, eso es un error de redondeo. La inversión es tiempo de ingeniería, no facturas de cloud.

La recompensa es duradera. Una vez que el pipeline existe, cada nueva pregunta se convierte en una consulta SQL en lugar de un ejercicio manual de exportar-y-pivotar. Los informes se refrescan solos. Los nuevos canales se enchufan al mismo esquema. Y la base de datos se compone: cuanto más tiempo se ejecuta el warehouse, más valioso se vuelve su historial para el modelado.

Visión general de la arquitectura y las tres fuentes de datos

La arquitectura de referencia es un warehouse por capas alimentado por tres fuentes, transformado por SQL programado, y mostrado en Looker Studio.

Las tres fuentes de datos:

La convención de datasets por capas mantiene el warehouse mantenible y eficiente en coste:

• raw_google_ads — exportaciones DTS sin tocar. Nunca consultadas directamente por los informes. Trátelo como zona de aterrizaje inmutable.
• exportación raw de GA4 — las tablas events_ que GA4 aterriza en su propio dataset, particionadas por fecha de evento.
• staging — vistas y tablas limpias y estandarizadas. Micros convertidos a moneda, columnas renombradas, duplicados de la ventana de refresco eliminados, date spine y mapeo de cuentas unidos.
• reporting — tablas curadas y desnormalizadas construidas a propósito para los dashboards. Esta es la única capa que Looker Studio toca.

Esta separación importa por tres razones: aísla los datos brutos para que un bug de transformación nunca corrompa la fuente, concentra los joins caros en construcciones programadas en lugar de por-refresco-de-dashboard, y le da una frontera limpia de permisos — los analistas obtienen acceso de lectura solo a reporting.

La orquestación es deliberadamente simple. El Data Transfer Service y la exportación de GA4 se ejecutan según la programación de Google, aterrizando datos frescos cada mañana. Unas horas después, las scheduled queries de BigQuery reconstruyen las tablas de staging y reporting. Looker Studio lee el resultado. Sin orquestador externo, sin servidores, sin contenedores. Puede graduarse a dbt y Cloud Composer después, pero no los necesita para empezar, y añadirlos prematuramente es sobreingeniería.

Una nota sobre las regiones: elija una ubicación de BigQuery (multi-región EU para residencia de datos europea) y úsela para cada dataset. Las consultas cross-región no están permitidas, así que un desajuste de ubicación entre su dataset de DTS y su dataset de CRM romperá los joins. Decida una vez, por adelantado.

Configurar el Data Transfer Service de Google Ads

El Data Transfer Service (DTS) es la base, y es genuinamente unos pocos clics de configuración más una espera por el backfill.

Prerrequisitos:

• Un proyecto de Google Cloud con facturación activada
• La BigQuery API y la BigQuery Data Transfer API activadas
• Una cuenta de Google con acceso de lectura a la cuenta de Google Ads objetivo (o MCC)
• El customer ID de la cuenta de Google Ads (10 dígitos, sin guiones)

Pasos de configuración:

1. En la consola de BigQuery, abra Data transfers y haga clic en Create transfer.
2. Elija Google Ads como fuente.
3. Nombre la transferencia, fije la programación a diaria, y elija una hora de ejecución a primera hora de la mañana.
4. Fije el dataset de destino a raw_google_ads.
5. Introduzca el Customer ID — use el ID de la MCC para extraer todas las cuentas hijas en una transferencia.
6. Configure la ventana de refresco (el número de días anteriores que DTS vuelve a extraer en cada ejecución) para capturar el backfill de conversiones y la atribución tardía.
7. Autentíquese con una cuenta que tenga el acceso necesario a Google Ads y guarde.

DTS creará un conjunto de tablas en raw_google_ads — campaña, grupo de anuncios, criterio de grupo de anuncios (keywords), conversiones, y más — cada una con sufijo de fecha o particionada, según la tabla. La nomenclatura sigue el esquema documentado de Google; mantenga esa documentación abierta como referencia porque los nombres de columna son verbosos y las tablas de stats separan las métricas de los atributos.

Ejecute un backfill de inmediato. Una transferencia nueva solo extrae hacia adelante desde hoy. Para obtener historial, dispare un backfill manual de los últimos 12 meses (o tan atrás como necesite y la cuenta soporte). Los backfills se ejecutan como una serie de jobs diarios y pueden tardar un rato para rangos largos, pero solo necesitan ejecutarse una vez.

Valide la primera carga. Tras completarse la ejecución inicial, hágale una comprobación de sensatez: sume el coste (en micros, luego divida por 1.000.000) de una semana reciente y compárelo con la interfaz de Google Ads para la misma ventana. Las pequeñas discrepancias son normales por la ventana de refresco de atribución y los límites de zona horaria, pero los totales deberían estar cerca. Si están muy desviados, compruebe que seleccionó el customer ID y la zona horaria correctos.

Consideraciones de MCC. Una transferencia de MCC etiqueta cada fila con su customer ID. Esto es potente para agencias pero multiplica el volumen de datos. Con muchas cuentas, particionar por fecha y agrupar por customer ID en su capa de staging deja de ser un lujo y se convierte en la diferencia entre una factura mensual de 40 € y una de 400 €. Planifíquelo desde la primera tabla de staging.

Diseñar el esquema de BigQuery y la capa de staging

Las tablas brutas de DTS son exactas pero incómodas: costes en micros, nombres de columna crípticos, tablas separadas de stats y atributos, y solapamiento de la ventana de refresco. La capa de staging arregla todo esto una vez para que las consultas aguas abajo se mantengan limpias.

Transformaciones centrales de staging:

-- staging.campaign_performance_daily
CREATE OR REPLACE TABLE staging.campaign_performance_daily
PARTITION BY date
CLUSTER BY customer_id, campaign_id AS
SELECT
  _DATA_DATE                         AS date,
  customer_id,
  campaign_id,
  campaign_name,
  metrics_cost_micros / 1000000      AS cost,
  metrics_impressions                AS impressions,
  metrics_clicks                     AS clicks,
  metrics_conversions                AS conversions,
  metrics_conversions_value          AS conversion_value
FROM `raw_google_ads.ads_CampaignBasicStats_*` s
JOIN `raw_google_ads.ads_Campaign_*` c USING (campaign_id)
WHERE _DATA_DATE = c._DATA_DATE;

Las especificidades de los nombres de tabla varían con la versión del esquema de DTS, pero el patrón se mantiene: convierta micros, renombre a columnas legibles, una stats con atributos, particione por fecha, agrupe por las columnas que más filtra.

Deduplicar la ventana de refresco. Como DTS vuelve a extraer los días anteriores, la misma fecha puede aparecer en múltiples cargas de snapshot. Seleccione el snapshot más reciente por fecha lógica usando una función de ventana o leyendo la partición que DTS marca como actual. Omitir este paso cuenta dos veces la inversión en sus días más recientes — un bug sutil que erosiona la confianza en el warehouse.

Tablas de soporte que necesitará:

Particionar y agrupar no es opcional. Particione cada tabla materializada de staging y reporting por date. Agrupe por customer_id y campaign_id (o lo que sea que filtren sus informes). Esta es la palanca que controla el coste: una consulta del mes pasado contra una tabla particionada por fecha escanea solo los bytes del mes pasado, no tres años de historial. La diferencia es a menudo 30x en un warehouse maduro.

Vistas versus tablas. Para transformaciones ligeras, las vistas están bien y no incurren en coste de almacenamiento — pero re-escanean los datos fuente en cada lectura. Para cualquier cosa consultada repetidamente por los dashboards, materialice una tabla particionada vía scheduled query. La regla general: transformación barata leída una vez igual a vista; transformación cara leída muchas veces igual a tabla materializada.

Mantenga la capa de staging aburrida y determinista. Debería hacer exactamente un trabajo — convertir las exportaciones brutas de DTS y GA4 en bloques de construcción limpios, bien tipados y particionados — para que la capa de reporting pueda centrarse en los joins interesantes.

Unir datos de GA4, Google Ads y CRM

Aquí es donde el warehouse se gana su sustento. Tres fuentes, unidas correctamente, responden preguntas que ninguna plataforma individual puede.

El GCLID es la columna vertebral de la atribución de ingresos. Cuando alguien hace clic en un anuncio de Google con auto-etiquetado activado, Google añade un GCLID a la URL de aterrizaje. Captúrelo en un campo oculto de formulario, persístalo a su CRM contra el lead, y se convierte en la clave de join entre los clics de Google Ads y el ingreso cerrado-ganado.

-- reporting.campaign_to_revenue
SELECT
  ga.date,
  ga.campaign_name,
  ga.cost,
  ga.conversions,
  COUNT(DISTINCT crm.deal_id)        AS deals_closed,
  SUM(crm.closed_won_amount)         AS crm_revenue,
  SAFE_DIVIDE(ga.cost, SUM(crm.closed_won_amount)) AS cost_to_revenue_ratio
FROM staging.click_with_gclid ga
LEFT JOIN crm.deals crm
  ON ga.gclid = crm.gclid
GROUP BY ga.date, ga.campaign_name, ga.cost, ga.conversions;

El LEFT JOIN es deliberado: la inversión sin emparejar debe permanecer visible. Si hace un inner join, cada clic sin un deal emparejado desaparece silenciosamente, y su matemática de coste-por-ingreso se halaga a sí misma. Mantenga toda la inversión en el resultado y trate la tasa de emparejamiento como su propia métrica de salud.

Unir GA4 para profundidad de comportamiento. La exportación de GA4 aterriza filas a nivel de evento con event_params anidados. Desanídelos para recuperar la campaña, la calidad de sesión y la landing page, luego agregue a la granularidad que necesite.

-- staging.ga4_sessions (campaign and landing page recovered from event_params)
SELECT
  PARSE_DATE('%Y%m%d', event_date) AS date,
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'campaign') AS campaign,
  COUNTIF(event_name = 'session_start') AS sessions,
  COUNTIF(event_name = 'sign_up')       AS signups
FROM `analytics_XXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20261231'
GROUP BY date, campaign;

Restrinja siempre el _TABLE_SUFFIX de GA4 a un rango de fechas — las tablas de eventos son grandes y un escaneo con wildcard sin límites es la trampa de coste clásica de GA4.

Cargar el CRM. Lleve los deals a BigQuery con lo que encaje en su stack: un conector gestionado como Fivetran, una Cloud Function programada que llama a la API de su CRM, o una carga nocturna de CSV. Las columnas mínimas son deal ID, GCLID, importe cerrado-ganado, fecha de cierre, y etapa. Refresque a diario para que el ingreso se mantenga actual.

Cuando la cobertura de GCLID es pobre, las tasas de emparejamiento sufren y el ingreso parece subestimado. Los arreglos aguas arriba son las enhanced conversions y la importación de conversiones offline, que ambos mejoran cuán fiablemente los clics se atan a los resultados — vea nuestra guía de configuración de enhanced conversions. Como recurso en el warehouse, un join basado en UTM recupera algunas filas sin emparejar, pero trátelo como un complemento de menor confianza, no un reemplazo del GCLID.

El resultado de esta sección es una única tabla unificada que lleva inversión, conversiones de Google, engagement de GA4, e ingreso del CRM lado a lado — la tabla sobre la que se construye cada informe de PPC significativo.

Scheduled queries y el refresco diario

Con la lógica de staging y reporting escrita, automatice la construcción diaria para que el warehouse se mantenga solo.

Las scheduled queries nativas son la herramienta correcta para empezar. BigQuery le permite programar cualquier sentencia SQL en una cadencia tipo cron sin coste extra más allá del procesamiento de consultas que consume. Programe primero la construcción de staging, luego la de reporting, ambas cronometradas unas horas después de que el DTS y la exportación de GA4 típicamente se completen por la mañana. Ese orden asegura que cada capa lee datos frescos aguas arriba.

Use las semánticas de escritura correctas:

Para la mayoría del reporting de PPC, reconstruir las N particiones anteriores con WRITE_TRUNCATE de ámbito a esas particiones es el enfoque correcto más simple — absorbe naturalmente el backfill de la ventana de refresco de DTS sin duplicar datos más antiguos.

Añada una comprobación de frescura. Una pequeña scheduled query que compara la fecha máxima de cada tabla fuente con hoy y escribe una alerta (o falla ruidosamente) atrapa el modo de fallo silencioso donde DTS o la exportación de GA4 se salta un día y sus dashboards muestran silenciosamente cifras obsoletas. Esta única guarda previene la clase más embarazosa de incidente de reporting.

-- monitoring.freshness_check
SELECT
  'google_ads' AS source,
  MAX(date)    AS latest_date,
  DATE_DIFF(CURRENT_DATE(), MAX(date), DAY) AS days_behind
FROM staging.campaign_performance_daily
HAVING days_behind > 1;

Si esa consulta devuelve filas, algo aguas arriba está obsoleto y necesita atención.

Cuándo graduarse a dbt. Las scheduled queries manejan cómodamente un warehouse de una sola cuenta durante mucho tiempo. Pase a dbt cuando la lógica de transformación supere unos 10-15 modelos interdependientes, cuando quiera tests automatizados y documentación a nivel de columna, o cuando varios analistas editen el mismo SQL y necesiten control de versiones y linaje. dbt orquestado por Cloud Composer (Airflow gestionado) es el siguiente paso común — pero adóptelo porque la complejidad lo exige, no porque esté de moda.

Disciplina de backfill. Cuando cambie una transformación, vuelva a ejecutarla a lo largo del historial para que las particiones antiguas reflejen la nueva lógica. Parametrice sus scheduled queries por fecha para que el mismo SQL sirva tanto la ejecución incremental diaria como un backfill completo manual.

Reporting en Looker Studio y gestión de costes

El warehouse solo es útil si la gente puede leerlo, y Looker Studio es el front end natural para BigQuery.

Conecte solo a tablas curadas. Apunte cada fuente de datos de Looker Studio al dataset reporting, nunca a exportaciones brutas o tablas anchas de staging. Esta es la decisión de coste más importante de todo el pipeline. Looker Studio refresca las consultas en la interacción y en una programación de caché; si un dashboard popular consulta una tabla de historial completo sin particionar, los bytes escaneados — y la factura — se componen rápido.

Un conjunto práctico de dashboards iniciales:

• Visión general ejecutiva — inversión blended, conversiones, e ingreso del CRM entre canales, en tendencia a lo largo del tiempo.
• Visión general de cuentas — rendimiento por cuenta para configuraciones de MCC, usando los nombres amigables del account-map.
• Drill-down de campañas — inversión, CPA, coste-por-ingreso, y engagement de GA4 por campaña y grupo de anuncios.

Controles de coste que realmente importan:

Monitorice las consultas más caras. La vista INFORMATION_SCHEMA.JOBS expone cada consulta, quién la ejecutó, y cuántos bytes procesó. Una mirada semanal a los mayores consumidores hace aflorar el único informe o scheduled query que domina silenciosamente su factura, para que pueda optimizarlo — normalmente añadiendo un filtro de partición o materializando un join.

SELECT
  user_email,
  query,
  total_bytes_processed / POW(10, 12) AS tb_processed
FROM `region-eu`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY total_bytes_processed DESC
LIMIT 20;

Fije un presupuesto de facturación y una alerta en el proyecto de Cloud sin importar cuán cuidadoso sea. Es el respaldo que convierte una consulta descontrolada de una sorpresa de fin de mes en una notificación del mismo día.

Con tablas curadas, filtros de partición, BI Engine para dashboards calientes, y monitorización de costes semanal, un warehouse de una sola cuenta se mantiene cómodamente en el rango de 30-150 €/mes mientras sirve informes rápidos y fiables.

Patrones SQL para incrementalidad y bases de LTV

El warehouse no es solo reporting más bonito — es el sustrato para el trabajo de medición que impulsa decisiones reales de presupuesto. Aquí están los patrones fundamentales.

Incrementalidad geo-holdout. El testing de incrementalidad pregunta qué conversiones habrían ocurrido sin los anuncios. El warehouse hace el análisis trivial una vez que se ejecuta un experimento geo: etiquete las regiones como test o control, luego compare las tasas de conversión entre los dos grupos para la ventana de test.

-- incrementality lift by region group
SELECT
  geo_group,
  SUM(conversions) / SUM(sessions) AS conversion_rate
FROM reporting.geo_experiment
WHERE date BETWEEN @test_start AND @test_end
GROUP BY geo_group;

El lift entre test y control, normalizado por el tamaño del grupo, estima la contribución incremental. La metodología y el diseño del test viven en nuestra guía de testing de incrementalidad; BigQuery es donde lo computa a escala y lo vuelve a ejecutar cada trimestre sin esfuerzo manual.

Retención por cohortes y LTV. El modelado del valor de vida empieza cohortando a los clientes por mes de adquisición y rastreando el ingreso hacia adelante.

-- monthly acquisition cohorts with cumulative revenue
SELECT
  DATE_TRUNC(first_close_date, MONTH) AS cohort_month,
  DATE_DIFF(revenue_month, first_close_date, MONTH) AS month_index,
  SUM(revenue) AS cohort_revenue
FROM reporting.customer_revenue_monthly
GROUP BY cohort_month, month_index
ORDER BY cohort_month, month_index;

Esta matriz de cohortes es la materia prima para las curvas de LTV, el análisis de período de payback, y los ratios CAC-a-LTV por canal de adquisición — las métricas que deberían gobernar la asignación de presupuesto. Unida de vuelta a la campaña que produjo el GCLID de cada cliente, puede computar el LTV por campaña, no solo el CPA por campaña, que es un objetivo de optimización mucho mejor. Nuestro análisis de payback de CAC por vertical muestra los benchmarks que alimentan estas consultas.

Reporting cross-channel blended. Una vez que Meta, LinkedIn y otros canales aterrizan en el mismo warehouse con definiciones consistentes, un único UNION ALL de la tabla diaria de cada canal seguido de GROUP BY channel con SAFE_DIVIDE(SUM(revenue), SUM(cost)) para el ROAS blended produce la vista cross-channel que ninguna interfaz de plataforma puede. La parte difícil son las definiciones consistentes, no el SQL.

Input de marketing mix modeling. Los equipos avanzados alimentan el warehouse directamente a un MMM. El framework open-source Meridian de Google lee inversión y resultados agregados semanalmente — exactamente la forma que sus tablas de reporting ya producen. Una única scheduled query pivota los datos diarios a la matriz semanal de canales que Meridian espera, cerrando el bucle de los datos de clic brutos al modelado estadístico de presupuesto.

Estos patrones son bases, no modelos terminados, pero son la parte difícil de acertar estructuralmente. Con datos limpios, unidos y particionados en BigQuery, añadir incrementalidad, LTV y MMM encima se convierte en un ejercicio de analítica en lugar de una pesadilla de fontanería de datos.

Para un contexto más amplio sobre los cambios de privacidad y tracking que hacen un warehouse first-party cada vez más esencial, vea nuestra guía de estrategia de datos first-party y el análisis del futuro sin cookies.

Un warehouse de reporting le dice a dónde fue el dinero; una capa de optimización decide a dónde va después. Si quiere optimización de Google Ads impulsada por IA que pueda actuar sobre las señales de coste-por-ingreso que su pipeline de BigQuery hace aflorar, SteerAds ejecuta una auditoría gratuita de 14 días sobre cuentas de Google y Microsoft Ads.

Sources

• cloud.google.com/bigquery/docs/google-ads-transfer — documentación del Data Transfer Service de Google Ads
• cloud.google.com/bigquery/docs — documentación de BigQuery
• support.google.com/analytics — documentación de la exportación de GA4 a BigQuery
• cloud.google.com/looker/docs/studio — documentación de Looker Studio
• cloud.google.com/blog/products/data-analytics — blog de analítica de datos de Google Cloud

FAQ