Gouvernance des métriques LookML : guide complet

📌 Série : réconciliation GA4 × SFCC, partie 4 sur 5

Cet article fait partie d’une série technique sur la réconciliation des données de commandes e-commerce entre Salesforce Commerce Cloud (SFCC) et Google Analytics 4 (GA4). Les parties 1 à 3 expliquent ce qu’est Looker, pourquoi GA4 et SFCC ne concordent jamais, et comment corriger la jointure sur le transaction ID. Cette partie traite de la gouvernance des métriques avec LookML. Le contexte ci-dessous permet de la lire seule.

Contexte : le problème que cet article résout

SFCC est une plateforme e-commerce d’entreprise qui enregistre chaque commande côté serveur : c’est le système de référence pour le revenu. GA4 suit le comportement côté navigateur via un tag JavaScript et déclenche un événement purchase : c’est le système de référence pour l’attribution digitale.

Ces deux systèmes ne s’accordent jamais sur le même chiffre. SFCC remonte en général plus de commandes que GA4, car certains achats n’atteignent jamais GA4 (consentement refusé, bloqueurs de publicité, page de confirmation non chargée, commandes hors ligne). L’ITP de Safari abîme surtout l’attribution : la commande est enregistrée, mais souvent comme un « nouveau » visiteur direct (WebKit Tracking Prevention). GA4 peut aussi surcompter : sa déduplication par transaction ID ne fonctionne que sur les flux web, pas sur les flux d’app (aide GA4). Dans les projets que j’ai audités, l’écart allait d’environ 10 % à 35 % des commandes web ; mesurez le vôtre avant de fixer une cible.

Figure 0 — SFCC et GA4 sont deux systèmes qui mesurent des réalités proches mais pas identiques. SFCC est la source de vérité du revenu, GA4 celle de l’attribution.

Les parties 1 à 3 ont traité la couche données (extraction dans BigQuery, normalisation des IDs, table reconciliation_base avec une ligne par commande SFCC enrichie de sa correspondance GA4). Cet article traite de la couche sémantique : définir vos métriques de façon cohérente, documentée et versionnée, sans risque de divergence entre dashboards. C’est ce que LookML résout.

Lundi matin, la directrice financière ouvre trois rapports de revenu côte à côte : trois chiffres différents pour le même trimestre, et personne ne sait lequel est le bon. Ce n’est pas un problème de données : la logique métier vit dans des dashboards individuels plutôt que dans un modèle partagé et gouverné.

La cause racine : la logique dans la mauvaise couche

Dans beaucoup d’outils de dashboard, les métriques sont définies au niveau du dashboard. Chaque analyste redéfinit ce dont il a besoin, copie une formule, l’ajuste un peu et oublie de noter ce qui a changé. Avec le temps : la même métrique a quinze définitions, un changement de règle métier oblige à traquer chaque dashboard, les nouveaux arrivants ne trouvent pas la version de référence, et les audits sont pénibles.

LookML déplace la logique métier de la couche dashboard vers la couche modèle. Une métrique est définie une fois, documentée en ligne, versionnée dans Git et consommée à l’identique par tous les dashboards et utilisateurs.

Figure 1 — Sans LookML, la logique métier est dispersée et diverge. Avec LookML, elle est centralisée, documentée et versionnée.

Dimensions et mesures : la distinction fondamentale

Chaque champ LookML est une dimension (attribut non agrégé, comme l’ID de commande, la date, le canal ou le statut, servant à regrouper, filtrer et segmenter) ou une mesure (agrégation : somme, comptage, moyenne, ratio, qui ne sert pas à regrouper). Looker n’autorise pas une mesure de type sum, average ou count à référencer une autre mesure, et quand vous déclarez clés primaires et relations de jointure, les agrégats symétriques évitent que les jointures comptent deux fois (agrégats symétriques).

view: sfcc_orders {
  sql_table_name: `project.reconciliation.norm_sfcc_orders` ;;
  dimension: order_id {
    type: string
    sql: ${TABLE}.norm_order_id ;;
    primary_key: yes
    hidden: yes
    description: "Normalised SFCC order ID. Used as join key."
  }
  dimension: order_size_tier {
    label: "Order Size Tier"
    type: string
    sql: CASE
      WHEN ${TABLE}.order_value < 50   THEN '1. Small (<€50)'
      WHEN ${TABLE}.order_value < 200  THEN '2. Medium (€50-200)'
      WHEN ${TABLE}.order_value < 1000 THEN '3. Large (€200-1000)'
      ELSE '4. Enterprise (>€1000)'
    END ;;
    description: "Prefix numbers ensure correct sort order in visualisations."
  }
  # ... dimension_group created, channel, order_status
}

Les mesures clés de la vue SFCC suivent ce modèle :

  measure: net_revenue {
    label: "Net Revenue (€)"
    type: sum
    sql: ${TABLE}.order_value - COALESCE(${TABLE}.refund_amount, 0) ;;
    description: "Gross revenue minus processed refunds. Does not include pending refunds."
    filters: [order_status: "-cancelled,-fraud,-test"]
  }
  measure: average_order_value {
    type: number
    sql: ${net_revenue} / NULLIF(${confirmed_order_count}, 0) ;;
  }

Le comptage des commandes confirmées (confirmed_order_count, qui exclut annulées, frauduleuses et de test), le revenu brut (gross_revenue) et le revenu web (web_revenue, filtré sur les canaux web,storefront) fonctionnent de la même façon.

Métriques multi-sources : GA4 et SFCC dans un seul modèle gouverné

Le vrai bénéfice de la gouvernance vient des métriques croisées, qui combinent GA4 et SFCC. Ce sont les plus souvent redéfinies dans les organisations sans couche de gouvernance. Sur la vue order_reconciliation (basée sur reconciliation_base), on définit d’abord deux dimensions : order_origin (tracked_web = session GA4 appariée, offline_store = POS, b2b_wholesale, dark_traffic_web = commande web sans correspondance GA4, unknown) et tracking_confidence (1. High, 2. Structural gap, 3. Fixable gap, 4. Unknown). Puis les mesures :

Mesure	Définition
`sfcc_net_revenue`	Revenu brut SFCC après remboursements traités
`ga4_reported_revenue`	Revenu tel que remonté par l’événement purchase de GA4
`revenue_delta`	`sfcc_net_revenue - ga4_reported_revenue` ; positif = SFCC remonte plus que GA4 (normal et attendu)
`revenue_delta_pct`	Écart divisé par `NULLIF(sfcc_net_revenue, 0)` ; cible interne sous 15 % pour les commandes web seules (fixée d’après notre base de référence)
`web_match_rate`	Commandes web avec session GA4 / commandes web ; cible interne au-dessus de 85 %
`tracked_revenue`	Revenu SFCC des commandes `tracked_web`
`fixable_gap_revenue`	Revenu des commandes `dark_traffic_web` : le coût financier des trous de tracking

Bonnes pratiques de gouvernance

1. Documentez chaque mesure avec une description qui répond à deux questions. Le champ description s’affiche en infobulle dans l’Explore : qu’inclut la métrique, et qu’exclut-elle explicitement ? « Revenu total » ne sert à rien ; « Revenu net des commandes web confirmées, après remboursements traités. Exclut les commandes annulées, frauduleuses et B2B » sert vraiment.

2. Versionnez chaque changement du modèle dans Git. Chaque modification est un commit, ce qui crée une piste d’audit complète : « pourquoi le revenu net a-t-il baissé de 8 % le 15 mars ? » devient une question résoluble. Exemple : le commit qui change net_revenue pour exclure les remboursements en attente (CASE WHEN ${TABLE}.refund_status = 'processed' THEN ${TABLE}.refund_amount END) est repris par tous les dashboards une fois en production (après rafraîchissement du cache).

3. Utilisez des libellés lisibles par les métiers. sfcc_orders.net_revenue est ambigu ; « Net Revenue (€), SFCC, post-remboursements » ne l’est pas. Pour les métriques de réconciliation, indiquez toujours le système source dans le libellé.

4. Masquez agressivement les champs techniques (clés de jointure, IDs intermédiaires, champs numériques bruts) avec hidden: yes : ils restent disponibles pour les calculs et les jointures sans encombrer le sélecteur de champs.

5. Appliquez les mêmes formats de valeur : decimal_2 pour les montants (12 345,67), decimal_0 pour les comptages, percent_1 pour les taux (87,4 %).

Le workflow de gouvernance complet

Un analyste construit un dashboard : il choisit SFCC Net Revenue et Revenue Gap % dans l’Explore. Définitions gouvernées, aucune formule à écrire.
La finance demande un changement de définition : une mise à jour de measure, une pull request, un déploiement. Tous les dashboards en profitent à leur prochaine requête (les résultats en cache expirent selon votre politique de datagroup ; voir déployer les changements), et c’est documenté dans Git pour toujours.
Un nouvel arrivant demande ce que veut dire « taux de dark traffic web » : il survole la métrique et lit la description.
Un audit exige la preuve du calcul du revenu : on partage l’historique des commits Git.
Un déploiement casse le tag : l’alerte Looker sur web_match_rate se déclenche dans Slack et l’incident est investigué le jour même.

La suite de la série

Partie 5 : dark traffic et commandes orphelines, avec le système de classification complet, les métriques à construire par-dessus et l’architecture du dashboard de réconciliation.

Sources

Pour aller plus loin, lisez la version complète de l’article (en anglais) : LookML Metric Governance: The Complete Guide to Defining, Enforcing, and Versioning Business Metrics.

Besoin d’aide sur ce sujet ? Consultant GA4 et audit analytics.

Gouvernance des métriques avec LookML : définir, imposer et versionner vos métriques métier