0Pricing
Digital Marketing Academy · Leçon

Modéliser les données marketing

Des tables nettoyées et reliées.

Modéliser les données marketing est une leçon Digital Marketing Academy gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Digital Marketing Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Digital Marketing Academy comprend 4 leçons au total.

Pourquoi modéliser ?

Les tables brutes des connecteurs sont désordonnées : noms de colonnes incohérents, monnaies mélangées, granularités différentes et particularités propres à chaque plateforme. Les interroger directement produit des chiffres erronés et impossibles à reproduire.

La modélisation des données consiste à transformer des lignes brutes en tables propres, cohérentes et prêtes pour l'activité. C'est là que le ROAS, la conversion et le chiffre d'affaires sont définis une seule fois, correctement, afin que tous les rapports concordent.

Schéma en étoile

Le modèle analytique dominant est le schéma en étoile : une table de faits centrale contenant les événements mesurables, entourée de tables de dimensions qui les décrivent. Les faits contiennent les chiffres, comme les dépenses, les clics et le chiffre d'affaires ; les dimensions fournissent le contexte, comme la campagne, la date, le canal et le client.

Cette structure est intuitive pour les professionnels du marketing et efficace pour les outils BI, qui relient un fait à plusieurs dimensions afin d'analyser les indicateurs selon n'importe quel attribut.

        dim_date
           |
dim_channel -- fct_ad_spend -- dim_campaign
           |
        dim_account

fct_ad_spend (facts): impressions, clicks, cost, conversions
dims: who / what / when context

Faits ou dimensions

Une table de faits est longue et additive : elle contient une ligne par événement ou par couple jour-campagne, avec des mesures numériques que vous additionnez. Une table de dimensions est large et descriptive : elle contient une ligne par campagne ou par client, avec des attributs selon lesquels vous filtrez et regroupez les données.

La règle est la suivante : si vous utiliseriez SUM pour l'agréger, c'est un fait ; si vous utiliseriez GROUP BY pour le regrouper, c'est une dimension. Les dépenses sont un fait ; le nom de la campagne est une dimension.

fct_ad_spend         dim_campaign
----------------     ----------------
date                 campaign_id (PK)
campaign_id (FK)     campaign_name
cost      <-SUM->     channel
clicks    <-SUM->     objective
conversions          start_date

Granularité : première décision

La granularité indique ce que représente une ligne d'une table de faits. La déclarer en premier est la décision de modélisation la plus importante. Mélanger les granularités, par exemple des lignes quotidiennes avec des totaux sur la durée, entraîne des doubles comptages et fausse chaque indicateur en aval.

Énoncez la granularité en termes simples : une ligne par campagne et par jour. Chaque colonne doit alors être vraie à cette granularité et chaque chargement doit la respecter.

Declared grain: one row per campaign per day

-- enforce uniqueness on the grain
SELECT date, campaign_id, COUNT(*)
FROM fct_ad_spend
GROUP BY 1,2
HAVING COUNT(*) > 1;   -- must return 0 rows

Modèles de préparation

Avant les faits et les dimensions, créez des modèles de préparation : un par table source, en renommant les colonnes selon une norme, en convertissant les types et en uniformisant les unités, par exemple des centimes en dollars et les dates en UTC. Un modèle de préparation correspond à une seule table brute, rien de plus.

La préparation est la couche de nettoyage. Elle isole les particularités des sources afin que vos magasins de données en aval n'aient jamais besoin de savoir que Meta parle de dépenses et Google de coût.

-- stg_google_ads__spend
SELECT
  date AS spend_date,
  campaign_id,
  'google' AS channel,
  cost_micros / 1000000 AS cost,   -- micros -> dollars
  clicks,
  conversions
FROM raw.google_ads__campaign_stats;

Unification des canaux

Chaque plateforme publicitaire produit ses rapports différemment, mais après la préparation, elles partagent une structure commune. Le modèle suivant les réunit en une seule table de faits des dépenses intercanal, fondement des rapports combinés.

C'est cette table unique qui rend le ROAS total possible. Comme chaque canal utilise les mêmes colonnes, une seule requête additionne simultanément les dépenses de Google, Meta et TikTok.

-- fct_ad_spend: union all channels
SELECT * FROM stg_google_ads__spend
UNION ALL
SELECT * FROM stg_meta_ads__spend
UNION ALL
SELECT * FROM stg_tiktok_ads__spend;

-- now: SUM(cost) GROUP BY channel works

Dimensions conformes

Pour l'analyse intercanal, les dimensions doivent être conformes : une dimension de date partagée, dim_date, et une dimension de canal partagée, dim_channel, auxquelles chaque fait se joint de la même manière. Ainsi, « chiffre d'affaires par mois et par canal » signifie la même chose, que la source soit la publicité, le courriel ou le Web.

Les dimensions conformes permettent de placer les dépenses et le chiffre d'affaires côte à côte dans un même graphique. Sans elles, les jointures s'alignent mal et les totaux divergent discrètement.

Conformed dims shared across facts:
dim_date     -> joined by every fact on date
dim_channel  -> 'google','meta','email','organic'
dim_campaign -> unified campaign keys

-> spend and revenue line up on the same axes

Attribution en SQL

L'attribution répartit le mérite d'une conversion entre les points de contact. Le dernier clic est le modèle le plus simple : la dernière source marketing avant la conversion reçoit tout le mérite. Le premier clic, le modèle linéaire et le modèle fondé sur la position répartissent le mérite différemment.

Dans un entrepôt, vous mettez en œuvre l'attribution sous forme de modèle, et non comme une boîte noire de plateforme. Avec les données d'événements de GA4, vous pouvez regrouper les points de contact par utilisateur à l'aide de fonctions de fenêtre et appliquer n'importe quelle règle, puis comparer honnêtement les résultats des différents modèles.

-- last non-direct click per conversion
WITH touches AS (
  SELECT user_id, channel, event_time,
    ROW_NUMBER() OVER (PARTITION BY user_id
      ORDER BY event_time DESC) AS rn
  FROM web_touchpoints
  WHERE channel <> 'direct'
)
SELECT channel, COUNT(*) FROM touches WHERE rn=1
GROUP BY 1;

Dimensions à évolution lente

Les attributs d'une dimension évoluent avec le temps : le responsable du budget d'une campagne change et le niveau d'un client augmente. Une dimension à évolution lente de type 2 conserve l'historique en ajoutant une nouvelle ligne avec des dates de validité au lieu d'écraser l'ancienne.

C'est essentiel pour obtenir des rapports exacts à un instant donné. Pour savoir dans quel segment se trouvait un client lorsqu'il a effectué une conversion, vous avez besoin de la version de la dimension qui était alors valide, et non de celle d'aujourd'hui.

dim_customer (SCD Type 2)
cust_id  tier      valid_from   valid_to     is_current
101      free      2026-01-01   2026-04-01   false
101      pro       2026-04-01   9999-12-31   true

-- join on event_date BETWEEN valid_from AND valid_to

Vérifications et documentation

Les modèles sont du code : vérifiez-les. Des outils comme dbt vous permettent de vérifier que les clés sont uniques et non nulles, que les valeurs de canal appartiennent à un ensemble autorisé et que les relations entre les tables sont respectées.

Les vérifications détectent la dérive du schéma et les mauvaises jointures avant qu'elles n'atteignent un tableau de bord. Associées à une documentation et à une traçabilité générées automatiquement, elles rendent le modèle fiable et facile à prendre en main, plutôt que de le laisser devenir une boîte noire fragile.

# dbt schema test
models:
  - name: fct_ad_spend
    columns:
      - name: campaign_id
        tests: [not_null]
      - name: channel
        tests:
          - accepted_values:
              values: ['google','meta','tiktok']

Magasins de données : couche finale

La couche supérieure est constituée de magasins de données métier : des tables prêtes pour l'activité et structurées pour des publics précis, comme la table métier marketing_performance, qui relie déjà les dépenses au chiffre d'affaires et calcule le ROAS par canal et par jour.

Les outils BI ne lisent que ces tables métier. En y préparant les jointures et les agrégations, les tableaux de bord restent rapides et peu coûteux, et chaque analyste bénéficie des mêmes définitions correctes.

-- marts.marketing_performance (1 row / day / channel)
SELECT s.spend_date, s.channel,
  SUM(s.cost)               AS spend,
  SUM(r.revenue)            AS revenue,
  SAFE_DIVIDE(SUM(r.revenue), SUM(s.cost)) AS roas
FROM fct_ad_spend s
LEFT JOIN fct_revenue r USING (spend_date, channel)
GROUP BY 1,2;

Vérification rapide

Vous construisez une table de faits pour les performances publicitaires et devez éviter les doubles comptages. Quelle est la chose la plus importante à déclarer avant d'écrire la moindre colonne ?

Récapitulatif

La modélisation transforme des tables brutes désordonnées en données fiables et prêtes à l'emploi pour l'entreprise grâce à plusieurs couches : la zone de préparation nettoie et harmonise chaque source, les tables de faits et les dimensions conformes forment un schéma en étoile, et les tables analytiques pré-assemblent toutes les données pour la BI.

Déclarez d'abord la granularité, regroupez les canaux pour obtenir des indicateurs combinés, implémentez l'attribution et l'historique SCD de type 2 dans les requêtes, puis testez chaque modèle afin que les chiffres erronés signalent clairement une erreur au lieu d'atteindre un tableau de bord.

Questions Fréquemment Posées

La leçon « Modéliser les données marketing » est-elle gratuite ?

Oui — le texte complet de « Modéliser les données marketing » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Digital Marketing Academy, passe à CoddyKit PRO. Le cours Digital Marketing Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Modéliser les données marketing » ?

Des tables nettoyées et reliées. Tu pratiques Digital Marketing Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Digital Marketing Academy ?

Aucune expérience préalable n'est requise. Digital Marketing Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Modéliser les données marketing » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Digital Marketing Academy ?

Oui. Chaque leçon Digital Marketing Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Pourquoi utiliser un entrepôt de données
  2. ETL et connecteurs
  3. Modéliser les données marketing
  4. Des tableaux de bord qui incitent à agir
← Retour à Digital Marketing Academy