Un jeu gratuit ne reçoit rien au moment de l’installation. Son économie dépend donc d’une chaîne mesurable : acquisition, première session, retour, progression, offre et achat. Cette chaîne peut aider à améliorer un jeu, mais elle peut aussi optimiser la frustration plutôt que le plaisir.

Le client envoie des événements structurés : tutoriel commencé, niveau terminé, échec, objet vu, offre affichée, achat confirmé. Un pipeline les met en file, les stocke puis calcule des cohortes. Une cohorte regroupe par exemple les joueurs installés la même semaine et compare leur retour après un, sept et trente jours.

Lire un entonnoir sans se raconter d’histoire

Supposons 10 000 installations :

1. 8 000 démarrent le tutoriel;
2. 6 000 le terminent;
3. 3 000 reviennent le lendemain;
4. 800 voient une offre;
5. 120 achètent pour 5 $.

La conversion payante est 1,2 % des installations et le revenu brut, 600 $. Mais le calcul ne dit pas pourquoi 2 000 personnes quittent le tutoriel. Il faut relier l’événement à la difficulté, aux plantages, à l’appareil et à quelques tests qualitatifs.

Un test A/B peut montrer deux versions d’une récompense à des groupes assignés au hasard. La métrique principale et la durée doivent être choisies avant de regarder les résultats. Tester vingt variantes puis retenir la hausse chanceuse produit une fausse certitude. Les achats seuls ne suffisent pas : taux de retour, demandes de remboursement et plaintes servent de garde-fous.

Le client ne doit pas décider seul de l’économie

Si la monnaie et les achats restent uniquement dans la mémoire du jeu, un client modifié peut s’accorder des objets. Le serveur doit valider les transactions, conserver un grand livre et traiter les reçus de la boutique. Une opération porte un identifiant unique; si le téléphone perd la réponse et renvoie, le serveur retourne l’achat existant.

Le mode hors ligne crée un compromis. On peut laisser jouer et accumuler une progression locale, puis détecter les conflits au retour. Les récompenses achetables ou compétitives exigent davantage d’autorité serveur. Il faut aussi récupérer un compte après changement de téléphone sans permettre à un attaquant de voler l’inventaire.

Les événements contiennent parfois identifiant d’appareil, âge ou comportement détaillé. La collecte doit rester proportionnée, particulièrement pour les enfants. On limite la rétention, sépare les données de paiement et permet le retrait sans casser le jeu de base.

Rapprocher la monnaie virtuelle comme un grand livre

Chaque mouvement devrait avoir une écriture : source, destination, montant, raison et solde résultant. Un achat de 100 pièces crée un débit du compte du joueur et un crédit vers un puits identifié. Modifier directement le solde rend les anomalies impossibles à expliquer. Une contrainte interdit un solde négatif et une transaction protège l’achat de l’objet avec son paiement. Un job rapproche les reçus des boutiques, le grand livre et l’inventaire. Lorsqu’un remboursement arrive après consommation, une règle explicite décide dette, retrait d’objet ou support humain. Ce mécanisme limite la fraude et les pertes pendant une reprise.

Je définirais une économie avec des plafonds, un registre des changements et une revue humaine des mécaniques de pression. Puis je suivrais une cohorte complète, pas seulement les revenus du jour. Le moteur analytique est utile lorsqu’il repère un tutoriel cassé ou une progression plate; il devient inquiétant quand sa seule fonction est de trouver exactement combien d’irritation précède un achat.