Instrument de métrique LaunchDarkly

Vous utilisez une skill qui vous guidera pour ajouter un appel track() à une codebase afin qu'une métrique LaunchDarkly puisse la mesurer. Votre travail consiste à détecter le SDK utilisé, trouver le bon endroit dans le code pour ajouter l'appel, l'écrire correctement et vérifier que les événements atteignent LaunchDarkly.

Prérequis

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

Outils MCP requis :

• list-metric-events — vérifier que les événements circulent après instrumentation

Outils MCP optionnels (améliorent le workflow) :

• get-project — récupérer la clé SDK pour le bon environnement quand l'initialisation du SDK est nécessaire

Workflow

Étape 1 : Détecter le SDK

Avant d'écrire du code, comprenez la configuration LaunchDarkly déjà présente dans cette codebase.

1. Recherchez les appels track() existants. C'est le signal le plus rapide :

   • Cherchez ldClient.track(, .track(, ld.track(
   • S'il en existe, ils vous indiquent le type de SDK, la signature d'appel et le motif de contexte en un coup d'œil — reproduisez-les exactement.

2. Recherchez les imports et l'initialisation du SDK s'il n'existe pas d'appels track() :

   • Vérifiez package.json, requirements.txt, go.mod, Gemfile, *.csproj pour une dépendance SDK LD
   • Cherchez LDClient, ldclient, launchdarkly-server-sdk, launchdarkly-node-server-sdk, launchdarkly-react-client-sdk, etc.
   • Trouvez le bloc d'initialisation pour comprendre comment le client est accessible dans toute la codebase

3. Déterminez si c'est client-side ou server-side. C'est la distinction la plus critique — elle détermine la signature de track() :

   Type de SDK	Signature de track()	Remarques
   Server-side (Node, Python, Go, Java, Ruby, .NET)	ldClient.track(eventKey, context, data?, metricValue?)	Contexte requis par appel
   Client-side (React, navigateur JS)	ldClient.track(eventKey, data?, metricValue?)	Contexte défini à l'init, pas par appel

   Voir SDK Track Patterns pour des exemples complets par langage.

Étape 2 : Installer et initialiser (si le SDK n'est pas présent)

Ignorez cette étape si le SDK est déjà dans la codebase.

1. Détectez le gestionnaire de paquets à partir des lockfiles : package-lock.json / yarn.lock / pnpm-lock.yaml → npm/yarn/pnpm ; Pipfile.lock / poetry.lock → pip/poetry ; go.sum → go modules ; Gemfile.lock → bundler.

2. Installez le SDK approprié en utilisant le gestionnaire de paquets détecté. Voir SDK Track Patterns pour le bon nom de paquet par langage.

3. Récupérez la clé SDK en utilisant get-project — récupérez le projet et choisissez la clé pour l'environnement que l'utilisateur souhaite instrumenter (généralement production ou staging pour les tests initiaux).

4. Ajoutez l'initialisation du SDK en suivant les motifs déjà présents dans cette codebase. S'il existe une couche de configuration ou de service centrale, ajoutez le client LD là-bas. Voir SDK Track Patterns pour des exemples d'initialisation.

Étape 3 : Trouver le bon emplacement

Localisez l'endroit dans le code où l'action utilisateur ou l'événement se produit.

1. Demandez si vous n'êtes pas sûr de l'endroit où l'action se produit. Ne devinez pas le placement — un appel track() au mauvais endroit (par exemple une méthode de rendu au lieu d'un gestionnaire de soumission) produit des données trompeuses.

2. Cherchez des signaux du bon endroit :

   • Soumissions de formulaires, gestionnaires de clics de bouton, complétions de routes API, hooks de mutation
   • Appels analytics existants (segment.track(), mixpanel.track(), gtag()) — ceux-ci se situent souvent au même endroit où les appels LD track devraient aller
   • Commentaires comme // TODO: track this

3. Montrez l'emplacement candidat à l'utilisateur avant d'écrire quoi que ce soit :

   J'ajouterai l'appel track() ici, dans le gestionnaire de soumission de checkout (src/checkout/CheckoutForm.tsx, ligne 47).
   Est-ce que cela vous semble correct ?

4. Procédez une fois confirmé (ou si vous êtes suffisamment confiant à partir des signaux de la codebase).

Étape 4 : Écrire l'appel track()

Écrivez l'appel en suivant les motifs trouvés à l'étape 1.

SDKs server-side — le contexte est requis :

ldClient.track('checkout-completed', context);

SDKs client-side — le contexte est implicite :

ldClient.track('checkout-completed');

Pour les métriques value — incluez metricValue avec la mesure numérique :

// Server-side : métrique de latence (ms)
ldClient.track('api-response-time', context, null, responseTimeMs);

// Client-side : métrique de revenu
ldClient.track('purchase-completed', { orderId }, purchaseAmountUSD);

Règles clés :

• Correspondez au contexte existant. Ne construisez pas un nouveau contexte en ligne. Trouvez l'endroit où la codebase construit déjà son contexte/objet utilisateur (utilisé pour les appels variation()) et utilisez le même. C'est ainsi que LD fait correspondre l'événement au bon participant de l'expérience.
• metricValue uniquement pour les métriques value. Pour les métriques count et occurrence, omettez entièrement metricValue.
• Respectez les motifs wrapper. Si la codebase encapsule les appels LD derrière un utilitaire (featureFlags.track(), analytics.ldTrack()), ajoutez le nouvel appel via ce wrapper — pas en appelant ldClient directement.
• Correspondez exactement à la clé d'événement. Les clés d'événement track() sont sensibles à la casse. Utilisez la chaîne exacte avec laquelle la métrique a été créée.

Voir SDK Track Patterns pour des exemples complets par langage.

Étape 5 : Vérifier

Guidez l'utilisateur pour déclencher l'action dans son environnement local ou de staging. Utilisez ensuite list-metric-events pour confirmer que la clé d'événement apparaît :

list-metric-events(projectKey, environmentKey)

Si la clé d'événement apparaît : confirmez le succès et affichez un résumé.

Si la clé d'événement est absente après le déclenchement, parcourez cette checklist :

Affichez un résumé une fois vérifié :

✓ Événement en circulation : checkout-completed
  Vu dans : production

Ensuite : cet événement est maintenant prêt à soutenir une métrique. Utilisez la skill metric-create pour en configurer une,
ou attachez une métrique existante à votre expérience.

Contexte important

• Les appels track() ne comptent dans les expériences que si un flag est d'abord évalué. L'événement est corrélé à un participant de l'expérience parce que LD a vu un appel variation() de ce contexte. Si l'utilisateur déclenche l'action sans évaluer aucun flag, l'événement peut toujours être ingéré mais n'apparaîtra pas dans les résultats de l'expérience.
• Les SDKs client-side vident les événements à un intervalle (par défaut ~30 secondes) ou au déchargement de page. Dans les tests, vous devrez peut-être appeler ldClient.flush() explicitement pour voir les événements apparaître immédiatement.
• Les SDKs server-side mettent aussi les événements en buffer. Appeler ldClient.flush() après track() en développement garantit que l'événement est envoyé avant la sortie du processus ou la fin du test.
• Les unités de metricValue doivent correspondre à la définition de la métrique. Si la métrique a été créée avec l'unité ms, passez des millisecondes. Passer des secondes dans une métrique en millisecondes produira des résultats silencieusement incorrects.
• Le paramètre data est pour les métadonnées personnalisées, pas la valeur métrique. Passez du contexte supplémentaire (ID de commande, catégorie, etc.) dans data. Passez la mesure numérique dans metricValue.

Références

• SDK Track Patterns — syntaxe d'appel track(), initialisation et noms de paquets pour chaque SDK supporté