Maintenir un flux de données publicitaires fiable sur plusieurs plateformes, versions d’API et régimes réglementaires implique un ensemble de défis d’ingénierie distincts, au-delà de l’extraction initiale.
Rate limits des API
Chaque plateforme applique des limites de débit différentes. Construire une logique de backoff qui les gère toutes nécessite une implémentation spécifique à chaque plateforme.
Meta utilise une fenêtre glissante d’une heure qui évolue avec le nombre d’annonces actives. Plus d’annonces signifie plus de budget API, mais la relation n’est pas linéaire et la formule exacte n’est pas entièrement documentée. Atteindre la limite entraîne un blocage jusqu’à ce que la fenêtre avance.
Google dispose de quotas par niveau de token développeur. L’accès Basic a des limites restrictives ; l’accès Standard les ouvre considérablement. Cette hiérarchisation signifie que le débit maximum de votre pipeline dépend de votre niveau d’accès à l’API.
Les limites de LinkedIn ne sont pas publiées. L’onglet Analytics du Developer Portal est le seul moyen de vérifier l’utilisation courante ; il n’existe aucun moyen programmatique de savoir à quelle distance vous êtes d’une limite avant de l’atteindre.
Chaque pipeline d’extraction nécessite un backoff exponentiel avec jitter, un suivi des rate limits par plateforme et des alertes quand on approche des limites. Les outils d’extraction managés gèrent cela ; les pipelines personnalisés doivent l’implémenter directement.
Changements de schéma
Les API publicitaires cassent régulièrement les pipelines, créant un coût de maintenance constant.
La refonte de l’attribution Meta de juin 2025 a modifié l’attribution des conversions hors-Meta. Les événements on-Meta sont désormais attribués au moment de l’impression ; les événements off-Meta sont attribués au moment de la conversion, sans opt-out possible. Tout pipeline comparant des conversions entre types d’événements a dû être mis à jour ; l’analyse historique qui enjambe la frontière de juin 2025 nécessite de tenir compte du changement de méthodologie.
La migration API Google de v14 à v16 (juin 2024) a renommé les colonnes de noms plats en préfixes metrics_* et segments_*. Les pipelines personnalisés avec des noms de colonnes codés en dur ont planté ; les pipelines managés par Fivetran ont été mis à jour automatiquement.
Si vous gérez des pipelines personnalisés, vous devez :
- Suivre les changelogs d’API pour chaque plateforme utilisée
- Planifier les migrations plusieurs mois à l’avance (tous les changements ne sont pas rétrocompatibles)
- Maintenir une logique d’extraction tenant compte des versions pour gérer les périodes de transition
- Tester les modifications du pipeline sur des données similaires à la production avant déploiement
Normalisation des fenêtres d’attribution
Comparer des « conversions » entre plateformes sans normaliser les fenêtres d’attribution revient à comparer des grandeurs différentes.
| Plateforme | Fenêtre clic par défaut | Fenêtre vue par défaut |
|---|---|---|
| Google Ads | 30 jours | Aucune (search) |
| Meta | 7 jours | 1 jour |
| 30 jours | 7 jours |
Une « conversion » Google Ads inclut les clics des 30 derniers jours. Une « conversion » Meta ne compte que les clics des 7 derniers jours. Comparer ces chiffres côte à côte sans normalisation est trompeur — Google semble générer plus de conversions en partie parce qu’il regarde sur une fenêtre plus longue.
La solution basée sur l’entrepôt consiste soit à :
- Normaliser toutes les plateformes sur la même fenêtre d’attribution (ex. : 7 jours clic uniquement) en réclamant les données avec des paramètres correspondants là où l’API le permet
- Utiliser votre propre modèle d’attribution construit à partir de données au niveau du clic, en contournant entièrement l’attribution des plateformes
- Utiliser le ROAS global (revenus totaux / dépenses totales) qui évite le désaccord d’attribution dans son ensemble
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 doit soit retraiter une fenêtre de lookback glissante, soit accepter que les données récentes sont provisoires.
Gestion des devises et des fuseaux horaires
La gestion des devises et des fuseaux horaires génère des écarts entre les totaux de l’entrepôt et les interfaces des plateformes si elle n’est pas traitée explicitement.
Google reporte les coûts en micros (millionièmes d’unité monétaire). Une valeur de coût de 1500000 signifie 1,50 $. Oublier la division par 1 000 000 fausse vos totaux de dépenses inter-plateformes de six ordres de grandeur. Cette normalisation appartient à la couche de base de votre projet dbt.
Meta utilise par défaut la devise du compte publicitaire. Si vous avez des comptes publicitaires dans plusieurs devises, le reporting inter-comptes exige une standardisation explicite des devises.
Les totaux journaliers diffèrent entre l’entrepôt et les interfaces des plateformes en raison de différences de pré-agrégation des fuseaux horaires. Les plateformes agrègent selon leur propre fuseau horaire (souvent celui du compte publicitaire), tandis que votre entrepôt stocke probablement tout en UTC. Une campagne qui dépense 100 $ entre 22h et 2h dans le fuseau horaire du compte publicitaire affichera cette dépense répartie sur deux jours différents en UTC. Il s’agit d’un défi bien documenté — le DECISIONLOG de dbt_ad_reporting de Fivetran en discute explicitement.
Tolérez un écart de 1 à 3 % entre vos totaux d’entrepôt et les totaux des interfaces des plateformes pour les écarts liés aux fuseaux horaires. Tout écart plus important signale un bug de pipeline.
Conformité vie privée
Construire des pipelines conformes est une obligation. Principaux développements réglementaires :
Huit nouvelles lois de confidentialité dans des États américains sont entrées en vigueur en 2025. Le règlement européen sur l’IA entre en application en août 2026. Google Consent Mode v2 est désormais une exigence standard pour tout site collectant des données auprès d’utilisateurs européens.
Le tracking côté serveur est devenu la réponse principale aux restrictions au niveau des navigateurs. 67 % des entreprises B2B ont déjà migré vers le tracking côté serveur, récupérant 20 à 40 % des données d’attribution perdues à cause des restrictions navigateur (bloqueurs de publicités, ITP, restrictions des cookies). Les entreprises implémentant le tracking côté serveur signalent une amélioration de 15 à 25 % des taux de conversion rapportés dès le premier trimestre.
Pour les data engineers, la conformité vie privée implique :
- S’assurer que les signaux de consentement se propagent dans votre pipeline (pas seulement collectés mais respectés lors de la transformation)
- Gérer les demandes de suppression de données qui doivent se propager dans les couches raw, intermédiaire et mart
- Auditer quelles données au niveau utilisateur votre pipeline stocke et pour combien de temps
- Comprendre que les données d’attribution reçues sont déjà filtrées par le consentement — vos chiffres d’entrepôt ne reflètent que les utilisateurs ayant consenti, pas l’activité totale
À mesure que les restrictions des navigateurs se resserrent et que les cookies tiers disparaissent, la collecte côté serveur devient la voie principale vers des données d’attribution précises, déplaçant la complexité d’implémentation du navigateur vers le serveur et des équipes marketing vers les équipes data engineering.