Anslut Facebook Ads till Looker Studio: alla vägar och vad var och en kostar
Google har ingen egen Facebook Ads-koppling för Looker Studio, och det kommer inte heller att finnas någon. Du kan ändå ansluta Facebook Ads till Looker Studio, på fyra sätt: med en betald partnerkoppling, med en gratis communitykoppling, med en lika gratis export från Annonshanteraren (Ads Manager) till Google Kalkylark, eller med BigQuery som mellanstation. Om du i Looker Studio (sedan april 2026 åter Data Studio) har skrivit ”Facebook” under Skapa → Datakälla (Create → Data source) och bara hittat rutor från tredje part med en prissida bakom, var det inte din sökning som var fel: så här ser integrationen ut. Den här guiden visar vad varje väg kostar i pengar och underhåll, vilka av de ”gratis” alternativen som faktiskt håller och vilket attributionsproblem varje väg hanterar fel från början.
Varför det inte finns någon inbyggd Facebook Ads-koppling
Katalogen i Looker Studio är egentligen tre kataloger under samma tak. Googles kopplingar (Search Console, Analytics, Google Ads, Google Kalkylark, BigQuery) kommer från Google själv och är gratis. Partnerkopplingar är kommersiella produkter som andra företag bygger och säljer, oftast debiterade per datakälla och månad. Communitykopplingar har någon publicerat, och om de fortfarande underhålls vet ingen.
Meta Ads finns i den andra och tredje gruppen, tillsammans med TikTok, LinkedIn, Shopify och Stripe. Meta konkurrerar med Google på annonsmarknaden; en gratis ledning från Google själv in i en rapportprodukt som Looker Studio var aldrig ett rimligt produktbeslut. Den långa versionen av det resonemanget finns i vår artikel om källor utan koppling till Looker Studio (på engelska).
Den praktiska följden: så fort en källa kräver en partnerkoppling växer kostnaden inte längre med datamängden, utan med antalet källor. En rapport över fem kanaler kostar fem gånger så mycket att hålla vid liv som en rapport över en kanal, fast datan inte har blivit ett dugg större.
De fyra vägar som faktiskt finns
1. En betald partnerkoppling
Supermetrics, Windsor.ai, Catchr, Porter, Dataslayer med flera säljer precis detta. Du ger åtkomst, väljer annonskontot och Facebook-datan dyker upp i listan över datakällor som om den vore inbyggd. Det är den snabbaste vägen till ett fungerande diagram, och för en enda krånglig källa som du styr på varje dag är det rätt val.
Vad det kostar utöver abonnemanget: en leverantörsrelation per källa, en OAuth-behörighet som går ut och måste bekräftas igen, en statussida du kollar när diagrammet står tomt, och prisnivåer som ofta styrs av antalet annonskonton – alltså exakt det mått som en byrå växer med.
2. En communitykoppling
Gratis, listad i samma galleri och anledningen till att många tror att problemet är löst. Haken är verklig: du ger en okänd tredje part en token till ditt annonskonto, och ingen är skyldig att uppdatera kopplingen när Meta släpper en ny, inkompatibel version av Marketing API. Felet visar sig inte som ett felmeddelande, utan som en instrumentpanel som fortsätter att visa gårdagens form med dagens datum och inte längre hämtar något nytt.
3. Export från Annonshanteraren till Google Kalkylark
Också gratis, fungerar direkt och är i tysthet vad de flesta faktiskt gör. Annonshanteraren exporterar en CSV-fil, filen hamnar i ett Google-kalkylark och Looker Studio läser kalkylarket med en koppling från Google. Med tiden faller den här vägen sönder på tre förutsägbara sätt: varje uppdatering hänger på att någon kommer ihåg att exportera igen, varje kolumnändring hos Meta slår sönder en formel tre flikar bort, och instrumentpanelen ger inga som helst tecken på att siffrorna bakom den är elva dagar gamla.
4. Ladda in i BigQuery först
Svaret för den som vill göra det ”ordentligt”, och i datalagerskala stämmer det. Men det flyttar problemet i stället för att lösa det: något måste fortfarande skriva Facebook-datan till BigQuery, och det är antingen en ELT-leverantör som debiterar per koppling (kopplingsskatten, betald en gång till ett lager ner) eller pipelinekod som nu är din och som du själv felsöker. För ett marknadsföringsdataset med miljoner snarare än miljarder rader är det flera nummer för stort; varför står i vår artikel om det minsta datalager för marknadsföring som faktiskt fungerar (på engelska).
Instagram Ads: samma fyra vägar, ett extra steg
Instagram Ads är Meta Ads, så det finns ingen separat Instagram Ads-koppling att leta efter. De köps i samma Annonshanterare, faktureras via samma annonskonto och rapporteras via samma Marketing API. Varje väg som hämtar Facebook Ads hämtar redan dina Instagram Ads, inräknade i samma kampanjsummor.
Det extra steget är uppdelningen. Var en annons visades rapporterar Meta som en uppdelning, inte som ett eget konto: i Annonshanteraren är det menyn Uppdelning (Breakdown → By delivery → Platform i det engelska gränssnittet), i Marketing API uppdelningen publisher_platform, som Meta dokumenterar som plattformen där annonsen visades: Facebook, Instagram eller Audience Network (Metas referens för uppdelningar, på engelska). En kampanjexport utan den uppdelningen ger Facebook och Instagram hopslagna, och Looker Studio kan inte skilja dem åt i efterhand.
- Partnerkoppling: ta med dimensionen för plattform (Publisher Platform) i diagrammet. En koppling som inte erbjuder den kan inte visa Instagram separat.
- Export till Google Kalkylark: ställ in uppdelning per plattform i Annonshanteraren före exporten, så innehåller CSV-filen en rad per plattform.
- TableBI: livekopplingen för Meta Ads (beta) synkar på kampanjnivå, så Instagrams kostnader och resultat ingår i kampanjsummorna utan uppdelning per plattform. En export från Annonshanteraren med uppdelning per plattform behåller den kolumnen: TableBI lägger varje CSV-kolumn som saknar en gemensam definition i
meta_ads_raw, där du kan gruppera på den.
Facebook Page Insights och offentlig siddata går i en annan ledning
Organisk Facebook-data – räckvidd, följare, inlägg och interaktioner för en sida – kommer inte via någon Facebook Ads-koppling. Den hör till sidan och inte till annonskontot, den kräver en annan behörighet och kopplingsleverantörer säljer den som en egen källa. Supermetrics har till exempel Facebook Insights för sidor du hanterar och Facebook Public Data för offentliga inlägg från sidor du inte hanterar som två kopplingar, skilda från Facebook Ads.
”Facebook Public Data” är den smalare av de två. Den är tänkt för att jämföra andra sidor utifrån vad de publicerar, och enligt Supermetrics egen dokumentation finns data för ungefär 600 rankade, publicerade inlägg per år, och för kommentarer bara de på översta nivån (Supermetrics dokumentation, på engelska).
Den kostnadsfria vägen fungerar som för annonserna: i Meta Business Suite laddar Insights → Exportera (Insights → Export) ner en sidas statistik som CSV- eller Excel-fil (Facebooks hjälpcenter), och ett Google-kalkylark med den filen läser Looker Studio in som vilket kalkylark som helst. TableBI kopplar inte Page Insights: TableBI:s Meta-koppling täcker bara annonser.
”Anslut Facebook Ads till Looker Studio gratis” – ärligt besvarat
Många kommer till det här problemet med ordet gratis, så det förtjänar ett tydligt svar i stället för en säljtratt. Två av de fyra vägarna kostar inga pengar: communitykopplingen och exporten till Google Kalkylark. Båda är legitima, och för båda betalar du i en annan valuta än pengar.
Med communitykopplingen betalar du med förtroende och sårbarhet: en okänd person har en token till ditt annonskonto, och ingen är skyldig dig en lagning när Meta byter API-version. Med vägen via Google Kalkylark betalar du med uppmärksamhet: ungefär tio minuter i veckan, för alltid, plus risken att någon fattar ett budgetbeslut på en inaktuell flik. Består din rapportering av ett annonskonto och en månadspresentation är vägen via Google Kalkylark helt i sin ordning, och du kan sluta läsa här. Gäller det flera konton, varje vecka, för människor som agerar på siffrorna, är gratisvägarna de dyra.
Vad varje väg gör fel från början
Det här felet överlever alla fyra alternativen, så det förtjänar mer uppmärksamhet än valet av koppling. Meta tillskriver en konvertering till en annons som klickades upp till 7 dagar tidigare eller visades 1 dag tidigare – standardfönstren på Metas sida om attributionsinställningar (på engelska) – och kan rapportera konverteringen på annonsens dag i stället för köpets. Ett köp i dag kan alltså fortfarande ändra förra tisdagens siffror. Enligt Metas egna riktlinjer för Insights API (på engelska) slutar siffrorna ändras först 28 dagar efter att de rapporterats.
Varje pipeline som bara hämtar ”i går” och lägger till blir därför permanent fel för det senaste förflutna, och för lågt, eftersom korrigeringarna oftast går uppåt. Instrumentpanelen visar en svag vecka som i tysthet repade sig när ingen längre tittade. Lösningen: hämta om det senaste fönstret vid varje synk i stället för att lägga till en gång, och låt rapporten visa vilka dagar som fortfarande rör sig. De flesta kopplingsuppsättningar gör varken det ena eller det andra, och ingenting i din Looker Studio-rapport varnar dig.
Den femte vägen: helt utan Looker Studio
Alternativet som inte finns i listan, eftersom det inte är en post i en lista: bygg inte rapporten i Looker Studio över huvud taget. Ge samma data till en backend som översätter den till gemensamma definitioner över kanalerna, och publicera instrumentpanelen därifrån. Du ger upp dra-och-släpp. I gengäld blir du av med prismodellen per källa, uppdateringsritualen och attributionsdriften i ett enda steg.
Det är vad TableBI gör. Vägen som fungerar för alla i dag är exporten: samma CSV-fil som du annars hade klistrat in i ett Google-kalkylark, märkt vid importen så att den hamnar i samma tabeller som dina andra kanaler:
# installera en gång npm i -g @tablebi/cli tablebi login tablebi install # exporten från Annonshanteraren, översatt till gemensamma definitioner tablebi connect csv --file meta-ads-augusti.csv --platform meta_ads # kontrollera vad som kom in och hur det tolkades tablebi sources tablebi sample
Etiketten --platform är ingen kosmetisk metadata. Den gör att raderna hamnar i samma tabell facts som Google Ads och Search Console, så att kostnad är kostnad och klick är klick, oavsett vilken plattformsdialekt de kom på. Just det kan en koppling per källa av princip inte ge dig: kopplingar levererar varje plattform med sitt eget ordförråd och lämnar avstämningen åt dig och en sammanslagning (blending) som ljuger.
Det finns också en livekoppling via OAuth:
tablebi connect meta_ads # ett annonskonto: synkas direkt # flera: listas; kör igen med --account <id>
Meta Ads är i beta. Vår Meta-app har ännu inte gått igenom Metas App Review, så i dag kan bara personer som lagts till i appen som testanvändare ge behörighet till sina annonskonton. Gäller det inte dig fungerar CSV-vägen, och den hamnar i exakt samma tabeller. Search Console, GA4 och Google Ads ansluts live utan den begränsningen. Byter du till livekopplingen efter uppladdade exporter, ge kommande CSV-filer från Annonshanteraren en egen etikett, till exempel meta_ads_csv: CLI:t vägrar en CSV som återanvänder etiketten för en plattform som redan synkas live, eftersom raderna annars räknas dubbelt.
Vad du kan fråga när datan väl är inne
Hela poängen med att få ut Facebook ur sin egen instrumentpanel är frågan som tidigare krävde två instrumentpaneler:
# ROAS över Meta och Google Ads: en fråga, en definition av 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"
Två saker i den bär tyngden. roas() och cpa() är definitionsmakron: beräkningen görs en gång i backend i stället för att härledas på nytt varje gång, och så undviker du medelvärdesfelet som förvränger de flesta hembyggda diagram med kvoter (den långa versionen, på engelska). Och datumfiltret utgår från MAX(date) i stället för kalendern, på grund av attributionsfönstret: ”i dag” är ännu ingen avslutad rad.
För detaljfrågor går du till rådatanivån, där Metas egna fält finns kvar oförändrade:
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"
Varje svar innehåller ett trust-block: aktualiteten per källa plus de förbehåll som gäller, inklusive fönstret där Meta fortfarande korrigerar. Om rapporteringsflödet snarare än anslutningen handlar Meta Ads-rapportering utan kalkylarksslit, om det kanalövergripande talet som allt detta finns till för blended ROAS (båda på engelska).
Fäst som en live-URL
När en vy är värd att behålla fäster du den. Det som sparas är frågan, inte en ögonblicksbild, så URL:en uppdaterar sig själv när ny data synkas:
tablebi pin --title "Betalda kanaler — Meta + Google Ads" \ --widget "Daglig kostnad::line=SELECT date, SUM(cost) AS spend FROM facts …" \ --widget "ROAS per plattform=SELECT platform, roas(SUM(conversion_value), SUM(cost)) AS roas FROM facts …" ✓ published → https://dk.tablebi.com/d/dsh_… (public, read-only, self-refreshing)
En riktig instrumentpanel, fäst på exakt det här sättet, med livedata i stället för en skiss: