ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Fenêtres d'attribution Meta Ads

Fonctionnement des fenêtres d'attribution de Meta, la séparation on-Meta/off-Meta de juin 2025, les fenêtres ayant survécu à la dépréciation de janvier 2026, et ce que cela signifie pour les données en entrepôt.

Planté
bigqueryanalyticsdata engineeringetl

Les fenêtres d’attribution définissent quelles conversions Meta attribue à quelles publicités. Deux changements survenus en 2025-2026 affectent les sorties des pipelines : la séparation de l’attribution on-Meta/off-Meta de juin 2025, et les dépréciations de fenêtres de janvier 2026. Les pipelines construits avant ces changements et non mis à jour produiront des chiffres incorrects dans l’entrepôt.

Fonctionnement des fenêtres d’attribution

Une fenêtre d’attribution définit la période suivant une interaction publicitaire durant laquelle Meta créditera une conversion à cette publicité. L’interaction peut être un clic (la personne a cliqué sur la publicité) ou une vue (la personne a vu la publicité sans cliquer).

Quand un événement de conversion se déclenche — un achat, la soumission d’un formulaire lead, l’installation d’une application — Meta regarde en arrière dans la fenêtre d’attribution et demande : « Cette personne a-t-elle interagi avec l’une de nos publicités ? » Si oui, cette conversion est créditée à la publicité.

Les tailles de fenêtre importent énormément car différentes durées capturent des volumes de conversion différents. Une fenêtre de 28 jours au clic capture chaque achat effectué dans les 28 jours suivant le clic sur une publicité. Une fenêtre de 7 jours au clic capture moins de conversions pour la même dépense publicitaire, faisant apparaître la version 28 jours comme plus efficace.

Les fenêtres ayant survécu à janvier 2026

Meta a déprécié les fenêtres d’attribution de vue de 7 jours et 28 jours le 12 janvier 2026. Les fenêtres d’attribution restantes :

FenêtreStatut
1d_clickActive
7d_clickActive
28d_clickActive
1d_engaged_viewActive
1d_viewActive
7d_viewDépréciée en janvier 2026
28d_viewDépréciée en janvier 2026

Si votre pipeline demandait 7d_view ou 28d_view avant la dépréciation, il a soit planté, soit silencieusement rebasculé vers les valeurs par défaut de Meta après le 12 janvier. Vérifiez vos logs d’extraction.

Les fenêtres survivantes offrent une couverture raisonnable pour la plupart des cas d’usage : 7d_click est le standard industriel pour la plupart des types de campagnes, 1d_view est utile pour les campagnes de notoriété haut de funnel, et 28d_click est utile pour les catégories à cycle d’achat long (B2B, achats à haute considération).

La séparation d’attribution de juin 2025

C’est le changement qui a surpris la plupart des pipelines. Meta attribue désormais les conversions différemment selon l’endroit où la conversion s’est produite :

  • Conversions on-Meta (soumissions de formulaires lead, conversations Messenger, interactions Instant Experience) → attribuées à l’heure d’impression
  • Conversions off-Meta (achats sur le site web via Pixel, installations d’app via SDK, événements Conversions API) → attribuées à l’heure de conversion

Il n’y a pas d’opt-out. La séparation est appliquée automatiquement.

Ce que cela signifie en pratique

Avant juin 2025, toutes les conversions étaient attribuées à l’heure d’impression. Un achat survenant un mardi attribué à un clic publicitaire du lundi apparaissait dans les données du lundi. Après juin 2025, ce même achat apparaît dans les données du mardi (heure de conversion) tandis qu’une soumission de formulaire lead apparaît toujours dans les données du lundi (heure d’impression).

Si votre pipeline compare des événements on-Meta et off-Meta dans le même graphique — en comparant les leads via formulaire aux achats sur le site pour la même campagne — ces chiffres utilisent désormais des horodatages d’attribution différents. Les mélanger dans une colonne agrégée « conversions » sans le documenter est une source de confusion pour quiconque tente de réconcilier l’entrepôt avec Ads Manager.

Gérer la séparation dans votre couche de transformation

Deux options :

Option 1 : les conserver séparément. N’agrégez pas les conversions on-Meta et off-Meta ensemble dans vos modèles intermédiaires. Créez des colonnes séparées et documentez la base d’attribution pour chacune.

-- Séparation claire dans le modèle intermédiaire
SELECT
date_start,
campaign_id,
-- Off-Meta : attribuées à l'heure de conversion
purchases AS off_meta_conversions,
purchase_value AS off_meta_conversion_value,
-- On-Meta : attribuées à l'heure d'impression
lead_form_leads AS on_meta_conversions
FROM {{ ref('int__meta_ads__actions_pivoted') }}

Option 2 : combiner avec documentation. Si votre mart nécessite une seule colonne conversions pour la comparaison cross-plateforme, documentez la base d’attribution mixte dans la description du modèle et acceptez que le chiffre soit une approximation.

Dans tous les cas, si vous analysez des données qui franchissent la frontière de juin 2025, traitez-la comme deux méthodologies de mesure différentes. Une courbe de tendance de janvier 2025 à décembre 2025 présente une rupture méthodologique au milieu qui ressemblera à un changement de performance même si rien n’a changé dans les campagnes.

Spécifier les fenêtres dans les appels API

C’est la configuration la plus souvent manquée : si vous ne spécifiez pas action_attribution_windows dans votre requête API, Meta utilise ses valeurs par défaut. Ces valeurs par défaut ne correspondent pas nécessairement à ce qu’Ads Manager affiche, ce qui est l’une des principales causes de divergences entre l’entrepôt et l’interface.

Spécifiez toujours les fenêtres explicitement :

params = {
'fields': 'impressions,clicks,spend,actions,action_values',
'action_attribution_windows': ['7d_click', '1d_view'],
'time_increment': 1,
'level': 'ad',
}

Les fenêtres que vous spécifiez déterminent quelles conversions apparaissent dans le tableau actions. Une publicité avec 7d_click peut afficher 15 achats ; la même publicité avec 28d_click peut en afficher 22. Les deux sont corrects — ils mesurent simplement des fenêtres différentes.

Alignez-vous avec Ads Manager en vérifiant quelles fenêtres votre équipe utilise dans l’interface Ads Manager et en les faisant correspondre dans vos appels API. Si Ads Manager affiche une attribution au clic sur 7 jours et que votre pipeline demande 28 jours au clic, les chiffres ne se réconcilieront jamais.

Mises à jour rétroactives des données et fenêtres de lookback

Les données d’attribution se mettent à jour rétroactivement. Un achat aujourd’hui peut être attribué à une impression publicitaire d’il y a 7 jours. Cela signifie que les données d’hier ne sont pas définitives — elles changeront à mesure que la fenêtre d’attribution se remplit.

La fenêtre de mise à jour varie selon le type de conversion :

  • La plupart des conversions standard : période de mise à jour de 3 à 7 jours
  • Conversions AEM (Aggregated Event Measurement) : jusqu’à 72 heures de délai supplémentaire avant même d’apparaître dans l’API
  • Événements off-Meta envoyés via Conversions API : délai supplémentaire selon le temps de traitement serveur

Pour un pipeline, cela signifie que vous ne pouvez traiter aucune donnée récente comme définitive. La défense standard est une fenêtre de lookback : à chaque synchronisation, re-tirez les 28 derniers jours et écrasez les chiffres périmés avec l’attribution mise à jour.

28 jours est conservateur. Pour la plupart des campagnes, 7 jours couvre la majorité des mises à jour rétroactives. Mais pour les implémentations Conversions API avec AEM, 28 jours est plus sûr car l’image d’attribution complète prend plus de temps à se stabiliser.

Les outils managés comme Fivetran gèrent cela automatiquement. Airbyte nécessite une configuration explicite de la fenêtre de lookback. Si vous construisez une extraction personnalisée, vous le gérez vous-même — et ce n’est pas trivial car vous devez décider d’écraser, de merger ou de suivre des snapshots historiques.

Divergences de données vs Ads Manager

Votre entrepôt ne correspondra jamais exactement à Ads Manager. Acceptez une petite variance et concentrez-vous sur la précision des tendances plutôt que sur la réconciliation exacte. Les principales sources de divergence légitime :

  1. Incompatibilité de fenêtre d’attribution — votre requête API et la vue Ads Manager utilisent des fenêtres différentes
  2. Différences de fuseau horaire — Ads Manager affiche les données dans le fuseau horaire du compte publicitaire ; votre entrepôt stocke probablement en UTC
  3. Délai de reporting — les données peuvent mettre 1 à 72 heures pour se finaliser
  4. Données modélisées vs réelles — après iOS 14.5, Meta utilise de plus en plus la modélisation statistique pour combler les lacunes d’attribution ; les chiffres modélisés se mettent à jour au fur et à mesure que davantage de signaux arrivent
  5. Déduplication CAPI — si vous envoyez des événements à la fois via le Pixel et via l’API Conversions sans valeurs event_id correspondantes, vous doublerez les conversions dans vos données brutes avant qu’elles soient dédupliquées par Meta

Le renommage Reach vers Viewers arrive également. Meta remplace la métrique « Reach » par « Viewers » d’ici fin juin 2026. Si vos tableaux de bord ou modèles dbt référencent le champ reach par nom, planifiez cette migration avant que le renommage ne prenne effet.

Une variance de 5 % ou moins entre l’entrepôt et Ads Manager est normale et ne vaut pas la peine d’être investiguée. Une variance de 15 %+ de façon constante indique un problème de configuration de pipeline — commencez par l’alignement des fenêtres d’attribution et descendez la liste.