LaunchDarkly Metric Choose

Vous utilisez une compétence qui aide les utilisateurs à sélectionner les bonnes métriques avant de configurer une expérience, un déploiement gardienné ou une politique de version. Votre travail consiste à comprendre le contexte de la fonctionnalité, à identifier ce qui s'attachera automatiquement à partir des politiques existantes du projet, à inventorier ce qui est disponible et en bonne santé, et à produire une recommandation clairement typée.

Cette compétence est consultative. Elle ne crée pas de métriques, ne les attache pas à des expériences, ni ne configure les déploiements. Pour ces tâches, consulter les compétences connexes à la fin de ce document.

Prérequis

Cette compétence nécessite que le serveur MCP LaunchDarkly hébergé à distance soit configuré dans votre environnement.

Outils MCP obligatoires :

• list-metrics — inventorier les métriques disponibles avec leurs types et clés d'événement
• list-metric-events — vérifier quelles clés d'événement ont une activité récente

Outils MCP optionnels (améliorent le flux de travail) :

• list-release-policies — récupérer les politiques au niveau du projet qui configurent les métriques s'attachant automatiquement aux déploiements gardiennés. Utiliser cette option pour les chemins de déploiement gardienné et de politique de version.

Flux de travail

Étape 1 : Identifier le contexte

Poser deux questions dès le départ :

1. À quoi cela sert-il ?

   • (a) Expérience — tester une hypothèse avec une variante de flag
   • (b) Déploiement gardienné — déployer progressivement une modification avec détection automatique de régression
   • (c) Politique de version — créer ou modifier une politique au niveau du projet qui configure les métriques par défaut pour tous les déploiements gardiennés correspondant à certaines conditions

2. Quel est le changement ?

   • Clé du flag (le cas échéant)
   • Description en langage naturel : « Déploiement d'un nouveau flux de paiement » / « Test d'un nouvel algorithme de recommandation »

Étape 2 : Récupérer la configuration existante (déploiement gardienné et politique de version uniquement)

Pour les expériences — ignorer cette étape. Il n'y a pas de configuration préexistante à présenter.

Pour les déploiements gardiennés et le travail de politique de version, appeler d'abord list-release-policies :

list-release-policies(projectKey)

Présenter les résultats avant de faire des recommandations :

Votre projet compte 2 politiques de version :

Politique : « Production guardrails » (s'applique à : environment=production)
  S'attache automatiquement aux déploiements gardiennés :
    ✓ api-error-rate  (count, LowerThanBaseline)
    ✓ p95-latency     (value, LowerThanBaseline)
    ✓ [Metric group] Core Platform Health (3 métriques)

Politique : « Default » (s'applique à : tous les environnements)
  Aucune métrique configurée.

Cela indique à l'utilisateur ce qui est déjà couvert avant qu'il ne choisisse quoi que ce soit d'autre. Pour un déploiement gardienné, ces métriques apparaîtront automatiquement — la recommandation porte sur ce qu'il faut ajouter en plus, non pas reconstruire à partir de zéro.

Si aucune politique n'existe ou qu'aucune n'a de métriques configurées, noter que toutes les métriques doivent être sélectionnées manuellement.

Étape 3 : Inventorier les métriques disponibles avec santé des événements

Appeler list-metrics pour voir toutes les métriques du projet, puis vérifier les références croisées avec list-metric-events.

Organiser en deux groupes :

Afficher cet inventaire avant de recommander — il peut révéler qu'une métrique que l'utilisateur a en tête n'a pas d'événements circulant.

Étape 4 : Recommander

Le raisonnement diffère sensiblement selon le contexte.

(a) Expérience

Commencer par l'hypothèse, pas la liste des métriques.

Demander à l'utilisateur de compléter cette phrase avant de regarder les métriques disponibles :

« Si ce changement réussit, [métrique] va [augmenter / diminuer]. »

La métrique primaire doit mesurer directement cette hypothèse — pas un proxy, pas une corrélation. Si l'utilisateur ne peut pas compléter la phrase, l'aider à y arriver d'abord.

Proposer une seule métrique primaire. Elle doit :

• Mesurer directement l'hypothèse
• Avoir des événements circulant activement
• Avoir une direction de succès sans ambiguïté (HigherThanBaseline ou LowerThanBaseline)

Proposer des métriques secondaires typées. Suggérer au moins une de chaque type applicable :

Une de chaque type est généralement la bonne quantité. Plus de métriques secondaires ajoutent du bruit et une charge d'interprétation.

(b) Déploiement gardienné

Les déploiements gardiennés sont des mécanismes de sécurité, pas des expériences. Chaque métrique que vous ajoutez est un déclencheur potentiel de restauration automatique — si elle régresse au-delà de son seuil avant que le déploiement ne se termine, LaunchDarkly peut arrêter et annuler la version.

Commencer par ce qui s'attache automatiquement. Après avoir présenté les résultats de la politique de version à l'étape 2, demander : « Les métriques automatiquement attachées sont-elles suffisantes, ou voulez-vous en ajouter d'autres pour ce déploiement spécifique ? »

Lors de la recommandation de métriques supplémentaires :

• Favoriser la fiabilité — les métriques d'ingénierie (taux d'erreur, latence, taux de plantage) avec des bases de référence stables et prévisibles
• Éviter les métriques produit exploratoires qui sont bruyantes ou difficiles à interpréter sous analyse de régression
• Moins c'est mieux. Deux ou trois métriques à haut signal est la bonne taille. Plus de cinq crée un risque de faux positifs de restauration.
• Ne recommander que les métriques avec des événements circulant activement. Une métrique à risque dans un déploiement gardienné soit ne produit aucun signal, soit, pire, déclenche une restauration fausse en raison de problèmes de qualité des données, non d'une vraie régression.

Point de départ suggéré pour tout déploiement gardienné (s'il n'est pas déjà couvert par une politique) :

1. Taux d'erreur — voyons-nous plus d'erreurs dans la nouvelle variation ?
2. Latence / temps de réponse — la nouvelle variation est-elle plus lente ?
3. Une métrique spécifique au domaine liée à l'action utilisateur principale affectée par le changement

(c) Politique de version

Les politiques de version s'appliquent à tous les déploiements du projet correspondant à leurs conditions. C'est le seuil le plus élevé.

Commencer par l'état actuel. Après avoir présenté les politiques existantes à l'étape 2, demander : « Quelle politique modifiez-vous, ou voulez-vous en créer une nouvelle ? À quels environnements ou conditions de flag s'appliquera-t-elle ? »

Lors de la recommandation de métriques pour une politique :

• 2–3 métriques maximum. Plus que cela transforme la politique en fardeau sur chaque déploiement, y compris ceux où les métriques ne s'appliquent pas bien.
• Ne recommander que les métriques avec un historique d'événements long et stable. Si un événement circule de façon fiable depuis des mois, c'est un défaut par défaut sûr au niveau du projet. Les lacunes occasionnelles créeront des problèmes à grande échelle.
• Repousser les ajouts. Si l'utilisateur propose plus de 3, demander lesquels ils supprimeraient. La discipline du choix est le point.
• Expliquer les conditions de portée. Une politique limitée à environment=production s'applique uniquement aux déploiements de production. Aider l'utilisateur à réfléchir à s'il souhaite les mêmes métriques en staging (où les bases de référence peuvent différer) ou une politique séparée.

Les candidats politiques généralement solides : taux d'erreur, une métrique de conversion ou d'engagement essentielle, latence.

Étape 5 : Livrer la recommandation

Générer une liste claire et nommée. Être explicite sur ce que chaque métrique est destinée à faire et ce qui est déjà couvert :

Métriques recommandées pour : déploiement gardienné du nouveau flux de paiement (environnement : production)

AUTOMATIQUEMENT ATTACHÉES (à partir de la politique « Production guardrails ») :
  ✓ api-error-rate    (count, LowerThanBaseline)
  ✓ p95-latency       (value, LowerThanBaseline)

SUPPLÉMENTAIRES — recommandées pour ce déploiement :
  ✓ checkout-conversion  (occurrence, HigherThanBaseline)
    → Confirme que le déploiement ne dégrade pas la conversion principale que la fonctionnalité cible

⚠ page-load-time — pas d'événements récents. Instrumenter l'événement avant de l'inclure,
  ou le supprimer de la liste pour éviter un déclencheur de restauration fausse.

Puis conclure avec les prochaines étapes :

• Si une métrique dont l'utilisateur a besoin n'existe pas → utiliser la compétence metric-create
• Si un événement ne circule pas → utiliser la compétence metric-instrument
• Une fois la liste confirmée → configurer le déploiement gardienné ou l'expérience (via l'interface LaunchDarkly ou l'API)

Contexte important

• Les modifications de métrique en cours d'expérience nécessitent un redémarrage. LaunchDarkly capture la configuration des métriques au démarrage d'une expérience. Ajouter, supprimer ou modifier des métriques après le lancement nécessite d'arrêter l'expérience et de la redémarrer — les données historiques d'avant le changement ne sont pas comparables. Signaler ceci immédiatement si l'utilisateur mentionne qu'il est en cours d'expérience.
• Une métrique primaire sans événements est pire qu'aucune métrique primaire. L'expérience ne produit aucune sortie statistique. La santé des événements est une exigence matérielle pour la métrique primaire.
• CUPED et analyse de percentile sont incompatibles. Si l'expérience utilise la réduction de variance CUPED, les métriques basées sur les percentiles (p.ex. latence p95) se dégradent silencieusement en analyse basée sur la moyenne. Signaler ceci si l'utilisateur sélectionne une métrique de percentile dans une expérience CUPED activée.
• Les désajustements de type de contexte causent des données manquantes. Si l'événement de métrique est suivi avec un contexte device mais que l'expérience randomise sur user, l'événement ne sera pas attribué correctement. Confirmer que le type de contexte dans les appels track() correspond à l'unité de randomisation de l'expérience.
• Les métriques de politique de version doivent partager le même type de contexte. Toutes les métriques d'un déploiement gardienné avec politique de version doivent utiliser la même unité de randomisation. Si l'utilisateur propose des métriques avec des types de contexte désajustés, le signaler avant qu'il ne tente de configurer la politique.

Compétences connexes

• launchdarkly-metric-create — créer une métrique qui n'existe pas encore
• launchdarkly-metric-instrument — ajouter un appel track() pour que les événements commencent à circuler