Types de métriques MetricFlow

MetricFlow supporte cinq types de métriques. Chacun sert un objectif spécifique, et choisir le bon type détermine si le calcul agrège correctement lors du regroupement par une dimension. Les types sont : simple, cumulative, dérivée, ratio et conversion — chacun documenté ci-dessous, avec les conditions pour lesquelles il faut l’utiliser.

Métriques simples

Les métriques simples référencent une seule mesure avec une agrégation. Elles sont le bloc de construction de tout le reste.

metrics:
  - name: order_total
    label: "Total Order Value"
    description: "Sum of all order values"
    type: simple
    type_params:
      measure: order_value

La mesure order_value définit déjà son agrégation (probablement sum), donc la métrique la référence simplement. Aucun calcul supplémentaire ne se produit au niveau de la métrique.

Utilisez les métriques simples pour les comptages et sommes directs : revenu total, nombre de commandes, utilisateurs actifs. Si la métrique est « agréger une colonne d’une façon », simple est le bon type.

On peut également appliquer des filtres pour réduire la portée sans modifier la mesure sous-jacente :

metrics:
  - name: enterprise_revenue
    type: simple
    type_params:
      measure: revenue
    filter:
      - "{{ Dimension('customer__segment') }} = 'enterprise'"

C’est préférable à l’encodage des filtres dans la mesure elle-même, car la même mesure de base peut servir plusieurs métriques filtrées.

Métriques cumulatives

Les métriques cumulatives agrègent sur des fenêtres temporelles. Pensez aux utilisateurs actifs hebdomadaires, aux revenus du mois en cours, ou aux moyennes glissantes sur 30 jours.

metrics:
  - name: weekly_active_users
    label: "Weekly Active Users"
    description: "Unique users active in the past 7 days"
    type: cumulative
    type_params:
      measure: active_users
      window: 7 days

Deux paramètres contrôlent le comportement :

• window crée une fenêtre glissante (7 jours, 30 jours). La métrique regarde en arrière depuis chaque point de données.
• grain_to_date se réinitialise aux limites de période (month-to-date, year-to-date). L’accumulation redémarre au début de chaque période.

metrics:
  - name: mtd_revenue
    label: "Month-to-Date Revenue"
    type: cumulative
    type_params:
      measure: revenue
      grain_to_date: month

Une exigence surprend souvent : les requêtes utilisant des métriques cumulatives avec un paramètre window doivent inclure metric_time comme dimension. Sans dimension temporelle, la fenêtre glissante n’a pas de point d’ancrage. MetricFlow rejettera la requête plutôt que de calculer silencieusement quelque chose de dépourvu de sens.

Métriques dérivées

Les métriques dérivées effectuent des calculs en utilisant d’autres métriques. Elles sont essentielles pour les marges bénéficiaires, les taux de croissance et les comparaisons période-sur-période.

metrics:
  - name: gross_profit
    label: "Gross Profit"
    type: derived
    type_params:
      expr: revenue - cost_of_goods_sold
      metrics:
        - name: revenue
        - name: cost_of_goods_sold

Le paramètre expr accepte toute expression SQL valide utilisant les noms de métriques référencés. C’est là que l’on compose les métriques en calculs d’ordre supérieur.

Pour les calculs période-sur-période, utilisez offset_window avec un alias :

metrics:
  - name: revenue_growth_wow
    label: "Revenue Growth % W/W"
    type: derived
    type_params:
      expr: (revenue - revenue_last_week) / revenue_last_week * 100
      metrics:
        - name: revenue
        - name: revenue
          offset_window: 7 days
          alias: revenue_last_week

L’alias permet de référencer la même métrique à différents décalages temporels dans une seule expression. Sans lui, il n’y aurait aucun moyen de distinguer « revenu maintenant » de « revenu il y a 7 jours ».

Métriques ratio

Les métriques ratio divisent un numérateur par un dénominateur. On pourrait se demander pourquoi ne pas utiliser une métrique dérivée pour cela. La réponse est un piège mathématique : la somme des ratios n’est pas le ratio des sommes.

Si le Magasin A a un taux de conversion de 50% et le Magasin B de 25%, le taux combiné n’est pas 37,5%. Cela dépend du volume dans chaque magasin. Les métriques ratio gèrent cela correctement en additionnant le numérateur et le dénominateur séparément avant de diviser.

metrics:
  - name: conversion_rate
    label: "Conversion Rate"
    type: ratio
    type_params:
      numerator: conversions
      denominator: sessions

On peut appliquer des filtres uniquement au numérateur ou au dénominateur, ce qui est puissant pour les taux spécifiques à un segment :

metrics:
  - name: mobile_conversion_rate
    label: "Mobile Conversion Rate"
    type: ratio
    type_params:
      numerator:
        name: conversions
        filter:
          - "{{ Dimension('session__device_type') }} = 'mobile'"
      denominator: sessions

La règle empirique : si la métrique est « X divisé par Y » et doit s’agréger correctement par dimensions, utilisez une métrique ratio. Si on utilise une métrique dérivée à la place, on risque l’erreur de somme-des-ratios qui produira silencieusement des chiffres incorrects dans toute requête groupée.

Métriques de conversion

Les métriques de conversion suivent quand un événement de base mène à un événement de conversion dans une fenêtre temporelle. C’est l’analyse d’entonnoir : visites vers achats, inscriptions vers activations.

metrics:
  - name: visit_to_purchase_rate
    label: "Visit to Purchase Rate"
    type: conversion
    type_params:
      entity: user
      calculation: conversion_rate
      base_measure: visits
      conversion_measure: purchases
      window: 7 days

Le paramètre entity définit la clé de jointure reliant les événements de base et de conversion. Le paramètre calculation peut être conversion_rate (pourcentage) ou conversions (compte).

Pour une correspondance plus stricte, constant_properties garantit que les attributs correspondent entre les événements :

type_params:
  entity: user
  calculation: conversion_rate
  base_measure: visits
  conversion_measure: purchases
  window: 7 days
  constant_properties:
    - base_property: "{{ Dimension('visit__device_type') }}"
      conversion_property: "{{ Dimension('purchase__device_type') }}"

Cela comptabilise une conversion uniquement si le type d’appareil de l’utilisateur correspond entre la visite et l’achat. Sans constant_properties, un utilisateur qui navigue sur mobile mais achète sur desktop serait quand même compté comme une conversion. Que ce soit correct dépend de ce que l’on mesure.

Choisir le bon type

L’arbre de décision est simple :

1. Une mesure, une agrégation ? Métrique simple.
2. Agrégation sur une fenêtre glissante ou se réinitialisant ? Métrique cumulative.
3. Calcul combinant d’autres métriques ? Métrique dérivée.
4. X divisé par Y, nécessite une agrégation correcte par groupes ? Métrique ratio.
5. Événement A suivi de l’événement B dans une fenêtre ? Métrique de conversion.

En cas de doute entre dérivée et ratio, demandez : « Cette métrique sera-t-elle groupée par une dimension ? » Si oui, et si la métrique est une division, utilisez ratio. L’exactitude mathématique n’est pas optionnelle.