Chaque plateforme publicitaire possède une conception d’API, un modèle d’authentification et un ensemble de pièges d’ingénierie qui lui sont propres. Cette note couvre les caractéristiques pertinentes pour l’extraction de données : structure des données, authentification et modes de défaillance connus.
Google Ads
Google Ads possède l’écosystème le plus mature. L’API (v18+) utilise GAQL (Google Ads Query Language) pour les requêtes — une syntaxe similaire à SQL permettant de demander des champs spécifiques et de filtrer les résultats de façon déclarative. La documentation est exhaustive et le support communautaire est large.
Le principal piège d’ingénierie : les coûts sont reportés en micros. Il faut diviser par 1 000 000 pour obtenir les valeurs monétaires réelles. Rater cette conversion et vos tableaux de bord afficheront des dépenses un million de fois trop élevées.
Google Ads est la seule grande plateforme proposant une intégration BigQuery native via le Data Transfer Service. Elle est gratuite, s’exécute quotidiennement et produit un schéma fixe dans votre projet BigQuery. La limitation : granularité journalière uniquement, et les campagnes Performance Max ont des lacunes documentées dans le reporting au niveau des annonces. Si vous avez besoin de données plus fraîches ou de ventilations Performance Max plus granulaires, vous devrez utiliser l’API directement.
Les campagnes Performance Max ne supportent que le reporting au niveau de la campagne, laissant des lacunes dans l’analyse au niveau des annonces et des groupes d’annonces. PMax est de plus en plus le type de campagne par défaut vers lequel Google oriente les annonceurs.
Meta Ads
Meta utilise la Marketing API avec des versions trimestrielles et un cycle de dépréciation d’environ 2 ans. Des travaux de migration réguliers sont nécessaires.
Le principal défi d’ingénierie est le tableau JSON imbriqué actions. Les conversions ne reviennent pas sous forme de colonnes plates. On obtient des structures comme :
[ {"action_type": "link_click", "value": "150"}, {"action_type": "offsite_conversion.fb_pixel_purchase", "value": "12"}]Aplatir cela en colonnes interrogeables est la tâche de transformation centrale pour les données Meta. Chaque type d’action qui vous intéresse doit être extrait du tableau et pivoté dans sa propre colonne. C’est là que la couche intermédiaire d’un projet dbt démontre son intérêt.
Le changement d’attribution Meta de juin 2025 a scindé le modèle d’attribution : les événements on-Meta (comme les leads générés via des formulaires) sont attribués au moment de l’impression, tandis que les événements off-Meta (comme les achats sur votre site) sont attribués au moment de la conversion. Il n’y a pas d’opt-out. Cela signifie qu’une même campagne peut afficher des comptages de conversions différents selon les types d’événements analysés, et que la comparaison de données avant/après juin 2025 requiert une attention particulière.
Les données d’attribution de Meta se mettent également à jour de façon rétroactive sur des fenêtres de 3 à 7 jours. Les chiffres d’hier changeront demain. Tout pipeline qui prend des snapshots de totaux journaliers doit tenir compte de cette fenêtre de retraitement.
LinkedIn Ads
LinkedIn a l’accès API le plus difficile de toutes les grandes plateformes. La revue manuelle des candidatures développeur peut prendre de plusieurs semaines à plusieurs mois. Les candidatures refusées ne peuvent pas se représenter avec la même application développeur.
La convention de nommage est inversée par rapport à toutes les autres plateformes : une « Campaign » LinkedIn correspond à ce que les autres appellent un « Ad Group », et le « Campaign Group » de LinkedIn correspond à ce que les autres appellent une « Campaign ». Ce décalage de nommage crée de la confusion dans le reporting inter-plateformes si vous ne remapez pas les termes dans votre couche de transformation.
L’authentification est également problématique. Les tokens OAuth expirent après 60 jours. Les tokens de rafraîchissement expirent après 365 jours. Après cela, l’utilisateur doit se ré-authentifier de façon interactive — il n’existe pas de pattern de compte de service à longue durée de vie. Construisez un monitoring autour des dates d’expiration des tokens.
Les rate limits sont non publiés. L’onglet Analytics du Developer Portal est le seul moyen de vérifier l’utilisation courante ; il n’existe aucun moyen programmatique de connaître la distance à la limite avant de l’atteindre.
Microsoft/Bing Ads
Microsoft Advertising utilise une API à protocole SOAP nécessitant à la fois un token développeur et une authentification OAuth. SOAP est un protocole legacy ; les outils sont moins pratiques que les API REST et le débogage est plus complexe. L’écosystème et le support communautaire sont moins développés que Google ou Meta. La qualité des données et les capacités de reporting sont solides une fois connecté.
TikTok Ads
La Marketing API de TikTok est en cours de maturation mais présente moins de stabilité que Google ou Meta. Les breaking changes sont plus fréquents et la documentation est moins exhaustive. Les capacités de chevauchement d’audience et le reporting au niveau des créatifs s’améliorent. La plateforme évolue assez vite pour que les hypothèses d’API d’un trimestre ne tiennent pas forcément le suivant.
Pinterest Ads
Pinterest supporte une API de conversions pour le tracking côté serveur. L’API de reporting couvre les métriques standard au niveau des campagnes, groupes d’annonces et annonces. La base d’annonceurs plus petite signifie moins d’outillage communautaire et moins de connecteurs préconstruits que Google ou Meta.
Twitter/X Ads
La roadmap de l’API publicitaire n’est pas bien communiquée et la fiabilité est incertaine. Les équipes dépendant programmatiquement des données publicitaires Twitter/X devraient maintenir des plans de contingence pour les changements d’API ou les restrictions d’accès.
Considérations inter-plateformes
La diversité entre ces plateformes — différents modèles d’authentification, structures de données, comportements de rate limit et méthodologies d’attribution — explique l’existence des outils d’extraction managés. Construire des pipelines personnalisés pour plusieurs plateformes simultanément représente un investissement d’ingénierie significatif. Chaque plateforme supplémentaire augmente la surface exposée aux modes de défaillance et à la maintenance des pipelines.