Cómo conectar Facebook Ads a Looker Studio: todas las vías y lo que cuesta cada una

Google no tiene un conector propio de Facebook Ads para Looker Studio, y nunca lo tendrá. Hay cuatro formas de conectar Facebook Ads a Looker Studio: un conector de socio de pago, un conector de la comunidad gratuito, exportar desde el Administrador de anuncios a Hojas de cálculo de Google o cargar antes los datos en BigQuery. Si abres el selector de fuentes de datos de Looker Studio (que Google volvió a llamar Data Studio en abril de 2026), escribes «Facebook» y te aparece una cuadrícula de conectores de terceros, cada uno con su página de precios, no es que hayas buscado mal: la integración está así. Esta guía explica cada vía, lo que cuesta en dinero y en mantenimiento, cuáles de las opciones «gratis» lo son de verdad y el problema de atribución que todas arrastran por defecto.

Por qué no existe un conector nativo de Facebook Ads

El catálogo de conectores de Looker Studio en realidad son tres catálogos bajo el mismo techo. Los conectores de Google (Search Console, Analytics, Google Ads, Hojas de cálculo de Google y BigQuery) son oficiales y gratuitos. Los conectores de socios son productos comerciales que desarrollan y venden otras empresas, y suelen cobrarse por fuente de datos y por mes. Los conectores de la comunidad son lo que alguien publicó en su día y quizá siga manteniendo, o quizá no.

Meta Ads está en el segundo y en el tercer grupo, junto a TikTok, LinkedIn, Shopify y Stripe. Meta compite con Google en publicidad: una conexión oficial y gratuita hacia un producto de informes de Google nunca fue una decisión de producto plausible. La versión larga de ese argumento está en no hay conector de Looker Studio para tu fuente (en inglés).

Las cuatro vías que existen de verdad

1. Un conector de socio de pago

Lo venden Supermetrics, Windsor.ai, Catchr, Porter, Dataslayer y otros. Autorizas, eliges la cuenta publicitaria y los datos de Facebook aparecen en el selector como si fueran nativos. Es la vía más rápida hasta un gráfico que funcione y, para una sola fuente complicada que importa a diario, es la decisión correcta.

Lo que cuesta además de la suscripción: un proveedor más por cada fuente, una autorización OAuth que caduca y hay que volver a aprobar, una página de estado que consultar cuando el gráfico se queda en blanco, y planes de precios que a menudo se basan en el número de cuentas publicitarias, que es justo la dimensión en la que crece una agencia.

2. Un conector de la comunidad

Es gratis, aparece en la misma galería y es la razón por la que mucha gente cree que el problema está resuelto. Pero tiene un precio real: le das a un tercero desconocido un token de tu cuenta publicitaria, y nadie está obligado a actualizarlo cuando Meta publica una versión de la Marketing API que rompe la compatibilidad. Cuando falla no ves un mensaje de error: ves un dashboard que sigue mostrando la forma de ayer con la fecha de hoy, sin traer nada nuevo.

3. Exportar desde el Administrador de anuncios a Hojas de cálculo de Google

También es gratis, funciona hoy y, aunque nadie lo diga en voz alta, es lo que más gente hace en la práctica. El Administrador de anuncios exporta un CSV, el CSV va a una hoja de cálculo de Google (Google Sheets) y Looker Studio lee esa hoja con un conector oficial de Google. Se estropea de tres maneras previsibles: cada actualización depende de que alguien se acuerde de volver a exportar, cada cambio de columnas de Meta rompe una fórmula escondida tres pestañas más allá, y el dashboard no da ninguna señal de que los números que tiene detrás son de hace once días.

4. Cargarlo primero en BigQuery

Es la respuesta de «hazlo como es debido» y, a escala de data warehouse, es correcta. Pero traslada el problema en lugar de eliminarlo: algo tiene que escribir los datos de Facebook en BigQuery, y ese algo es o un proveedor de ELT que cobra por conector (el mismo peaje por conector, pagado otra vez una capa más abajo) o código de pipeline que pasa a ser tuyo y que te toca depurar. Para un conjunto de datos de marketing que se mide en millones de filas y no en miles de millones, es varias tallas más grande de lo que necesitas; lo argumentamos en el data warehouse de marketing más pequeño que de verdad funciona (en inglés).

Instagram Ads: las mismas cuatro vías, con un paso más

Los anuncios de Instagram son anuncios de Meta, así que no hay un conector de Instagram Ads aparte que buscar. Se compran en el mismo Administrador de anuncios, se facturan a la misma cuenta publicitaria y sus datos salen de la misma Marketing API. Cualquiera de las vías anteriores que traiga Facebook Ads ya trae tus anuncios de Instagram, sumados en los mismos totales de campaña.

El paso extra es separarlos. Meta no trata el lugar donde se mostró un anuncio como una cuenta aparte, sino como un desglose: en el Administrador de anuncios es Desglose → Por entrega → Plataforma (Breakdown → By delivery → Platform en la interfaz en inglés), y en la Marketing API es el desglose publisher_platform, que Meta documenta como la plataforma en la que se mostró el anuncio: Facebook, Instagram o Audience Network (referencia de desgloses de Meta, en inglés). Si traes los datos a nivel de campaña sin ese desglose, Facebook e Instagram llegan sumados, y Looker Studio no tiene forma de separarlos después.

• Conector de socio: añade al gráfico la dimensión de plataforma (publisher platform). Un conector que no la ofrezca no puede separar Instagram.
• Exportación a Hojas de cálculo: aplica el desglose Plataforma en el Administrador de anuncios antes de exportar, para que el CSV traiga una fila por plataforma.
• TableBI: el conector en vivo de Meta Ads (beta) sincroniza a nivel de campaña, así que la inversión y los resultados de Instagram quedan dentro de los totales de campaña, sin separar por plataforma. Una exportación del Administrador de anuncios con el desglose Plataforma sí conserva esa columna: TableBI guarda en meta_ads_raw cada columna del CSV para la que no tiene una definición compartida, y ahí puedes agrupar por ella.

Estadísticas de páginas de Facebook y datos públicos: van por separado

Los datos orgánicos de Facebook (el alcance, los seguidores, las publicaciones y la interacción de una página) no llegan por ningún conector de Facebook Ads. Pertenecen a la página y no a la cuenta publicitaria, requieren otro permiso, y los proveedores de conectores los venden como una fuente aparte. Supermetrics, por ejemplo, ofrece Facebook Insights para las páginas que administras y Facebook Public Data para las publicaciones públicas de páginas que no administras: dos conectores distintos del de Facebook Ads.

Los «datos públicos de Facebook» son la más limitada de las dos fuentes. Sirven para compararte con otras páginas a partir de lo que publican, y la propia documentación de Supermetrics indica que hay datos de aproximadamente 600 publicaciones clasificadas y publicadas por año, y solo de los comentarios de primer nivel (documentación de Supermetrics, en inglés).

La vía gratuita es igual que la de los anuncios: en Meta Business Suite, el botón Exportar de Insights (Export en la interfaz en inglés) descarga como archivo las estadísticas que estás viendo (Servicio de ayuda de Facebook), y una hoja de cálculo de Google con ese archivo entra en Looker Studio como cualquier otra hoja. TableBI no conecta Page Insights: su conector de Meta solo cubre anuncios.

«Conectar Facebook Ads a Looker Studio gratis», sin rodeos

Mucha gente llega a este problema con la palabra gratis por delante, así que merece una respuesta directa y no un embudo de ventas. Dos de las cuatro vías no cuestan dinero: el conector de la comunidad y la exportación a Hojas de cálculo. Las dos son legítimas, y las dos se cobran en otra moneda que no es el dinero.

El conector de la comunidad te cobra en confianza y fragilidad: alguien desconocido tiene un token de tu cuenta publicitaria y nadie te debe un arreglo cuando cambia la versión de la API. La vía de Hojas de cálculo te cobra en atención: unos diez minutos a la semana para siempre, más el riesgo de que alguien decida un presupuesto mirando una pestaña desactualizada. Si tus informes son una cuenta y una presentación al mes, la vía de Hojas de cálculo está bien de verdad y puedes dejar de leer aquí. Si son varias cuentas, cada semana, para gente que toma decisiones con esos números, las vías gratis son las caras.

El fallo que todas las vías tienen por defecto

Este fallo sobrevive a las cuatro opciones, así que merece más atención que la propia elección del conector. Meta vuelve a atribuir conversiones durante una ventana móvil de unos siete días. Una conversión que ocurre hoy puede atribuirse a una impresión de hace cinco días, lo que significa que los números del martes pasado siguen cambiando este martes.

Por eso, cualquier pipeline que traiga «solo ayer» y lo añada al final se equivoca para siempre en el pasado reciente, y casi siempre por lo bajo: como las revisiones suelen ser al alza, guarda cifras demasiado bajas y la semana parece más floja de lo que fue en realidad. El dashboard enseña una semana mediocre que después mejoró sin que nadie volviera a mirarla. La solución es volver a traer la ventana completa en cada sincronización en lugar de añadir los datos una sola vez, y que el informe diga qué días todavía se están asentando. La mayoría de las configuraciones con conectores no hacen ninguna de las dos cosas, y nada en el lienzo de Looker Studio te lo va a advertir.

La quinta vía: saltarse el lienzo

La opción que no está en el selector, porque no es una entrada del selector: no construir el informe en Looker Studio. Entregar los mismos datos a un backend que los normalice en definiciones compartidas entre canales y publicar el dashboard desde ahí. Renuncias al arrastrar y soltar. A cambio, te quitas de encima de una vez el precio por fuente, el ritual de actualizar a mano y la deriva de la atribución.

Eso es lo que hace TableBI. La vía que hoy funciona para todo el mundo es la exportación: el mismo CSV que habrías pegado en una hoja de cálculo, etiquetado al cargarlo para que caiga en las mismas tablas que tus otros canales:

# instalar una sola vez
npm i -g @tablebi/cli
tablebi login
tablebi install

# la exportación del Administrador de anuncios, normalizada en definiciones compartidas
tablebi connect csv --file meta-ads-august.csv --platform meta_ads

# comprobar qué se cargó y cómo se interpretó
tablebi sources
tablebi sample

La etiqueta --platform no es un metadato decorativo. Es lo que permite que esas filas convivan en la misma tabla facts que Google Ads y Search Console, de modo que la inversión es inversión y los clics son clics, sea cual sea el dialecto de la plataforma de la que llegan. Eso es lo que un conector por fuente no puede darte por diseño: los conectores entregan cada plataforma con su propio vocabulario y te dejan la conciliación a ti y a una combinación de datos que engaña.

También hay un conector OAuth en vivo:

tablebi connect meta_ads
tablebi sync meta_ads

Meta Ads está en beta. Nuestra app de Meta todavía no ha superado la revisión de apps (App Review), así que hoy solo funciona con cuentas publicitarias de tu propiedad o con personas añadidas como usuarios de prueba. Si no es tu caso, la vía del CSV es la que funciona, y cae exactamente en las mismas tablas. Search Console, GA4 y Google Ads se conectan en vivo sin esa salvedad.

Qué puedes preguntar cuando los datos ya están dentro

La razón para sacar Facebook de su propio dashboard es la pregunta que antes necesitaba dos dashboards:

# ROAS de Meta y Google Ads: una consulta, una sola definición de ROAS
tablebi ask "SELECT platform, SUM(cost) AS spend,
             roas(SUM(conversion_value), SUM(cost)) AS roas,
             cpa(SUM(cost), SUM(conversions)) AS cpa
             FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 28
             GROUP BY platform ORDER BY spend DESC"

Dos detalles sostienen todo lo demás. roas() y cpa() son macros de definición: la cuenta se hace una sola vez en el backend en lugar de rehacerse en cada gráfico, y así se evita el error de promediar ratios que estropea la mayoría de los gráficos de ratios hechos a mano (la versión larga, en inglés). Y el filtro de fechas se ancla en MAX(date) y no en el calendario porque Meta sigue reatribuyendo conversiones durante unos siete días: «hoy» todavía no es una fila asentada.

Para investigar a fondo, bajas al nivel en bruto, donde los campos propios de Meta se conservan tal cual:

tablebi ask "SELECT campaign, SUM(clicks) AS clicks, SUM(impressions) AS imp
             FROM meta_ads_raw
             GROUP BY campaign ORDER BY clicks DESC LIMIT 20"

Cada respuesta incluye un bloque de confianza (trust block): lo actualizada que está cada fuente y las advertencias pertinentes, incluida la ventana móvil de reatribución. Para el flujo de trabajo de los informes, más allá de la conexión, lee informes de Meta Ads sin pelearte con hojas de cálculo; para la cifra combinada que todo esto persigue, el ROAS combinado (blended ROAS). Los dos artículos están en inglés.

Fíjalo en una URL en vivo

Cuando una vista merece conservarse, fíjala. Lo que se guarda es la consulta, no una captura, así que la URL se actualiza sola a medida que se sincronizan los datos:

tablebi pin --title "Paid overview — Meta + Google Ads" \
  --widget "Daily spend::line=SELECT date, SUM(cost) AS spend FROM facts …" \
  --widget "ROAS by platform=SELECT platform, roas(SUM(conversion_value), SUM(cost)) AS roas FROM facts …"
✓ published → https://dk.tablebi.com/d/dsh_…  (public, read-only, self-refreshing)

Aquí tienes uno real, fijado exactamente así: datos en vivo, no una maqueta.