Cómo conectar Facebook Ads a BigQuery: métodos, costes y el truco de la atribución tardía

Mirar los informes dentro de Meta Ads Manager se parece demasiado a jugar en el casino del anfitrión: las fichas las pone él, las reglas las define él y las ganancias que te atribuye en pantalla siempre parecen más abultadas que el dinero que acaba entrando en tu cuenta bancaria. Desde que los cambios de privacidad desbarataron el rastreo de terceros y Meta empezó a apoyarse en modelos probabilísticos y atribuciones estimadas, fiarse a ciegas del panel nativo es el camino más rápido para inflar presupuestos en campañas que en la vida real están quemando caja.

Para tener una foto honesta del retorno publicitario hace falta sacar el dato de la plataforma y llevarlo a un terreno neutral. Y en analítica moderna, ese terreno neutral casi siempre se llama Google BigQuery. Conectar los datos de gasto, impresiones, clics y conversiones de Facebook Ads a BigQuery te permite cruzarlos con los eventos crudos de Google Analytics 4, los pedidos reales de tu base de datos y los costes de pasarela, construyendo una sola fuente de verdad sobre la incrementalidad real de tus anuncios.

Ahora bien: conectar ambas plataformas no es pulsar un botón mágico. Implica elegir entre pagar herramientas de terceros, mantener código propio y, sobre todo, esquivar la trampa técnica que arruina el 90% de estas canalizaciones: la ventana de atribución retrospectiva de Meta.

Las tres vías reales para conectar Facebook Ads con BigQuery

Cuando te sientas a planificar la arquitectura de extracción, tienes tres alternativas sobre la mesa. Cada una tiene su peaje: unas te cobran en dinero cada mes; otras, en tiempo de desarrollo.

Si tu presupuesto es holgado y tu equipo solo sabe arrastrar cajitas en Looker Studio, paga un conector de terceros y olvídate. Pero si gestionas una estructura con cabeza o quieres entender qué estás pagando, montar un script serverless en Google Cloud Platform (GCP) no solo te ahorra miles de euros al año, sino que te blinda ante los cambios de tarifas abusivos de las plataformas de sincronización.

El gran dolor de cabeza: la ventana de atribución retrospectiva de Meta

Aquí es donde casi todos los principiantes meten la pata. Programan una sincronización diaria que cada madrugada a las 02:00 descarga los datos del día anterior (yesterday) y los inserta en BigQuery en modo APPEND. A final de mes, comparan el gasto e ingresos de BigQuery con el Ads Manager y falta un 25% de las compras. La primera sospecha suele ser culpar a la API de Meta.

El fallo no es de la API; es de diseño conceptual. Meta utiliza de forma predeterminada una ventana de atribución de 7 días tras clic y 1 día tras visualización. Eso significa que un usuario que hizo clic en un anuncio el lunes pero compró el jueves verá su compra atribuida por Meta al lunes original. Si tu canalización solo leyó el lunes una vez y nunca volvió a revisarlo, esa conversión jamás entrará en tu almacén de datos.

Para resolver esto sin multiplicar los costes de almacenamiento, debes aplicar una estrategia de ventana móvil incremental:

1. Cada ejecución diaria no consulta solo el día previo, sino los últimos 7 o 14 días móviles de la API de Insights.
2. Vuelca esa información en una tabla temporal de aterrizaje (staging).
3. Ejecuta una sentencia MERGE en BigQuery contra la tabla maestra consolidada, actualizando los registros existentes por fecha y ad_id e insertando los nuevos.

-- Lógica de consolidación con ventana móvil para evitar duplicados
MERGE `mi_proyecto.marketing_meta.fact_facebook_ads_daily` T
USING `mi_proyecto.marketing_meta.staging_facebook_ads_recent` S
ON T.date = S.date AND T.ad_id = S.ad_id
WHEN MATCHED THEN
  UPDATE SET
    T.spend = S.spend,
    T.impressions = S.impressions,
    T.clicks = S.clicks,
    T.conversions = S.conversions,
    T.conversion_value = S.conversion_value,
    T.updated_at = CURRENT_TIMESTAMP()
WHEN NOT MATCHED THEN
  INSERT (date, ad_id, campaign_name, adset_name, ad_name, spend, impressions, clicks, conversions, conversion_value, updated_at)
  VALUES (S.date, S.ad_id, S.campaign_name, S.adset_name, S.ad_name, S.spend, S.impressions, S.clicks, S.conversions, S.conversion_value, CURRENT_TIMESTAMP());

Paso a paso: Configurar la extracción con Python y Cloud Functions

Si optas por la vía de control propio, el flujo técnico consta de cuatro piezas elementales dentro del ecosistema de Meta y Google Cloud:

1. Crear la App en Meta for Developers y obtener credenciales

Necesitas una aplicación en el portal de desarrolladores de Meta asociada a tu Business Manager. Desde allí generas un Token de Acceso de Usuario del Sistema (System User Token) permanente con permisos ads_read y read_insights. Jamás utilices tokens de usuario estándar generados desde el Graph API Explorer; caducan a los 60 días y romperán la sincronización en silencio.

2. Consultar el endpoint de Insights de la Graph API

La llamada principal de extracción se dirige a https://graph.facebook.com/v21.0/act_{AD_ACCOUNT_ID}/insights. Los parámetros clave que debes solicitar son:

• level=ad (para tener granularidad por anuncio y cruzar con UTMs).
• time_increment=1 (para recibir datos desglosados día a día y no un único agregado).
• fields=date_start,campaign_id,campaign_name,adset_id,adset_name,ad_id,ad_name,spend,impressions,clicks,actions,action_values.
• time_range={'since':'YYYY-MM-DD', 'until':'YYYY-MM-DD'} (cubriendo tu ventana móvil).

3. Desplegar la Cloud Function en Google Cloud

Empaqueta tu script de Python en una Cloud Function de segunda generación (o servicio Cloud Run) configurada en la misma región geográfica donde reside tu dataset de BigQuery (por ejemplo, europe-west1 para cumplir RGPD y evitar costes de transferencia entre regiones). La función procesará la paginación JSON de la API de Meta y cargará los registros utilizando el cliente nativo google-cloud-bigquery.

4. Automatizar la frecuencia con Cloud Scheduler

Crea un trabajo en Cloud Scheduler con una expresión cron sencilla: 0 4 * * * (todos los días a las 04:00 AM UTC). Al activarse, disparará tu Cloud Function mediante autenticación OIDC segura, completando la extracción sin intervención humana.

Buenas prácticas de diseño en BigQuery para no derrochar recursos

BigQuery cobra por dos conceptos: almacenamiento y volumen de bytes procesados en las consultas SQL. Si diseñas la tabla de forma descuidada, una consulta en Looker Studio puede escanear tu histórico entero cientos de veces al día:

• Particiona siempre por fecha (PARTITION BY date): Esto garantiza que cuando consultes el último trimestre en tu panel de control, BigQuery solo lea las particiones de esos 90 días, reduciendo el coste de consulta hasta un 95%.
• Agrupa por dimensiones clave (CLUSTER BY campaign_id, ad_id): El clustering físico ordena los bloques de datos en disco, acelerando los filtros de campañas individuales y reduciendo drásticamente el tiempo de respuesta en dashboards.
• Vigila el formato del campo actions: Meta devuelve las conversiones como un array de objetos (action_type y value). Normaliza en tu script de extracción los eventos principales (compras, leads, añadidos al carrito) en columnas numéricas directas antes de insertarlos en BigQuery; consultar arrays anidados en SQL añade complejidad innecesaria a tus analistas.

El valor real: cruzar Meta Ads con GA4 y facturación

Llevar Facebook Ads a BigQuery no tiene como fin duplicar el panel de Meta en otra ventana. Su propósito es responder a las preguntas que ninguna plataforma puede contestar en solitario:

¿Qué porcentaje de los leads reportados por Meta con coste de 5 € terminaron firmando un contrato comercial en tu CRM? ¿Cuántos clientes que compraron a través de una campaña de retargeting en Instagram ya habían entrado orgánicamente por artículos de posicionamiento SEO? Al unir en SQL tu tabla de Facebook Ads con tus eventos de calidad de datos de GA4 y las tablas de facturación de tu ERP, dejas atrás la fantasía del ROAS inflado y empiezas a gestionar la adquisición con la frialdad de los números reales.