How to connect Facebook Ads to Looker Studio — every route, and what each one costs
There is no Google-built connector for Facebook Ads, and there never will be. If you opened the Looker Studio data source picker, typed "Facebook", and got back a grid of third-party tiles with pricing pages attached, that wasn't a search failure — it's the actual state of the integration. This page lays out the four routes that genuinely exist, what each one costs in money and in maintenance, which of the "free" options are real, and the attribution problem that every route gets wrong by default.
Why there's no native Facebook Ads connector
Looker Studio's catalogue is three catalogues wearing one coat. Google connectors — Search Console, Analytics, Google Ads, Sheets, BigQuery — are first-party and free. Partner connectors are commercial products built and sold by other companies, typically billed per data source per month. Community connectors are things someone published and may or may not still maintain.
Meta Ads lives in the second and third groups, alongside TikTok, LinkedIn, Shopify and Stripe. Meta is a competitor of Google's in advertising; a free first-party pipe into a Google reporting product was never a plausible product decision. We wrote the long version of that argument in no Looker Studio connector for your source.
The practical consequence: the moment a source needs a partner connector, its cost stops scaling with how much data you have and starts scaling with how many sources you have. A five-channel report costs five times more to keep alive than a one-channel report, and the data hasn't grown at all.
The four routes that actually exist
1. A paid partner connector
Supermetrics, Windsor.ai, Catchr, Porter, Dataslayer and others all sell this. You authorize, pick the ad account, and Facebook data shows up in the picker as though it were native. This is the fastest route to a working chart, and for one awkward source that matters daily it's the right call.
What it costs beyond the subscription: a vendor relationship per source, an OAuth grant that expires and has to be re-approved, a status page to check when the chart goes blank, and pricing tiers that often key off the number of ad accounts — which is the exact dimension an agency grows along.
2. A community connector
Free, listed in the same gallery, and the reason many people think the problem is solved. The tradeoff is real: you're granting an unknown third party a token to your ad account, and there is no obligation on anyone to update it when Meta ships a breaking Marketing API version. The failure mode isn't an error message — it's a dashboard that keeps rendering yesterday's shape with today's date while returning nothing new.
3. Export from Ads Manager into Sheets
Also free, works today, and quietly the most common thing people actually do. Ads Manager exports a CSV, the CSV goes into a Google Sheet, and Looker Studio reads the Sheet through a first-party connector. It rots in three predictable ways: every refresh is a human remembering to re-export, every column change from Meta breaks a formula three tabs deep, and the dashboard gives no signal at all that the numbers behind it are eleven days old.
4. Land it in BigQuery first
The "do it properly" answer and genuinely correct at warehouse scale. But it moves the problem rather than removing it: something still has to write Facebook data into BigQuery, and that something is either an ELT vendor billed per connector — the connector tax, re-bought one layer down — or pipeline code you now own and debug. For a marketing dataset measured in millions of rows rather than billions, it's several sizes too big; we argued that case in the smallest marketing data warehouse that actually works.
"Connect Facebook Ads to Looker Studio free" — honestly
A lot of people arrive at this problem with the word free attached, so it deserves a straight answer rather than a funnel. Two of the four routes above cost nothing in cash: the community connector and the Sheets export. Both are legitimate, and both pay for themselves in a currency other than money.
The community connector charges you in trust and fragility — an unknown party holds a token to your ad account, and nobody owes you a fix when the API version rolls. The Sheets route charges you in attention — roughly ten minutes a week forever, plus the risk that someone makes a budget call on a stale tab. If your reporting is one account and one monthly deck, the Sheets route is genuinely fine and you should stop reading here. If it's several accounts, weekly, for people who act on the numbers, the free routes are the expensive ones.
The thing every route gets wrong by default
This is the failure that survives all four options, so it's worth more attention than the connector choice itself. Meta re-attributes conversions over a trailing window of roughly seven days. A conversion that happens today can be credited back to an impression from five days ago, which means the numbers for last Tuesday are still changing this Tuesday.
Any pipeline that pulls "yesterday only" and appends is therefore permanently wrong in the recent past — and it's wrong in the flattering direction, because the revisions are usually upward. The dashboard shows a soft week that quietly firmed up after nobody looked again. The fix is to re-pull the trailing window on every sync rather than append once, and to make the report say which days are still settling. Most connector setups do neither, and nothing in the Looker Studio canvas will tell you.
The fifth route: skip the canvas
The option that isn't in the picker, because it isn't a picker entry: don't build the report in Looker Studio at all. Hand the same data to a backend that normalizes it into shared cross-channel definitions, and publish the dashboard from there. You give up drag-and-drop. You get back the per-source pricing model, the refresh ritual and the attribution drift in one move.
That's what TableBI does. The route that works for everyone today is the export — the same CSV you'd have pasted into a Sheet, labelled on ingest so it lands in the same tables as your other channels:
# install once npm i -g @tablebi/cli tablebi login tablebi install # the Ads Manager export, normalized into shared definitions tablebi connect csv --file meta-ads-august.csv --platform meta_ads # check what landed and how it was interpreted tablebi sources tablebi sample
The --platform label isn't cosmetic metadata. It's what lets those rows sit in the same facts table as Google Ads and Search Console, so spend is spend and clicks are clicks regardless of which platform's dialect they arrived in. That's the thing a per-source connector structurally cannot give you: connectors deliver each platform in its own vocabulary and leave the reconciliation to you and a blend configuration that lies.
There's also a live OAuth connector:
tablebi connect meta_ads tablebi sync meta_ads
Meta Ads is in beta. Our Meta app hasn't cleared App Review yet, so today it only authorizes ad accounts you own or that have been added as test users. If that's not you, the CSV route above is the one that works — and it lands in exactly the same tables. Search Console, GA4 and Google Ads connect live with no such caveat.
What you can ask once it's in
The point of getting Facebook out of its own dashboard is the question that needed two dashboards before:
# ROAS across Meta and Google Ads, one query, one definition of 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"
Two things there are load-bearing. roas() and cpa() are definition macros, so the arithmetic is computed once in the backend rather than re-derived — which is how you avoid the averaging bug that corrupts most hand-built ratio charts (the long version). And the date filter anchors on MAX(date) rather than the calendar, because of the attribution window above: "today" is not a settled row.
Forensic questions drop to the raw altitude instead, where Meta's own fields survive untouched:
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"
Every answer carries a trust block — freshness per source plus the caveats that apply, including the trailing re-attribution window. For the reporting workflow rather than the connection, see Meta ads reporting without the spreadsheet grind; for the blended number this all exists to produce, blended ROAS.
Pin it to a live URL
When a view is worth keeping, pin it. What's stored is the query, not a snapshot, so the URL refreshes itself as data syncs:
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)
A real one, pinned exactly this way — live data, not a mockup: