Facebook Ads verbinden met Looker Studio: alle routes en wat elke route kost

Google heeft geen eigen Facebook Ads-connector voor Looker Studio, en die komt er ook niet. Je kunt Facebook Ads toch met Looker Studio verbinden, via vier routes: een betaalde partnerconnector, een gratis communityconnector, een eveneens gratis export uit Advertentiebeheer (Ads Manager) naar Google Spreadsheets, of BigQuery als tussenstation. Heb je in Looker Studio (sinds april 2026 weer Data Studio) bij Maken → Gegevensbron (Create → Data source) „Facebook” getypt en alleen tegels van derden met een prijspagina gevonden? Dan lag dat niet aan je zoekopdracht: zo ziet deze koppeling er gewoon uit. Deze handleiding laat zien wat elke route kost aan geld en onderhoud, welke „gratis” opties echt bruikbaar zijn en welk attributieprobleem elke route standaard verkeerd behandelt.

Waarom er geen native Facebook Ads-connector is

De catalogus van Looker Studio bestaat eigenlijk uit drie catalogi onder één dak. Google-connectors (Search Console, Analytics, Google Ads, Google Spreadsheets, BigQuery) komen van Google zelf en zijn gratis. Partnerconnectors zijn commerciële producten die andere bedrijven bouwen en verkopen, meestal per gegevensbron per maand gefactureerd. Communityconnectors heeft iemand gepubliceerd, en of die persoon ze nog onderhoudt, weet niemand.

Meta Ads zit in de tweede en derde groep, samen met TikTok, LinkedIn, Shopify en Stripe. Meta is in de advertentiemarkt een concurrent van Google; een gratis verbinding van Google zelf naar een rapportageproduct als Looker Studio was nooit een logische productbeslissing. De uitgebreide versie van dat argument staat in ons artikel over bronnen zonder Looker Studio-connector (Engelstalig).

De vier routes die er echt zijn

1. Een betaalde partnerconnector

Supermetrics, Windsor.ai, Catchr, Porter, Dataslayer en anderen verkopen precies dit. Je geeft toegang, kiest het advertentieaccount, en de Facebook-data verschijnen in de lijst met gegevensbronnen alsof ze native zijn. Dat is de snelste weg naar een werkend diagram, en voor één lastige bron waar je elke dag op stuurt de juiste keuze.

Wat het naast het abonnement kost: een leveranciersrelatie per bron, een OAuth-machtiging die verloopt en opnieuw bevestigd moet worden, een statuspagina die je controleert als het diagram leeg blijft, en prijsniveaus die vaak afhangen van het aantal advertentieaccounts – precies de maat waarmee een bureau groeit.

2. Een communityconnector

Gratis, in dezelfde galerie te vinden en de reden dat veel mensen denken dat het probleem opgelost is. Het addertje is echt: je geeft een onbekende derde een token voor je advertentieaccount, en niemand is verplicht de connector bij te werken als Meta een nieuwe, incompatibele versie van de Marketing API uitbrengt. Het foutbeeld is geen foutmelding, maar een dashboard dat de vorm van gisteren met de datum van vandaag blijft tonen en niets nieuws meer ophaalt.

3. Export uit Advertentiebeheer naar Google Spreadsheets

Ook gratis, werkt meteen en is stilletjes wat de meeste mensen echt doen. Advertentiebeheer exporteert een CSV-bestand, dat bestand gaat in een Google-spreadsheet, en Looker Studio leest de spreadsheet met een connector van Google. Na verloop van tijd brokkelt deze route op drie voorspelbare manieren af: elke update hangt ervan af dat iemand aan de nieuwe export denkt, elke kolomwijziging bij Meta breekt een formule drie tabbladen verderop, en het dashboard geeft geen enkel signaal dat de cijfers erachter elf dagen oud zijn.

4. Eerst in BigQuery laden

Het antwoord voor wie het „goed” wil doen, en op warehouse-schaal klopt dat ook. Alleen verplaatst het het probleem in plaats van het op te lossen: iets moet de Facebook-data nog steeds naar BigQuery schrijven, en dat is ofwel een ELT-leverancier die per connector factureert (de connectorbelasting, een laag dieper nog eens betaald), ofwel pipelinecode die nu van jou is en die je zelf debugt. Voor een marketingdataset met miljoenen in plaats van miljarden rijen is dat een paar maten te groot; waarom, staat in ons artikel over het kleinste marketing-datawarehouse dat echt werkt (Engelstalig).

Instagram Ads: dezelfde vier routes, één extra stap

Instagram Ads zijn Meta Ads, dus er is geen aparte Instagram Ads-connector die je moet zoeken. Ze worden in hetzelfde Advertentiebeheer ingekocht, via hetzelfde advertentieaccount gefactureerd en via dezelfde Marketing API gerapporteerd. Elke route die Facebook Ads ophaalt, haalt je Instagram Ads al mee, verwerkt in dezelfde campagnetotalen.

De extra stap is de uitsplitsing. Waar een advertentie liep, rapporteert Meta als uitsplitsing, niet als apart account: in Advertentiebeheer is dat het menu Uitsplitsing (Breakdown → By delivery → Platform in de Engelse interface), in de Marketing API de uitsplitsing publisher_platform, die Meta documenteert als het platform waarop de advertentie werd weergegeven: Facebook, Instagram of Audience Network (Meta's naslag over uitsplitsingen, Engelstalig). Een campagne-export zonder die uitsplitsing levert Facebook en Instagram samengeteld, en Looker Studio kan ze achteraf niet meer scheiden.

• Partnerconnector: neem de dimensie voor het platform (Publisher Platform) op in het diagram. Een connector die die dimensie niet aanbiedt, kan Instagram niet apart tonen.
• Export naar Google Spreadsheets: zet in Advertentiebeheer vóór de export de uitsplitsing op platform, dan bevat het CSV-bestand één rij per platform.
• TableBI: de live connector voor Meta Ads (bèta) synchroniseert op campagneniveau, dus uitgaven en resultaten van Instagram zitten zonder uitsplitsing per platform in de campagnetotalen. Een export uit Advertentiebeheer met de uitsplitsing op platform behoudt die kolom: TableBI zet elke CSV-kolom waarvoor het geen gedeelde definitie heeft in meta_ads_raw, waar je erop kunt groeperen.

Facebook Page Insights en openbare paginadata lopen via een andere leiding

Organische Facebook-data – bereik, volgers, berichten en interacties van een pagina – komen niet via een Facebook Ads-connector. Ze horen bij de pagina en niet bij het advertentieaccount, ze vragen een andere machtiging, en connectorleveranciers verkopen ze als aparte bron. Supermetrics bijvoorbeeld voert Facebook Insights voor pagina's die je beheert en Facebook Public Data voor openbare berichten van pagina's die je niet beheert als twee connectors, los van Facebook Ads.

„Facebook Public Data” is de smalste van de twee. Die bron is bedoeld om andere pagina's te vergelijken op wat ze publiceren, en volgens de documentatie van Supermetrics zelf zijn er data beschikbaar voor ongeveer 600 gerangschikte, gepubliceerde berichten per jaar, en bij reacties alleen die op het hoogste niveau (documentatie van Supermetrics, Engelstalig).

De gratis route werkt net als bij de advertenties: in Meta Business Suite downloadt Insights → Exporteren (Insights → Export) de inzichten van een pagina als CSV- of Excel-bestand (Facebook Helpcentrum), en een Google-spreadsheet met dat bestand leest Looker Studio in zoals elke andere spreadsheet. TableBI koppelt Page Insights niet: de Meta-connector van TableBI dekt alleen advertenties.

„Facebook Ads gratis verbinden met Looker Studio” – eerlijk beantwoord

Veel mensen komen met het woord gratis bij dit probleem, dus het verdient een duidelijk antwoord in plaats van een verkooptrechter. Twee van de vier routes kosten geen geld: de communityconnector en de export naar Google Spreadsheets. Beide zijn legitiem, en voor beide betaal je in een andere munt dan geld.

Bij de communityconnector betaal je met vertrouwen en kwetsbaarheid: een onbekende heeft een token voor je advertentieaccount, en niemand is je een reparatie verschuldigd als Meta van API-versie wisselt. Bij de route via Google Spreadsheets betaal je met aandacht: zo'n tien minuten per week, voorgoed, plus het risico dat iemand een budgetbeslissing neemt op basis van een verouderd tabblad. Bestaat je rapportage uit één advertentieaccount en één maandelijkse presentatie, dan is de route via Google Spreadsheets prima en kun je hier stoppen met lezen. Gaat het om meerdere accounts, elke week, voor mensen die op de cijfers handelen, dan zijn de gratis routes de dure.

Wat elke route standaard verkeerd doet

Deze fout overleeft alle vier de opties, dus hij verdient meer aandacht dan de keuze van de connector. Meta schrijft conversies toe aan een advertentie die tot 7 dagen eerder werd aangeklikt of 1 dag eerder werd gezien – de standaardvensters op Meta's pagina over attributie-instellingen (Engelstalig) – en kan die conversie rapporteren op de dag van de advertentie in plaats van de dag van de aankoop. Een aankoop van vandaag kan dus de cijfers van vorige dinsdag nog veranderen. Volgens Meta's eigen richtlijnen voor de Insights API (Engelstalig) veranderen de cijfers pas niet meer 28 dagen nadat ze zijn gerapporteerd.

Elke pipeline die alleen „gisteren” ophaalt en toevoegt, zit daardoor blijvend fout voor het recente verleden, en wel te laag, omdat de correcties meestal omhoog gaan. Het dashboard toont een zwakke week die zich stilletjes herstelde toen niemand meer keek. De oplossing: bij elke synchronisatie het recente venster opnieuw ophalen in plaats van één keer toe te voegen, en in het rapport aangeven welke dagen nog in beweging zijn. De meeste connectorinstellingen doen geen van beide, en niets in je Looker Studio-rapport waarschuwt je.

De vijfde route: helemaal zonder Looker Studio

De optie die niet in de lijst staat, omdat het geen item in een lijst is: bouw het rapport helemaal niet in Looker Studio. Geef dezelfde data aan een backend die ze omzet naar gedeelde, kanaaloverstijgende definities, en publiceer het dashboard vanaf daar. Je levert slepen-en-neerzetten in. In ruil ben je in één stap af van het prijsmodel per bron, het ververs-ritueel en de attributiedrift.

Dat is wat TableBI doet. De route die vandaag voor iedereen werkt, is de export: hetzelfde CSV-bestand dat je anders in een Google-spreadsheet had geplakt, bij het importeren voorzien van een label, zodat het in dezelfde tabellen terechtkomt als je andere kanalen:

# één keer installeren
npm i -g @tablebi/cli
tablebi login
tablebi install

# de export uit Advertentiebeheer, omgezet naar gedeelde definities
tablebi connect csv --file meta-ads-augustus.csv --platform meta_ads

# controleren wat er is binnengekomen en hoe het is gelezen
tablebi sources
tablebi sample

Het label --platform is geen cosmetisch metagegeven. Het zorgt ervoor dat deze rijen in dezelfde tabel facts staan als Google Ads en Search Console, zodat uitgaven uitgaven zijn en klikken klikken, in welk platformdialect ze ook binnenkwamen. Precies dat kan een connector per bron structureel niet: connectors leveren elk platform in zijn eigen vocabulaire en laten de afstemming over aan jou en een samenvoeging (blending) die liegt.

Er is ook een live connector via OAuth:

tablebi connect meta_ads
# één advertentieaccount: wordt meteen gesynchroniseerd
# meerdere: worden getoond; opnieuw uitvoeren met --account <id>

Meta Ads is in bèta. Onze Meta-app heeft de App Review van Meta nog niet doorlopen, dus op dit moment kunnen alleen mensen die als testgebruiker aan de app zijn toegevoegd hun advertentieaccounts machtigen. Geldt dat niet voor jou, dan werkt de CSV-route, en die komt in precies dezelfde tabellen terecht. Search Console, GA4 en Google Ads verbinden live, zonder die beperking. Stap je na geüploade exports over op de live connector, geef volgende CSV-bestanden uit Advertentiebeheer dan een eigen label, zoals meta_ads_csv: de CLI weigert een CSV die het label hergebruikt van een platform dat al live wordt gesynchroniseerd, omdat de rijen anders dubbel worden geteld.

Wat je kunt vragen zodra de data binnen zijn

Het hele punt van Facebook uit zijn eigen dashboard halen, is de vraag waarvoor je tot nu toe twee dashboards nodig had:

# ROAS over Meta en Google Ads: één query, één definitie van 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"

Twee dingen daarin zijn dragend. roas() en cpa() zijn definitiemacro's: de berekening gebeurt één keer in de backend in plaats van telkens opnieuw, en zo vermijd je de gemiddeldenfout die de meeste zelfgebouwde diagrammen met verhoudingen vertekent (de lange versie, Engelstalig). En het datumfilter gaat uit van MAX(date) in plaats van de kalender, vanwege het attributievenster: „vandaag” is nog geen afgesloten rij.

Voor forensische vragen ga je naar de ruwe laag, waar Meta's eigen velden onveranderd bewaard blijven:

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"

Elk antwoord bevat een trust-blok: de actualiteit per bron plus de voorbehouden die gelden, inclusief het venster waarin Meta nog corrigeert. Over de rapportageworkflow in plaats van de koppeling gaat Meta Ads-rapportage zonder spreadsheetgedoe, over het kanaaloverstijgende getal waar dit allemaal om draait blended ROAS (beide Engelstalig).

Vastpinnen als live URL

Is een weergave de moeite waard om te bewaren, pin hem dan vast. Opgeslagen wordt de query, geen momentopname, dus de URL ververst zichzelf zodra er nieuwe data zijn gesynchroniseerd:

tablebi pin --title "Betaalde kanalen — Meta + Google Ads" \
  --widget "Dagelijkse uitgaven::line=SELECT date, SUM(cost) AS spend FROM facts …" \
  --widget "ROAS per 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)

Een echt dashboard, precies zo vastgepind, met live data in plaats van een mock-up: