Connecter Facebook Ads à Looker Studio : toutes les solutions et ce que chacune coûte

Il n’existe pas de connecteur Facebook Ads conçu par Google, et il n’y en aura jamais. Si vous avez ouvert le sélecteur de sources de données de Looker Studio (renommé Data Studio par Google en avril 2026), tapé « Facebook » et obtenu une grille de connecteurs tiers renvoyant chacun vers une page de tarifs, votre recherche n’a pas échoué : c’est l’état réel de l’intégration. Ce guide détaille les quatre solutions qui existent vraiment (connecteur partenaire payant, connecteur de la communauté, export vers Google Sheets, BigQuery), ce que chacune coûte en argent et en maintenance, lesquelles des options « gratuites » le sont réellement, et le problème d’attribution que toutes gèrent mal par défaut.

Pourquoi il n’y a pas de connecteur Facebook Ads natif

Le catalogue de Looker Studio, ce sont en réalité trois catalogues sous une même vitrine. Les connecteurs Google (Search Console, Analytics, Google Ads, Sheets, BigQuery) sont conçus par Google et gratuits. Les connecteurs partenaires sont des produits commerciaux développés et vendus par d’autres entreprises, généralement facturés par source de données et par mois. Les connecteurs de la communauté ont été publiés par quelqu’un qui les maintient peut-être encore, ou peut-être plus.

Meta Ads se range dans les deuxième et troisième groupes, aux côtés de TikTok, LinkedIn, Shopify et Stripe. Meta est un concurrent de Google sur la publicité : un tuyau gratuit et officiel vers un outil de reporting de Google n’a jamais été une décision produit plausible. Nous avons développé cet argument dans pas de connecteur Looker Studio pour votre source (en anglais).

Les quatre solutions qui existent vraiment

1. Un connecteur partenaire payant

Supermetrics, Windsor.ai, Catchr, Porter, Dataslayer et d’autres en vendent un. Vous autorisez l’accès, choisissez le compte publicitaire, et les données Facebook apparaissent dans le sélecteur comme si elles étaient natives. C’est le chemin le plus rapide vers un graphique qui fonctionne, et pour une source récalcitrante qui compte au quotidien, c’est le bon choix.

Ce que ça coûte en plus de l’abonnement : un fournisseur de plus par source, une autorisation OAuth qui expire et qu’il faut renouveler, une page de statut à consulter quand le graphique se vide, et des paliers tarifaires souvent indexés sur le nombre de comptes publicitaires, c’est-à-dire exactement l’axe sur lequel une agence grandit.

2. Un connecteur de la communauté

Gratuit, présent dans la même galerie, et c’est pour ça que beaucoup croient le problème réglé. Le compromis est pourtant réel : vous confiez à un tiers inconnu un jeton d’accès à votre compte publicitaire, et personne n’est tenu de mettre le connecteur à jour quand Meta publie une version de l’API Marketing qui casse la compatibilité. La panne ne se manifeste pas par un message d’erreur : c’est un tableau de bord qui continue d’afficher la structure d’hier avec la date du jour, sans plus rien renvoyer de neuf.

3. Exporter depuis le Gestionnaire de publicités vers Google Sheets

Gratuit lui aussi, opérationnel dès aujourd’hui, et discrètement ce que la plupart des gens font vraiment. Le Gestionnaire de publicités exporte un CSV, le CSV atterrit dans une feuille Google Sheets, et Looker Studio lit cette feuille via un connecteur conçu par Google. Le montage se dégrade de trois façons prévisibles : chaque actualisation dépend de quelqu’un qui pense à refaire l’export, chaque changement de colonne côté Meta casse une formule enfouie trois onglets plus loin, et le tableau de bord ne signale jamais que les chiffres qu’il affiche datent de onze jours.

4. Passer d’abord par BigQuery

La réponse « faisons les choses proprement », et réellement la bonne à l’échelle d’un entrepôt de données. Mais elle déplace le problème au lieu de le supprimer : il faut toujours que quelque chose écrive les données Facebook dans BigQuery, et ce quelque chose est soit un fournisseur ELT facturé par connecteur (la taxe au connecteur, rachetée un étage plus bas), soit du code de pipeline que vous possédez désormais et que vous déboguez vous-même. Pour un jeu de données marketing qui se compte en millions de lignes et non en milliards, c’est plusieurs tailles trop grand ; nous défendons ce point dans le plus petit entrepôt de données marketing qui fonctionne vraiment (en anglais).

Instagram Ads : les quatre mêmes solutions, avec une étape en plus

Les publicités Instagram sont des publicités Meta : il n’existe donc pas de connecteur Instagram Ads distinct à chercher. Elles s’achètent dans le même Gestionnaire de publicités, sont facturées sur le même compte publicitaire et remontent par la même API Marketing. Toute solution qui récupère Facebook Ads récupère déjà vos publicités Instagram, additionnées dans les mêmes totaux de campagne.

L’étape en plus, c’est la séparation. Meta présente l’endroit où une publicité a été diffusée comme une ventilation (une « répartition », dans le vocabulaire de Meta), et non comme un compte séparé : dans le Gestionnaire de publicités, c’est Répartition → Par diffusion → Plateforme (Breakdown → By delivery → Platform dans l’interface en anglais), et dans l’API Marketing, c’est la ventilation publisher_platform, que Meta définit comme la plateforme sur laquelle la publicité a été affichée : Facebook, Instagram ou Audience Network (référence des ventilations de Meta, en anglais). Une extraction au niveau campagne sans cette ventilation vous donne Facebook et Instagram additionnés, et Looker Studio n’a ensuite aucun moyen de les séparer.

• Connecteur partenaire : ajoutez la dimension plateforme (publisher platform) au graphique. Un connecteur qui ne l’expose pas ne peut pas isoler Instagram.
• Export vers Google Sheets : exportez depuis le Gestionnaire de publicités après avoir activé la répartition Plateforme, pour que le CSV contienne une ligne par plateforme.
• TableBI : le connecteur Meta Ads en direct (beta) synchronise au niveau campagne, si bien que les dépenses et résultats Instagram restent inclus dans les totaux de campagne, sans ventilation par plateforme. Un export du Gestionnaire de publicités avec la répartition Plateforme conserve cette colonne : TableBI stocke dans meta_ads_raw chaque colonne du CSV qui n’a pas de définition commune, et vous pouvez y regrouper les lignes selon cette colonne.

Facebook Page Insights et données publiques des Pages : un autre tuyau

Les données organiques de Facebook (couverture, abonnés, publications et interactions d’une Page) ne passent par aucun connecteur Facebook Ads. Elles appartiennent à la Page et non au compte publicitaire, elles dépendent d’une autre autorisation, et les éditeurs de connecteurs les vendent comme une source à part. Supermetrics, par exemple, propose Facebook Insights pour les Pages que vous gérez et Facebook Public Data pour les publications publiques des Pages que vous ne gérez pas : deux connecteurs distincts de Facebook Ads.

Les « données publiques Facebook » sont la plus étroite des deux sources. Elles servent à benchmarker d’autres Pages à partir de ce qu’elles publient, et la documentation de Supermetrics indique que les données sont disponibles pour environ 600 publications classées et publiées par an, avec uniquement les commentaires de premier niveau (documentation Supermetrics, en anglais).

La solution gratuite est le pendant de celle des publicités : dans Meta Business Suite, le bouton Exporter de la section Statistiques (Export et Insights dans l’interface en anglais) télécharge sous forme de fichier les statistiques que vous consultez (pages d’aide Facebook), et une feuille Google Sheets contenant ce fichier se lit dans Looker Studio comme n’importe quelle autre feuille. TableBI ne connecte pas Page Insights : son connecteur Meta ne couvre que les publicités.

« Connecter Facebook Ads à Looker Studio gratuitement » : la réponse honnête

Beaucoup de gens arrivent sur ce problème avec le mot gratuit en tête : il mérite une réponse franche plutôt qu’un tunnel de vente. Deux des quatre solutions ne coûtent rien en argent : le connecteur de la communauté et l’export CSV importé dans Google Sheets. Les deux sont légitimes, et les deux se paient dans une autre monnaie que l’argent.

Le connecteur de la communauté se paie en confiance et en fragilité : un inconnu détient un jeton d’accès à votre compte publicitaire, et personne ne vous doit de correctif quand la version de l’API change. La solution Google Sheets (export manuel) se paie en attention : une dizaine de minutes par semaine, indéfiniment, plus le risque que quelqu’un tranche un budget à partir d’un onglet périmé. Si votre reporting se résume à un seul compte et à une présentation mensuelle, la solution Google Sheets convient vraiment et vous pouvez arrêter votre lecture ici. Si ce sont plusieurs comptes, chaque semaine, pour des gens qui agissent sur les chiffres, ce sont les solutions gratuites qui coûtent cher.

Ce que toutes les solutions font mal par défaut

C’est le défaut qui survit aux quatre options, et il mérite plus d’attention que le choix du connecteur lui-même. Meta réattribue les conversions sur une fenêtre glissante d’environ sept jours. Une conversion qui a lieu aujourd’hui peut être créditée à une impression d’il y a cinq jours : les chiffres de mardi dernier bougent donc encore ce mardi.

Tout pipeline qui récupère « hier seulement » puis ajoute les lignes à la suite reste donc faux en permanence sur le passé récent, et ses chiffres sont sous-évalués, puisque les révisions se font généralement à la hausse : le tableau de bord montre une semaine molle qui s’est discrètement raffermie quand plus personne ne regardait. La solution consiste à recharger toute la fenêtre glissante à chaque synchronisation au lieu d’ajouter les lignes une fois pour toutes, et à indiquer dans le rapport quels jours sont encore en cours de consolidation. La plupart des configurations de connecteurs ne font ni l’un ni l’autre, et rien dans le canevas de Looker Studio ne vous le signalera.

La cinquième solution : se passer du canevas

L’option absente du sélecteur, parce que ce n’est pas une entrée du sélecteur : ne pas construire le rapport dans Looker Studio du tout. Confiez les mêmes données à un backend qui les normalise selon des définitions communes à tous les canaux, et publiez le tableau de bord depuis ce backend. Vous renoncez au glisser-déposer. En échange, vous sortez d’un seul coup de la tarification par source, du rituel des actualisations et de la dérive d’attribution.

C’est ce que fait TableBI. La solution qui fonctionne aujourd’hui pour tout le monde, c’est l’export : le même CSV que vous auriez collé dans une feuille Google Sheets, étiqueté à l’import pour atterrir dans les mêmes tables que vos autres canaux :

# à installer une seule fois
npm i -g @tablebi/cli
tablebi login
tablebi install

# l’export du Gestionnaire de publicités, normalisé selon des définitions communes
tablebi connect csv --file meta-ads-august.csv --platform meta_ads

# vérifier ce qui a été chargé et comment c’est interprété
tablebi sources
tablebi sample

L’étiquette --platform n’est pas une métadonnée cosmétique. C’est elle qui permet à ces lignes de rejoindre la même table facts que Google Ads et Search Console : une dépense reste une dépense et un clic reste un clic, quel que soit le dialecte de la plateforme d’origine. C’est précisément ce qu’un connecteur par source ne peut structurellement pas offrir : chaque connecteur livre sa plateforme dans son propre vocabulaire et vous laisse la réconciliation, avec une configuration de combinaison qui ment.

Il existe aussi un connecteur OAuth en direct :

tablebi connect meta_ads
tablebi sync meta_ads

Meta Ads est en beta. Notre application Meta n’a pas encore passé l’examen App Review de Meta : aujourd’hui, elle n’autorise que les comptes publicitaires qui vous appartiennent ou qui ont été ajoutés comme utilisateurs test. Si ce n’est pas votre cas, c’est l’import CSV qui fonctionne, et il alimente exactement les mêmes tables. Search Console, GA4 et Google Ads se connectent en direct, sans cette restriction.

Ce que vous pouvez demander une fois les données chargées

L’intérêt de sortir Facebook de son propre tableau de bord, c’est la question qui exigeait jusqu’ici deux tableaux de bord :

# ROAS sur Meta et Google Ads, une seule requête, une seule définition du 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"

Deux détails portent tout le poids. roas() et cpa() sont des macros de définition : le calcul est fait une seule fois, dans le backend, au lieu d’être refait dans chaque graphique, ce qui évite le bug de moyenne qui fausse la plupart des graphiques de ratios construits à la main (la version longue, en anglais). Et le filtre de date s’ancre sur MAX(date) plutôt que sur le calendrier, à cause de la fenêtre de réattribution de Meta : « aujourd’hui » n’est pas une ligne consolidée.

Les questions d’investigation descendent plutôt au niveau brut, où les champs d’origine de Meta restent intacts :

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"

Chaque réponse arrive avec un bloc de confiance (trust block) : la fraîcheur de chaque source et les mises en garde qui s’appliquent, dont la fenêtre glissante de réattribution. Pour le workflow de reporting plutôt que la connexion, voir le reporting Meta Ads sans corvée de tableur (en anglais) ; pour le chiffre que tout cela sert à produire, le ROAS global (blended ROAS) (en anglais).

L’épingler sur une URL en direct

Quand une vue mérite d’être conservée, épinglez-la. Ce qui est enregistré, c’est la requête et non une capture figée, si bien que l’URL se met à jour d’elle-même au fil des synchronisations :

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)

En voici un vrai, épinglé exactement de cette façon, avec des données réelles et non une maquette :