Revenue Playbook

L’achat SDK est qu'une partie de gagner de l'argent avec une application. Les revenus viennent d'une problème clair, d'un produit petit que les utilisateurs peuvent essayer, d'une facturation de magasin fiable et d'une barrière payante qui vous enseigne ce que les gens sont prêts à acheter.

Utilisez ce livre d'or lorsque vous ajoutez des abonnements ou des déverrouillages premium avec @capgo/native-purchases.

Démarrez avec un objectif de revenu simple

Fixez le premier objectif concrètement. Par exemple :

Prix mensuel	Abonnés actifs nécessaires pour environ 1 000 $ MRR
$4.99	201
$7.99	126
$9.99	101
29,99 $ par an	Environ 400 abonnés annuels, en fonction de la chronologie

Ceux-ci sont avant les frais de magasin, les taxes, les remboursements et les différences de devise. Ils sont toujours utiles car ils gardent le plan de lancement pratique : vous avez besoin de quelques centaines d'utilisateurs motivés, pas d'une vaste audience.

Construisez le produit payant le plus petit

1. Choisissez un cas d'utilisation douloureux

   Construit autour d'une seule issue que les utilisateurs recherchent déjà. Exemples : un plan de travail pour de nouveaux parents, un gestionnaire de budget pour les couples, un scanner de factures pour les freelances, ou une application de grammaire pour un examen.

2. Vérifiez la demande dans les magasins

   Recherchez l'App Store et Google Play pour le mot-clé principal. Lisez les commentaires de notes basses et moyennes des applications concurrentes pour trouver des fonctionnalités manquantes, une onboarding confusante, des plaintes de tarification et des obstacles de l'interface utilisateur.

3. Lancez une MVP étroite

   La première version devrait inclure l'onboarding, une action utile principale, un traitement d'erreur de base et suffisamment d'analytiques pour voir si les utilisateurs atteignent le moment de valeur.

4. Ajoutez les achats tôt

   Ne attendez pas jusqu'à ce que l'application se sente complète. Un paywall de base vous aide à apprendre si les utilisateurs comprennent la valeur et si votre tarification est plausible.

Instrumentez le canal avant d'optimiser

Suivez ces événements avant de commencer à modifier les prix ou les écrans :

Événement	Cela compte
install ou ouvrez d'abord	Trafic de base
onboarding_completed	Les utilisateurs comprennent-ils la configuration
core_action_completed	Le produit fournit-il de la valeur
paywall_viewed	Les utilisateurs atteignent-ils la monétisation
trial_started	L'offre est-elle séduisante
purchase_completed	Conversion payante
restore_started et restore_completed	Récupération et conformité de l'achat
subscription_status_checked	Fiabilité de l'entitlement
cancel_feedback_submitted	Raison de la dérive

Si beaucoup d'utilisateurs ne voient pas le mur de payement, corrigez l'inscription avant de modifier le mur de payement. Si les utilisateurs voient le mur de payement mais ne commencent pas un essai, améliorez l'offre, la preuve ou la présentation du prix.

Choisissez un modèle de monétisation

Commencez par un modèl’afin que les données soient lisibles.

Modèle	Bon ajustement	Première version
Version initiale	Freemium	Outils quotidiens, suiveurs, outils avec utilisation répétée
Action gratuite de base, limites payantes ou fonctionnalités premium	Paywall avec essai gratuit	Applications qui fournissent une valeur rapide après l'inscription
Un verrouillage unique	Petits outils avec une valeur récurrente limitée	Produit à vie plus abonnement facultatif ultérieur

Évitez de livrer trois niveaux, de nombreux forfaits et des chemins d'amélioration complexes dès le premier jour. Utilisez un plan mensuel et un plan annuel lorsqu'il vous faut des abonnements. Ajoutez des tarifs localisés après avoir vu un trafic significatif d'un pays.

Configurez les produits pour l'apprentissage des revenus

Conservez les identificateurs de produit stables et lisibles :

com.example.app.premium.monthly
com.example.app.premium.yearly
com.example.app.premium.lifetime

Utilisez les noms de produits de magasin qui renforcent la valeur que les utilisateurs recherchent, comme « Meal Planner Pro Mensuel » au lieu de seulement « Mensuel ». Les métadonnées et les noms de mise à jour en application peuvent aider à la découverte et à la clarté.

Chargez les données de produit à partir des magasins afin que les tarifs, la devise et les offres d'introduction soient toujours précis :

import { NativePurchases, PURCHASE_TYPE } from '@capgo/native-purchases';

const { products } = await NativePurchases.getProducts({
  productIdentifiers: [
    'com.example.app.premium.monthly',
    'com.example.app.premium.yearly',
  ],
  productType: PURCHASE_TYPE.SUBS,
});

const monthly = products.find((product) => product.identifier.endsWith('.monthly'));
const yearly = products.find((product) => product.identifier.endsWith('.yearly'));

Ne fixez jamais les tarifs de magasin dans l'interface utilisateur. Affichez product.priceStringUtilisez les informations de produit localisées, la période de facturation et les termes de la période d'essai à partir des données du magasin chaque fois que possible.

Construirez la première barrière payante.

La première barrière payante doit être claire, pas ingénieuse :

• Titre : le résultat payant, tel que « Découvrez des plans d'entraînement illimités ».
• Avantages : 3 à 5 améliorations concrètes, pas une longue liste de fonctionnalités.
• Plans : mensuels et annuels, avec des économies réelles annuelles si proposés.
• Essai : durée exacte de l'essai et ce qui se passe après sa fin.
• LTI : « Démarrer l'essai gratuit » ou « Mise à niveau maintenant ».
• Lien : conditions d'utilisation, politique de confidentialité, restauration des achats et gestion des abonnements.

Placez la première barrière payante après l'inscription, une fois que l'utilisateur comprend ce que fait l'application. Plus tard, testez des déclencheurs supplémentaires tels que des limites d'utilisation, des appels de fonctionnalités premium ou des actions de base complétées.

Flux d'achat et de restauration

import { NativePurchases, PURCHASE_TYPE } from '@capgo/native-purchases';

export async function buyYearly(appAccountToken: string) {
  const transaction = await NativePurchases.purchaseProduct({
    productIdentifier: 'com.example.app.premium.yearly',
    planIdentifier: 'yearly-plan',
    productType: PURCHASE_TYPE.SUBS,
    appAccountToken,
  });

  await fetch('/api/purchases/validate', {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({
      transactionId: transaction.transactionId,
      receipt: transaction.receipt,
      purchaseToken: transaction.purchaseToken,
      productIdentifier: transaction.productIdentifier,
    }),
  });

  return transaction;
}

export async function restorePurchases() {
  await NativePurchases.restorePurchases();

  return NativePurchases.getPurchases({
    productType: PURCHASE_TYPE.SUBS,
  });
}

Vérifiez toujours les achats sur votre serveur avant de concéder des droits durables. Gardez une cache de droits locaux pour une interface rapide, mais considérez l'application et votre serveur comme la source de vérité.

Apportez les premiers utilisateurs

Le revenu nécessite du trafic. Commencez par les canaux qui peuvent fonctionner avant d'avoir une marque :

• ASO : titre, sous-titre, mots-clés, captures d'écran, description de l'application, icône, notes et noms de ventes en ligne.
• Vidéo courte : publiez des démos rapides, des clips problème/solution et des exemples avant/après pour le pays cible.
• Reddit et communautés : rejoignez la conversation en premier, puis partagez ce que vous avez construit comme une histoire utile plutôt qu'une publicité.
• Groupe de bêta : TestFlight, Google Play testing interne, Discord et forums spécialisés.

Chaque canal doit envoyer les utilisateurs dans le même canal mesuré afin de pouvoir comparer la rétention, les vues de la barrière payante, les essais et les achats.

Lisez correctement le déclin

Le déclin signifie que les utilisateurs ont essayé l'application et ont décidé qu'elle ne leur convenait pas. C'est normal. Ce qui compte, c'est le modèle :

• Annulations pendant la période d'essai : valeur incertaine, onboarding défectueux ou trafic incorrect.
• Annulations après un cycle : valeur de répétition insuffisante ou boucle de habitude faible.
• Remboursements : incohérence de tarifs, risque d'achat accidentel ou conditions non claires.
• Aucun restore : gestion de l'entitlement brisée ou interface de restauration manquante.

Ajoutez un sondage d'annulation à une seule question lorsque possible. Utilisez les réponses pour améliorer l'onboarding, le périmètre des fonctionnalités, les captures d'écran de l'application Store et le texte de la paywall.

Liste de vérification de lancement

• Le produit résout un problème payant clair.
• Les produits de l'application Store sont actifs et testés sur iOS et Android.
• La paywall affiche les prix et les conditions chargés par l'application Store.
• Achats, restauration, gestion de l'abonnement et validation back-end sont mis en œuvre.
• Les événements de la truffe sont suivis de la première ouverture à l'achat.
• Les métadonnées de l'application expliquent la valeur dans les premières captures d'écran.
• Au moins un canal d'acquisition est actif avant le lancement.
• Les retours sur la perte de souscription sont collectés auprès des premiers abonnés.

Guides connexes

• Démarrage
• Créer des abonnements iOS
• Créer des abonnements Android
• Test de sandbox iOS
• Test de sandbox Android

Continuez de là du Cahier des charges des revenus

Si vous utilisez Cahier des charges des revenus pour planifier les paiements et les achats, connectez-l’à En utilisant @capgo/native-purchases pour la capacité native dans En utilisant @capgo/native-purchases, Capgo Tarification pour le flux de travail du produit dans Capgo Tarification, Système de paiement pour le détail d'implémentation dans Système de paiement, @capgo/native-purchases pour les détails d'implémentation dans @capgo/achats natifs, et Démarrage pour les détails d'implémentation dans Démarrage.