Marketing et croissance liés aux métriques produit

1. Pourquoi le marketing d’une ChatGPT App — c’est de l’analytics produit, pas du « bruit »

Sur le web classique, on peut brancher Google Analytics, mettre des balises UTM sur tous les liens, poser deux pixels de retargeting — et vivre avec. Dans l’écosystème ChatGPT, tout est différent. L’utilisateur est dans l’interface de ChatGPT, et votre App est un « invité » dans ce dialogue. Les cookies, iframe et Facebook Pixel n’y ont pas droit de cité.

Cela fait automatiquement des événements produit la principale (et souvent la seule) source de vérité sur la croissance. À quelle fréquence ouvre‑t‑on l’App ? Les utilisateurs atteignent‑ils le scénario clé ? Reviennent‑ils ? Quel lien avec le revenu ? À toutes ces questions répondent non pas un compteur externe, mais vos événements MCP et votre analytics côté serveur.

Ici, le terme product‑led growth (PLG) s’impose naturellement : la croissance dépend moins du nombre de bannières achetées que de la capacité du produit à répondre au scénario utilisateur et de la manière dont vous le faites évoluer à partir des données.

Par conséquent, le personnage principal de cette leçon — c’est l’entonnoir d’événements interne à GiftGenius, et non un canal marketing externe. Les canaux seront là, mais uniquement comme des hypothèses qui influencent ces événements.

AARRR pour GiftGenius : notre entonnoir « pirate »

Le modèle AARRR (Acquisition, Activation, Retention, Revenue, Referral) s’adapte parfaitement à une ChatGPT App — il faut juste le traduire dans le langage des événements de notre application.

Pour GiftGenius, on peut la décrire ainsi :

app_opened

workflow_completed (pervyy raz)

povtornye workflow_completed / app_opened

checkout_started, checkout_success

referral_sent, referral_activated (optsional’no)

L’important, c’est que cet entonnoir est décrit non par des clics front‑end, mais par des « événements d’usage » au niveau MCP/App : l’utilisateur a ouvert, a parcouru le scénario, a acheté, est revenu. À la différence du web, où vous pistez parfois « chaque mouvement de souris », ici l’analytics doit être compacte et pertinente : moins de « où a‑t‑il cliqué », plus de « qu’a‑t‑il fait dans le scénario ».

Pour la version de base de GiftGenius, nous nous concentrons d’abord sur les quatre premiers niveaux (Acquisition, Activation, Retention, Revenue). Referral reste important, mais plutôt comme une étape suivante, à activer quand le cœur du produit et des paiements sera stabilisé.

2. Concevoir le modèle d’événements : des logs à l’analytics

Dans le module sur l’observability, nous nous sommes déjà mis d’accord pour écrire des logs JSON structurés, et non des « romans‑logs » libres. Par‑dessus, nous construisons maintenant le modèle événementiel du produit.

Idée minimale : chaque étape importante dans l’App génère un objet événement. Côté MCP, on peut à la fois le journaliser et l’envoyer vers un système d’analytics externe (BI, ClickHouse, BigQuery — au choix).

Une définition minimale des événements pour GiftGenius peut ressembler à ceci :

// Forme générale de l’événement
type GiftGeniusEventType =
  | 'app_opened'
  | 'workflow_started'
  | 'workflow_completed'
  | 'ideas_shown'
  | 'idea_clicked'
  | 'checkout_started'
  | 'checkout_success'
  | 'checkout_failed';

interface AnalyticsEvent {
  type: GiftGeniusEventType;
  userId?: string;          // depuis l’auth, si disponible
  sessionId: string;        // UUID de session dans ChatGPT
  timestamp: string;        // chaîne ISO
  properties?: Record<string, unknown>;
}

Il est pratique d’ajouter un petit helper pour envoyer des événements depuis la partie Next.js de l’application :

async function trackEvent(event: AnalyticsEvent) {
  await fetch('/api/analytics', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(event),
  });
}

Sur le serveur /api/analytics, vous pouvez déjà décider quoi en faire : stocker en base, envoyer dans un logger ou streamer dans un data‑pipeline. L’essentiel — que tous les événements soient dans un format unifié. En pratique, vous aurez un même ensemble d’événements produit, mais plusieurs points de naissance : il est plus pratique de fixer certaines étapes directement sur le serveur MCP via logger.info, et d’en envoyer d’autres depuis le widget comme AnalyticsEvent vers /api/analytics. Ce qui importe, ce n’est pas le nombre de « tuyaux » techniques, mais le fait que les types d’événements ("app_opened", "workflow_completed", etc.) et leurs champs restent unifiés et cohérents.

3. Acquisition : comprendre d’où viennent les utilisateurs

La première tâche du marketing — répondre à qui vient chez nous et combien ils sont. Dans une ChatGPT App, cette « venue » est fixée par le lancement de l’App dans un chat. Ce que nous voulons journaliser s’appelle "app_opened".

Pour GiftGenius, cela peut être fait côté widget (en réagissant au montage du composant) comme côté serveur (par exemple, au premier callTool de la session). C’est plus fiable côté serveur pour ne pas dépendre des particularités du rendu, mais voyons le front pour la simplicité.

Exemple de composant widget GiftGenius qui appelle trackEvent au premier rendu :

import { useEffect, useRef } from 'react';
import { trackEvent } from '../lib/analytics';

export default function GiftGeniusWidget() {
  const reported = useRef(false);

  useEffect(() => {
    if (reported.current) return;
    reported.current = true;

    trackEvent({
      type: 'app_opened',
      sessionId: crypto.randomUUID(),
      timestamp: new Date().toISOString(),
      properties: { source: 'chatgpt_app' },
    });
  }, []);

  return (
    <main>
      {/* ...UI principal du widget... */}
    </main>
  );
}

En pratique, vous voudrez récupérer sessionId et userId depuis un contexte existant (par exemple _meta ou un jeton d’autorisation), plutôt que de les générer côté client. Mais l’idée, c’est que chaque lancement de GiftGenius doit produire un tel événement.

Le problème des sources de trafic est moins bien résolu que sur le web : les referrers et balises UTM sont limités. On utilise généralement l’une des deux stratégies. La première — considérer que la source principale de trafic est le Store, et analyser uniquement "app_opened" dans le temps : si vous publiez un nouveau listing Store, regardez le pic de "app_opened" et les niveaux suivants de l’entonnoir. La seconde — utiliser des paramètres explicites : si vous donnez à l’utilisateur un lien du type https://chat.openai.com/...&utm_source=blog2025, alors lors du premier "app_opened", on peut prendre ce tag du contexte et le placer dans le champ referral_source.

Donc, les métriques d’acquisition ressemblent à : « le nombre de "app_opened" par jour », « le nombre de userId uniques qui ont lancé l’App par semaine », « la distribution par referral_source, si disponible ».

4. Activation : trouver l’« aha moment » dans GiftGenius

L’acquisition ne veut rien dire si les gens ferment aussitôt l’App. Le second étage clé — l’Activation. C’est le moment où l’utilisateur ressent pour la première fois que l’App fait quelque chose de réellement utile.

Pour GiftGenius, ce moment est logiquement lié à la fin du workflow : l’utilisateur a saisi des informations sur le destinataire, ajusté des filtres, et l’App lui a montré, disons, 10 idées pertinentes. C’est à ce moment qu’il voit la valeur pour la première fois.

Il est pratique de fixer cela via l’événement "workflow_completed". Ce pas est préférable à journaliser côté serveur MCP, quand vous avez déjà collecté les cadeaux et envoyez le résultat au widget :

logger.info('event.workflow_completed', {
  type: 'workflow_completed',
  userId,
  sessionId,
  requestId,
  ideasCount: giftIdeas.length,
  timestamp: new Date().toISOString(),
});

Ici, logger est votre logger structuré, déjà ajouté pour les SLO et l’instrumentation des coûts. Nous y avons simplement ajouté un événement produit.

C’est précisément sur "workflow_completed" que vous calculerez l’activation : activation_rate = (nombre de userId uniques ayant au moins un "workflow_completed") / (nombre de userId uniques avec "app_opened" sur la période).

On peut aussi regarder plus grossièrement : « la part des sessions sessionId dans lesquelles il y a eu un "workflow_completed" ». L’important est que ce soit une métrique familière : plus l’activation est haute, meilleur est le démarrage de l’App.

5. Retention : les utilisateurs reviennent‑ils vers votre App ?

La retention pour une ChatGPT App est un peu plus complexe que pour un produit web classique. D’un côté, ChatGPT est déjà un endroit où l’on revient naturellement. De l’autre, on peut revenir à une multitude d’Apps, pas forcément la vôtre. Nous voulons comprendre s’il revient à GiftGenius.

En présence d’authentification (module 10), vous disposez d’un userId ou d’un tenantId stable. La définition classique est alors simple : un utilisateur est considéré comme « retained » s’il a, disons, 7 jours après son premier "workflow_completed", un nouveau "workflow_completed" ou au moins un "app_opened".

Si l’auth n’existe pas, on peut utiliser une métrique plus faible basée sur sessionId et des userKey heuristiques (par exemple, un hash du compte OpenAI s’il est disponible dans _meta), mais dans ce cours, nous supposerons que userId est bien présent.

Sous forme de logique type SQL (pseudo‑code), cela ressemble à :

-- première activation
WITH first_activation AS (
  SELECT user_id, MIN(timestamp) AS first_ts
  FROM events
  WHERE type = 'workflow_completed'
  GROUP BY user_id
),
retained_d7 AS (
  SELECT fa.user_id
  FROM first_activation fa
  JOIN events e
    ON e.user_id = fa.user_id
   AND e.timestamp >= fa.first_ts + INTERVAL '7 day'
   AND e.timestamp <  fa.first_ts + INTERVAL '14 day'
   AND e.type IN ('app_opened', 'workflow_completed')
)
SELECT COUNT(*) / (SELECT COUNT(*) FROM first_activation) AS d7_retention
FROM retained_d7;

Vous n’avez pas besoin d’écrire une telle beauté SQL en production, mais il est important de comprendre l’idée : la retention, c’est le fait que les gens reviennent utiliser l’App, et pas seulement qu’ils aient payé une fois.

6. Revenue : relier l’entonnoir à l’argent

La couche Revenue pour GiftGenius rappelle pourquoi nous faisons tout cela. Dans le module commerce, nous avons déjà ajouté des événements autour du paiement : "checkout_started", "checkout_success", "checkout_failed". Ces mêmes événements deviennent la clé des métriques produit de revenu : conversion et panier moyen.

Au moment où l’utilisateur clique sur « Acheter un cadeau » et que vous créez une session de paiement (via ACP/Stripe), côté MCP il convient de journaliser l’événement :

logger.info('event.checkout_started', {
  type: 'checkout_started',
  userId,
  sessionId,
  requestId,
  amount: checkout.amount,
  currency: checkout.currency,
  timestamp: new Date().toISOString(),
});

Quand arrive le webhook de succès du PSP :

logger.info('event.checkout_success', {
  type: 'checkout_success',
  userId,
  sessionId,
  orderId,
  amount: payment.amount,
  currency: payment.currency,
  timestamp: new Date().toISOString(),
});

Vous pouvez maintenant calculer facilement la conversion :

• « de "workflow_completed" à "checkout_started" » — à quelle fréquence les gens vont‑ils au paiement ;
• « de "checkout_started" à "checkout_success" » — la qualité de votre flux commerce (erreurs de carte, fraude, UX de paiement).

Simultanément, ces mêmes événements se connectent aux logs de coûts du cours précédent sur le contrôle des dépenses et l’instrumentation des coûts : via requestId ou sessionId, vous savez quelles invocations d’outil et combien de tokens/argent ont coûté le chemin jusqu’à cet achat. Cela donne des métriques du type « cost_per_paid_workflow moyen » et « revenu moins coût de revient par commande réussie ».

7. Referral : quand les utilisateurs en amènent d’autres

La couche Referral dans une ChatGPT App est un peu atypique. Vous n’avez pas de push ni d’emailing, mais les utilisateurs peuvent partager des chats, des liens et simplement se dire « cherche GiftGenius dans le Store ».

Techniquement, vous pouvez introduire les événements "referral_sent" et "referral_activated", si :

• vous fournissez aux utilisateurs un code de parrainage ou un paramètre dans le lien vers l’App (?ref=friend123),
• ou vous traitez referral_source/campaign dans le contexte de "app_opened".

Dans un MVP de base de GiftGenius, on peut laisser Referral pour plus tard — il faut d’abord structurer Acquisition/Activation/Revenue et s’assurer que le cœur de l’entonnoir fonctionne. Mais il est important de savoir où « l’accrocher » : aux mêmes logs d’événements et métriques, et non à un Excel séparé avec des codes promo.

Entonnoir visuel GiftGenius

Pour garder l’image en tête plus facilement, il est utile de dessiner un petit schéma :

flowchart LR
  A[app_opened] --> B[workflow_started]
  B --> C[workflow_completed]
  C --> D[checkout_started]
  D --> E[checkout_success]

Chaque arête ici — c’est une conversion mesurable. Marketing, changements UX, expériences avec les modèles — tout doit, au final, augmenter une ou plusieurs de ces conversions. Si vous faites quelque chose sans pouvoir dire quelle arête doit s’améliorer, c’est suspect.

Tableaux de bord de croissance : quels rapports en priorité

Imaginons un tableau de bord minimal pour la croissance de GiftGenius. Nous ne construisons pas ici un système BI « spatial », mais voulons au moins un tableau à regarder chaque semaine.

Exemple de rapport agrégé par jour :

On voit tout de suite que le 3, nous avons « injecté » de l’acquisition (hausse de "app_opened"), mais l’activation et la conversion ont baissé — peut‑être que le trafic n’était pas le bon ou que vous avez cassé quelque chose dans l’UX. Ce sont précisément ces tableaux qui aident à distinguer un bon marketing d’un marketing simplement bruyant.

Par‑dessus l’axe temps, il est utile de regarder des cohortes : utilisateurs venus une semaine donnée et leur retention après 7/30 jours. Mais pour commencer, savoir construire des coupes simples par jours et semaines suffit.

8. Le marketing comme une série d’expériences sur les événements

Passons maintenant au moment le plus « marketing » : comment relier des actions externes (articles, listing Store, partenariats) à ce que nous voyons dans les événements de l’App.

Principe clé : toute idée marketing se formule comme une hypothèse sur quelles métriques produit doivent changer.

Par exemple, pour GiftGenius :

• « Si nous améliorons le listing du Store (icônes, description, vidéo démo), le nombre de "app_opened" par de nouveaux utilisateurs doit augmenter et, idéalement, le taux d’activation parmi eux ».
• « Si nous écrivons un article sur le choix des cadeaux pour le Nouvel An et y mettons un lien vers GiftGenius, alors dans les 3 prochains jours doivent augmenter les "app_opened" avec referral_source = "blog_ny2025" puis les "workflow_completed" dans cette cohorte ».

Techniquement, cela se réalise souvent via un champ supplémentaire campaign ou referral_source dans l’événement "app_opened". Par exemple, si lors de l’initialisation de l’App vous recevez du contexte ChatGPT un certain tag :

trackEvent({
  type: 'app_opened',
  sessionId,
  timestamp: new Date().toISOString(),
  properties: {
    referral_source: openaiContext.referralSource ?? 'organic',
    app_version: '1.3.0',
  },
});

Vous pouvez maintenant construire des rapports « par campagne » : combien de "app_opened" et de "workflow_completed" chez ceux venus avec referral_source = "blog_ny2025", et en quoi cela diffère de l’organique.

Important : nous ne considérons pas le marketing réussi uniquement via des « couvertures » affichées ailleurs. Si un blogueur dit que sa vidéo a été vue par un million de personnes, c’est super, mais pour GiftGenius, le succès sera « la hausse de "app_opened" et de "workflow_completed" chez nous ».

9. Exemple : une expérience marketing pour GiftGenius

Rassemblons tout dans un scénario concret et relions soigneusement une campagne externe aux événements produit à l’intérieur de GiftGenius.

Supposons que vous vouliez tester l’hypothèse : un article sur un blog populaire de cadeaux amènera des utilisateurs « qualifiés ». Dans l’article, vous mettez un lien non pas directement vers ChatGPT, mais vers votre landing, par exemple :

https://giftgenius.app/landing?utm_source=giftblog2025

L’utilisateur arrive sur un court landing décrivant GiftGenius avec un bouton « Ouvrir dans ChatGPT ». Côté backend du landing, vous lisez utm_source et l’enregistrez dans le profil utilisateur (ou dans une table séparée), par exemple comme acquisitionSource = "giftblog2025". Le bouton du landing mène déjà à votre ChatGPT App dans le Store, l’utilisateur connecte l’App et commence à l’utiliser.

Quand cet utilisateur lance GiftGenius dans ChatGPT et que votre backend reçoit le premier appel depuis Apps SDK / MCP, vous récupérez acquisitionSource et l’ajoutez aux événements produit. Pour "app_opened", cela peut ressembler à :

logger.info('event.app_opened', {
  type: 'app_opened',
  userId,
  sessionId,
  referral_source: user.acquisitionSource ?? 'organic',
  timestamp: new Date().toISOString(),
});

Vous taguez de la même façon les événements "workflow_completed", "checkout_started", "checkout_success". L’expérience se ramène ensuite à comparer des cohortes : utilisateurs avec referral_source = "giftblog2025" contre organique. Si la cohorte « blog » a une part plus élevée de scénarios complétés et de paiements, avec un revenu par utilisateur comparable ou meilleur, la campagne peut être considérée comme réussie ; si seuls les lancements d’application montent mais que la conversion vers "workflow_completed" et "checkout_success" baisse, cela signifie que l’article amène surtout des curieux, pas des acheteurs.

L’avantage de cette approche, c’est que vous « traduisez » proprement une balise UTM du monde web vers votre champ interne referral_source, puis vous travaillez uniquement avec l’analytics produit de l’App — sans magie ni tentative de faire transiter des paramètres d’URL directement dans ChatGPT.

En parallèle, vous pouvez regarder le coût de revient si vous notez le CAC quelque part (coût de diffusion) et le cost_per_task. L’hypothèse devient alors une expérience plus « financière » : « Ce canal est‑il rentable ? ».

10. Analytics privacy‑first : ne pas briser la politique ni le bon sens

Point important à part — comment ne pas devenir un peu Facebook. À la différence du web classique, OpenAI traite la vie privée dans les ChatGPT Apps de manière assez stricte : on ne peut pas tracer des données personnelles, collecter de la PII inutile ni envoyer le texte complet des dialogues n’importe où.

Les bonnes pratiques pour l’analytics de GiftGenius ressemblent à :

1. Ne pas stocker le texte brut des messages utilisateur dans les événements. À la place, journaliser uniquement des « faits de scénario » : type de scénario, nombre d’idées affichées, succès du paiement.
2. Si vous devez distinguer des utilisateurs, utiliser des identifiants pseudonymisés (userId, tenantId), pas l’email/le nom. Toute PII est stockée en base avec authentification, et l’analytics manipule des clés anonymisées.
3. Éviter dans les logs/événements des champs pouvant identifier directement une personne si ce n’est pas nécessaire (par exemple, l’adresse de livraison complète n’a clairement pas sa place dans un événement ; sa place est dans la base protégée du commerce).
4. Utiliser au maximum l’analytics agrégée : ce qui vous intéresse, ce sont les activation‑rates et la retention sur des centaines d’utilisateurs, pas des personnes nominativement.

Et n’oublions pas que nous avons déjà eu un module sur l’audit & le cycle de vie : si l’utilisateur demande la suppression de ses données, la logique de retention doit en tenir compte. Mais cela relève plutôt du module 15 ; ici, il suffit de garder à l’esprit que l’analytics ne donne pas d’indulgence pour collecter n’importe quelles données.

11. Lien avec l’instrumentation des coûts et les SLO : un marketing qui mesure tout

D’un point de vue technique, l’image idéale ressemble à ceci : vous avez un flux unifié d’événements structurés, où à chaque session utilisateur sont associés :

• des événements produit ("app_opened", "workflow_completed", "checkout_success") ;
• des données de coûts (tokens, cost_estimate, duration_ms par outil) ;
• des métriques SLO (latence et erreurs MCP/outils, disponibilité).

Alors, toute décision marketing et produit devient réellement data‑driven presque automatiquement. Vous pouvez demander :

• « Quel est l’activation_rate des utilisateurs de la campagne X et combien coûte en moyenne leur workflow réussi ? »
• « L’error_rate ou la latence p95 augmentent‑ils à mesure que le trafic du Store grandit ? »
• « Si nous avons réduit le coût du modèle dans l’expérience « coût ↔ qualité » du cours précédent, la conversion vers "checkout_success" a‑t‑elle baissé et le revenue par utilisateur a‑t‑il diminué ? »

Et tout cela ne requiert pas d’inventer de nouveaux systèmes — vous utilisez simplement les mêmes logs et outils de coûts que vous avez déjà intégrés.

Au final, le marketing d’une ChatGPT App n’est pas un trafic pour le trafic, mais l’amélioration de métriques produit concrètes à l’intérieur de votre application. Journalisez les étapes clés du scénario ("app_opened", "workflow_completed", "checkout_success"), reliez‑les à l’instrumentation des coûts et aux SLO, et formulez vos actions marketing comme des hypothèses sur le maillon de l’entonnoir que vous voulez améliorer. Si vous gardez cet entonnoir et les contraintes de confidentialité à l’esprit, les décisions sur le produit et la croissance deviennent automatiquement plus pertinentes et plus durables.

12. Erreurs typiques dans le travail avec les métriques produit et le marketing

Erreur n°1 : du marketing pour le trafic, pas pour l’activation.
Il arrive souvent que les équipes se réjouissent d’une hausse brutale de "app_opened" après un article ou un tweet, et déclarent l’expérience réussie sans regarder l’activation et la conversion. Au final, on obtient une foule de « touristes » qui augmentent la charge et les coûts, mais n’apportent pas d’argent et ne deviennent pas de vrais utilisateurs. La bonne approche — regarder toujours au‑delà de la première étape de l’entonnoir : combien, parmi les arrivants, sont allés jusqu’à "workflow_completed" et "checkout_success".

Erreur n°2 : absence d’identifiant utilisateur unifié.
Parfois, l’App commence à journaliser des événements, mais sans userId stable ni même tenantId. Dans ce mode, vous ne pouvez compter que quelque chose comme « le nombre d’événements par jour », mais ni la retention ni le cost_per_user. Ajouter plus tard un suivi utilisateur correct peut s’avérer difficile, surtout s’il existe déjà de fortes contraintes de confidentialité. Mieux vaut réfléchir au schéma d’identification au stade de l’authentification (module 10) et l’utiliser dans tous les événements.

Erreur n°3 : tracer « chaque éternuement » au lieu des événements clés.
La première réaction à l’analytics événementielle — journaliser absolument tout : survol de souris, chaque focus d’input, chaque re‑render. Dans le contexte ChatGPT, c’est particulièrement nuisible : ces événements s’intègrent mal au modèle d’usage, créent des tonnes de bruit et accroissent les risques de confidentialité. Bien plus utile de se limiter à quelques événements clés du scénario et de les analyser correctement.

Erreur n°4 : des campagnes marketing sans attribution.
Schéma courant : l’équipe lance une campagne (article, vidéo, partenariat), mais ne marque pas le trafic entrant et se demande ensuite « est‑ce que ça a marché ? ». En conséquence, tous les changements de métriques se diluent. Beaucoup mieux d’utiliser des champs explicites referral_source ou campaign dans les événements "app_opened", même via de simples paramètres de type UTM, puis de comparer ces cohortes à l’organique.

Erreur n°5 : ignorer les contraintes de confidentialité pour une « analytics complète ».
Parfois, à la poursuite du détail, on commence à écrire dans les événements le texte des requêtes, des données personnelles du destinataire du cadeau, des adresses et autres PII. C’est dangereux sur deux plans : du point de vue des politiques OpenAI/Store et du point de vue du risque juridique réel (RGPD, CCPA, etc.). La bonne analytics se construit sur des indicateurs agrégés du scénario et des identifiants anonymes, pas sur la conservation de toute la conversation « au cas où ».

Erreur n°6 : optimiser uniquement les coûts, sans tenir compte de la qualité et de la croissance.
Après le module sur les coûts, on peut basculer dans un « mode économie » extrême, en essayant de réduire les tokens à tout prix. Si, ce faisant, le taux d’activation, la retention et "checkout_success" baissent, l’économie est une fausse bonne idée : vous tuez la valeur du produit. Gardez toujours en tête le triangle « coût ↔ qualité ↔ croissance » : tout changement de prompts, de modèles et d’UX doit être regardé à travers le prisme du coût de revient et des métriques produit.