Les données LinkedIn Ads nécessitent un traitement explicite dans la couche intermédiaire avant de pouvoir rejoindre une couche de reporting cross-plateforme : la hiérarchie de campagnes inversée doit être renommée, les définitions de clics normalisées, et la fenêtre d’attribution de 90 jours requiert une stratégie incrémentale avec lookback.
Le renommage de la hiérarchie
La structure de campagnes de LinkedIn est inversée par rapport à Google Ads et Meta. Le “Campaign Group” de LinkedIn correspond à ce que les autres plateformes appellent une “Campaign”. La “Campaign” de LinkedIn correspond à un “Ad Group”. Le “Creative” de LinkedIn correspond à un “Ad”.
Tout modèle cross-plateforme qui UNION ALL les données LinkedIn aux côtés de Google et Meta nécessite une terminologie cohérente. Utiliser les noms natifs de LinkedIn dans la couche mart produit des résultats incompatibles lors des requêtes aux côtés d’autres plateformes.
Le renommage appartient à la couche intermédiaire — appliqué une seule fois, avant que tout modèle mart ou dashboard en aval touche les données :
-- models/intermediate/int_linkedin_ads__campaigns.sqlSELECT campaign_group_id AS campaign_id, campaign_group_name AS campaign_name, campaign_id AS ad_group_id, campaign_name AS ad_group_name, creative_id AS ad_idFROM {{ ref('base__linkedin_ads__ad_analytics') }}Choisissez une convention et engagez-vous. Le standard Google/Meta (Campaign → Ad Group → Ad) est le bon choix car il correspond à ce que la plupart des gens attendent, c’est ce qu’utilise le package Fivetran dbt_ad_reporting, et c’est ce que les parties prenantes ayant vu des dashboards Google Ads chercheront.
Documentez le renommage dans la description dbt de votre modèle. Les parties prenantes venant d’un background LinkedIn s’attendront à la terminologie native de LinkedIn ; elles doivent savoir que la traduction a eu lieu.
Normalisation des métriques
Cinq métriques composent la couche unifiée cross-plateforme : clics, impressions, dépenses, conversions et valeur_conversions. LinkedIn se mappe sur celles-ci, mais avec des décisions de traduction spécifiques :
Dépenses : LinkedIn rapporte costInLocalCurrency. Renommez en spend dans la couche intermédiaire. Si vous combinez plusieurs comptes publicitaires dans différentes devises, ajoutez une standardisation de devise explicite ici.
Clics : La métrique clicks brute de LinkedIn inclut les actions sociales — likes, partages, commentaires et abonnements. Cela gonfle le CTR de LinkedIn par rapport à Google et Meta, qui ne comptent que les clics naviguant l’utilisateur quelque part. Pour la comparabilité cross-plateforme, utilisez externalWebsiteClicks ou landingPageClicks au lieu du total clicks. Si votre outil d’extraction ne fournit pas ces champs plus étroits, documentez explicitement la divergence dans la description de votre modèle pour que les consommateurs en aval sachent que le CTR LinkedIn n’est pas directement comparable.
Conversions : Le package dbt_ad_reporting utilise par défaut external_website_conversions + one_click_leads comme métrique de conversions pour LinkedIn. C’est un défaut raisonnable pour les pipelines B2B où les conversions de sites web et les complétions de formulaires lead comptent comme pipeline. Si votre définition de conversion diffère — par exemple, si vous ne voulez compter qu’un seul type — personnalisez-la via la configuration de variables passthrough du package plutôt que d’override directement le modèle.
Impressions : LinkedIn utilise le standard de visibilité IAB (50 % des pixels visibles pendant au moins 1 seconde). Google compte toute annonce diffusée. Les chiffres ne sont pas directement comparables, mais il n’y a pas de normalisation que vous pouvez appliquer rétroactivement. Documentez-le dans la description du modèle. Voir ad-platform-metric-divergence pour le tableau complet des divergences cross-plateforme.
Le package dbt_ad_reporting
Le package dbt_ad_reporting de Fivetran gère LinkedIn parmi ses 11 plateformes. Si vous utilisez Fivetran pour l’extraction, le package s’appuie sur les tables staging de Fivetran et produit un modèle unifié ad_reporting__ad_report avec les cinq métriques standard.
Le package gère le renommage de la hiérarchie, le calcul des conversions et le UNION ALL entre plateformes. Ce qu’il ne gère pas, ce sont les modèles LinkedIn-spécifiques pour les données démographiques, les métriques sociales ou les métriques virales — ceux-ci appartiennent aux modèles mart spécifiques à la plateforme que vous construisez aux côtés de la couche unifiée.
Si vous utilisez un outil d’extraction différent (Airbyte, dlt ou un pipeline personnalisé), vous pouvez tout de même adopter le même pattern de modélisation que le package utilise. Les conventions structurelles — base, intermédiaire (avec le renommage de la hiérarchie et la normalisation des métriques), mart (unifié et spécifique à la plateforme) — valent la peine d’être suivies même si vous n’utilisez pas le code généré du package.
Stratégie incrémentale pour l’attribution de 90 jours
La fenêtre d’attribution de 90 jours de LinkedIn signifie que les données de conversion pour un jour donné continuent de se mettre à jour pendant trois mois. Une conversion attribuée à un clic du 10 janvier peut ne pas apparaître avant mars. Votre modèle incrémental doit re-traiter au moins les 90 derniers jours à chaque exécution pour capturer ces conversions tardives.
La bonne stratégie incrémentale pour les données de conversion LinkedIn est insert_overwrite avec partitionnement par date. Cela remplace atomiquement des partitions de dates entières à chaque exécution — pas de complexité de merge, pas de risque de doublons, juste un remplacement propre des jours concernés :
{{ config( materialized='incremental', partition_by={"field": "date_day", "data_type": "date"}, incremental_strategy='insert_overwrite') }}
{% set lookback_days = var('linkedin_lookback_days', 90) %}
SELECT date_day, campaign_group_id AS campaign_id, campaign_id AS ad_group_id, creative_id AS ad_id, impressions, external_website_clicks AS clicks, cost_in_local_currency AS spend, external_website_conversions + one_click_leads AS conversionsFROM {{ ref('base__linkedin_ads__ad_analytics') }}
{% if is_incremental() %}WHERE date_day >= DATE_SUB(CURRENT_DATE(), INTERVAL {{ lookback_days }} DAY){% endif %}Faites du lookback de 90 jours une variable dbt pour pouvoir l’ajuster sans changer le code du modèle. Certaines équipes utilisent 60 jours pour les exécutions quotidiennes et un full-refresh trimestriel pour capturer ce qui aurait pu passer à travers. La valeur correcte dépend de combien vos données de conversion LinkedIn changent réellement dans la queue de la fenêtre d’attribution — tirez une semaine de données de l’interface LinkedIn et comparez-les à ce que votre entrepôt montre pour la même période 30 et 60 jours plus tard pour calibrer.
Ce pattern est une application spécifique du late-arriving-data-lookback-window-pattern. Le cas LinkedIn est notable car la fenêtre est inhabituellement longue — trois mois est un lookback agressif comparé aux 7 jours de Meta ou à la fenêtre typique de 3 jours pour les données d’événements. Dimensionnez vos jobs de pipeline en conséquence.
Modèles spécifiques à la plateforme vs modèles unifiés
Les données démographiques professionnelles de LinkedIn — entreprise, titre de poste, niveau hiérarchique, fonction, industrie, taille d’entreprise — n’ont pas d’équivalent dans les pipelines Google ou Meta. Elles n’appartiennent pas au modèle cross-plateforme unifié, où elles seraient NULL pour chaque ligne non-LinkedIn.
Construisez des modèles mart LinkedIn-spécifiques séparés pour l’analyse démographique :
models/ marts/ advertising/ unified/ mart__ad_reporting.sql # UNION ALL across platforms platform/ linkedin/ mart__linkedin_ads__demographics.sql # seniority, company, job title mart__linkedin_ads__social.sql # likes, shares, viral metrics mart__linkedin_ads__video.sql # video engagement funnelLe modèle unifié sert aux comparaisons de dépenses et performances cross-plateforme. Les modèles spécifiques à la plateforme servent à la valeur B2B unique de LinkedIn — quels comptes cibles atteignez-vous, à quels niveaux hiérarchiques, avec quelle fréquence ? Voir linkedin-ads-b2b-data-value pour le cadrage analytique.
Sans Fivetran
Si vous construisez des modèles personnalisés sans les tables de base de Fivetran, suivez le même pattern en trois couches. La couche intermédiaire porte la responsabilité la plus lourde : renommage de la hiérarchie, normalisation des métriques (définitions des clics, dépenses, conversions), ajustements spécifiques à LinkedIn (documentation de la définition des clics, gestion de la fenêtre d’attribution). Les modèles mart doivent être légers en logique LinkedIn-spécifique — ils consomment des données intermédiaires propres et normalisées.
Les particularités de la couche d’extraction (linkedin-ads-analytics-endpoint) — segmenter les requêtes pour rester sous 15 000 éléments, gérer le query tunneling, diviser les requêtes pour plus de 20 métriques — sont des problèmes de couche d’extraction, pas de transformation. Résolvez-les avant que les données atteignent dbt.