Analytics et optimisation

Mesurer et optimiser les performances de votre app

Une app publiée sans suivi analytique est un investissement en aveugle : vous savez qu’elle tourne, jamais si elle sert. Le Apps SDK et le portail développeur exposent les métriques nécessaires pour comprendre comment votre app est utilisée, à quel moment les utilisateurs décrochent et où porter votre prochain effort.

Lire les bonnes métriques

L’engagement se mesure d’abord par les sessions par utilisateur, c’est-à-dire le nombre de fois qu’une personne lance votre app dans la semaine, puis par les actions par session, qui indiquent si la conversation va au bout ou s’arrête au premier appel. La durée de session complète le tableau, et le taux de complétion — la part des sessions qui aboutissent à un résultat utile — reste le plus révélateur des quatre : un taux bas signale presque toujours un problème de parcours plutôt que de trafic.

La rétention se lit ensuite à trois horizons. La rétention J1 vous dit si l’app a tenu sa promesse dès le premier usage, la J7 si elle est entrée dans une habitude, la J30 si elle y reste. Les cohortes, qui suivent l’évolution de ces taux par date d’inscription, sont ce qui vous permet de savoir si une mise à jour a réellement amélioré les choses ou si vous observez simplement un afflux de nouveaux venus.

Si votre app monétise, cinq indicateurs supplémentaires structurent votre pilotage, et ils se lisent dans l’ordre du parcours. Le taux d’installation mesure la part des visiteurs du Store qui franchissent le pas, donc la qualité de votre fiche bien plus que celle de votre code. Le taux de conversion du gratuit vers le payant vous dit ensuite si votre frontière premium est placée au bon endroit.

Viennent enfin les trois chiffres qui déterminent la viabilité économique : l’ARPU, revenu moyen par utilisateur, le churn mensuel, pourcentage d’abonnés qui annulent, et la LTV, valeur vie client estimée. Le churn est celui qu’on surveille le plus étroitement, parce qu’il agit sur la LTV de façon multiplicative — gagner deux points de rétention mensuelle vaut souvent plus qu’une hausse de prix.

Récupérer les métriques par le code

Le dashboard du portail suffit pour un coup d’œil quotidien, mais l’API du SDK vous permet d’automatiser vos rapports ou de croiser ces chiffres avec vos propres données.

import { analytics } from "@openai/apps-sdk";

// Récupérer les métriques des 30 derniers jours
const metrics = await analytics.getMetrics({
  appSlug: "mon-app",
  period: "30d",
  metrics: ["dau", "sessions", "actions", "revenue"],
});

console.log(`DAU moyen : ${metrics.dau.average}`);
console.log(`Sessions totales : ${metrics.sessions.total}`);
console.log(`Revenu du mois : ${metrics.revenue.total} EUR`);

Le détail par action est encore plus opérationnel, car il associe à chaque action son volume d’appels, sa latence moyenne et son taux d’erreur. C’est là que vous découvrez qu’une action peu appelée plombe votre expérience, ou qu’une action massivement utilisée mérite une optimisation ciblée.

const actionMetrics = await analytics.getActionMetrics({
  appSlug: "mon-app",
  period: "7d",
});

// Résultat :
// [
//   { action: "searchProducts", calls: 4521, avgLatency: 230, errorRate: 0.02 },
//   { action: "getDetails", calls: 2103, avgLatency: 180, errorRate: 0.01 },
//   { action: "addToCart", calls: 891, avgLatency: 150, errorRate: 0.03 },
// ]

Réduire la latence

La latence d’une action se ressent immédiatement dans la conversation. Le gain le plus facile consiste à cesser d’attendre des appels indépendants les uns après les autres : trois requêtes séquentielles de 200 ms coûtent 600 ms, les mêmes en parallèle en coûtent 200.

// Avant : appels séquentiels (lent)
const product = await fetchProduct(id);
const reviews = await fetchReviews(id);
const stock = await checkStock(id);

// Après : appels parallèles (rapide)
const [product, reviews, stock] = await Promise.all([
  fetchProduct(id),
  fetchReviews(id),
  checkStock(id),
]);

Le second levier est le cache intégré du SDK, à réserver aux données qui bougent rarement. Une liste de catégories produit change quelques fois par an : la recalculer à chaque appel n’apporte rien.

export const getCategories = defineAction({
  name: "getCategories",
  description: "Liste les catégories de produits disponibles",
  cacheTtl: 3600, // Cache 1 heure
  handler: async () => {
    return await fetchCategories();
  },
});

Corriger les erreurs de routage

Quand le modèle appelle systématiquement la mauvaise action, le défaut vient rarement du code : il vient de descriptions trop proches l’une de l’autre. La correction consiste à expliciter non seulement ce que fait l’action, mais dans quelle situation l’utiliser.

// Problème : le modèle confond searchProducts et getProductDetails
// Solution : descriptions plus distinctes

// searchProducts
description: "Recherche des produits par mot-clé dans le catalogue. Retourne une liste de résultats. Utilisez cette action quand l'utilisateur cherche quelque chose sans connaître le produit exact."

// getProductDetails
description: "Récupère les détails complets d'un produit spécifique par son identifiant. Utilisez cette action quand l'utilisateur veut plus d'informations sur un produit déjà identifié."

Trancher par l’expérimentation

Plutôt que de débattre de la meilleure présentation d’une page de tarifs, testez-la. Le SDK affecte chaque utilisateur à une variante stable et vous laisse rendre un widget différent selon le groupe.

import { experiment } from "@openai/apps-sdk";

app.action("showPricing", {
  description: "Affiche les options de tarification",
  handler: async (_, context) => {
    const variant = await experiment.getVariant(
      context.user.id,
      "pricing-layout"
    );

    if (variant === "A") {
      return { _widget: "pricingCards" }; // Cartes côte à côte
    } else {
      return { _widget: "pricingTable" }; // Tableau comparatif
    }
  },
});

La lecture des résultats se fait ensuite en une ligne, et l’écart se passe de commentaire.

const results = await experiment.getResults("pricing-layout");
// { A: { conversion: 0.12 }, B: { conversion: 0.18 } }
// Le tableau comparatif convertit 50 % mieux

Un tableau de bord qui vous ressemble

Rien ne vous oblige à consulter deux interfaces séparées. En combinant les métriques du SDK et vos données internes dans une action protégée, vous obtenez votre propre dashboard, accessible depuis la conversation — à condition de vérifier les droits avant toute chose.

app.action("adminDashboard", {
  description: "Affiche le tableau de bord administrateur de l'application",
  auth: "required",
  handler: async (_, context) => {
    if (!isAdmin(context.user.id)) {
      throw new ActionError("FORBIDDEN", "Accès réservé aux administrateurs");
    }

    const [appMetrics, businessMetrics] = await Promise.all([
      analytics.getMetrics({ appSlug: "mon-app", period: "7d" }),
      getBusinessMetrics(), // Vos propres métriques
    ]);

    return {
      _widget: "adminDashboard",
      dau: appMetrics.dau.average,
      revenue: appMetrics.revenue.total,
      activeSubscriptions: businessMetrics.subscriptions,
      topActions: appMetrics.topActions,
    };
  },
});

Les chiffres ne racontent qu’une moitié de l’histoire : les avis laissés sur le Store donnent l’autre. Répondez systématiquement aux avis négatifs en annonçant un plan d’action concret, cherchez les motifs récurrents dans les demandes de fonctionnalités plutôt que de réagir à la dernière reçue, et mesurez après chaque mise à jour son effet sur la rétention et sur la note — c’est ce va-et-vient entre métriques et retours qui fait progresser une app.

Points clés à retenir

• Le dashboard développeur expose les métriques d’engagement, rétention et revenus
• Analysez les performances par action pour identifier les goulots d’étranglement
• Parallélisez les appels et utilisez le cache pour réduire la latence
• Le A/B testing permet de comparer différentes approches de manière empirique
• Les descriptions d’actions bien rédigées réduisent les erreurs de routage du modèle
• Itérez continuellement sur les retours utilisateurs et les métriques

Testez vos connaissances

Du SDK au Store : validez le parcours d’une app ChatGPT.

1. Quels sont les trois piliers de l'architecture Apps SDK ?

Réponse : Les actions (connecter votre backend), les widgets (interfaces riches dans ChatGPT) et le commerce (vendre dans la conversation) — une app combine ces briques selon son modèle.

2. Que fait une action, techniquement ?

Réponse : Elle relie l’app à votre API : ChatGPT appelle votre backend avec des paramètres structurés et intègre la réponse dans la conversation — l’authentification sécurise l’accès aux comptes utilisateurs.

3. À quoi servent les widgets ?

Réponse : À dépasser le texte : afficher des interfaces interactives (listes, cartes, formulaires) dans ChatGPT — l’expérience d’une app, sans quitter la conversation.

4. Que vérifie le processus de review avant publication ?

Réponse : La conformité aux guidelines : sécurité, confidentialité, qualité de l’expérience, honnêteté de la description — préparez la soumission en testant les cas limites avant de la lancer.

5. Que suit-on après le lancement ?

Réponse : Les analytics d’usage : activation, rétention, parcours et conversions — c’est sur ces données qu’on optimise l’app et son modèle économique.

Actions, widgets, commerce, review, analytics : le cycle complet d’un produit — dans une interface que des centaines de millions d’utilisateurs ouvrent déjà.