Livre de jeu des revenus

La commande d'achat SDK n'est qu'une partie de la génération de revenus à partir d'une application. Les revenus proviennent d'un problème clair, d'un produit minimal que les utilisateurs peuvent essayer, d'une facturation de magasin fiable et d'une barrière payante qui enseigne ce que les gens sont prêts à acheter.

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

Commencez par un objectif de revenus simple

Fixez l'objectif concret. 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 du calendrier

Ces chiffres sont avant les frais de stockage, 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 d'une poignée de centaines d'utilisateurs motivés, pas d'une audience immense.

Construire le plus petit produit payant

1. Choisissez un cas d'utilisation douloureux

   Construire autour d'un résultat que les utilisateurs recherchent déjà. Exemples : un plan de travail pour de nouveaux parents, un suivi de budget pour des couples, un scanner de factures pour des 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 bas et moyens 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 un MVP étroit

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

4. Ajoutez les achats tôt

   N'attendez pas jusqu'à ce que l'application se sente complète. Un paywall de base vous aide à savoir 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	Pourquoi cela compte
install ou ouvrez d'abord	Trafic de référence
onboarding_completed	Si les utilisateurs comprennent la configuration
core_action_completed	Si le produit offre de la valeur
paywall_viewed	Si les utilisateurs atteignent la monétisation
trial_started	Si l'offre est séduisante
purchase_completed	Conversion payante
restore_started et restore_completed	Acheter la récupération et passer en revue la conformité
subscription_status_checked	Fiabilité des droits
cancel_feedback_submitted	Raison de déchirure

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èle afin que les données soient lisibles.

Modèle	Bon ajustement	Première version
Freemium	Outils quotidiens, suiveurs, outils avec utilisation répétée	Action de base gratuite, limites payantes ou fonctionnalités premium
Paywall avec essai gratuit	Applications qui fournissent une valeur rapide après le processus d'inscription	Paywall après le processus d'inscription avec essai gratuit de 3 à 14 jours
Désactivation unique	Petits outils avec une valeur récurrente limitée	Produit à vie plus option de souscription future facultative

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

Configurez les produits pour l'apprentissage des revenus

Conservez les identifiants 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 cherchent, comme « Planificateur de repas Pro Mensuel » au lieu de seulement « Mensuel ». Les métadonnées et les noms de produits de magasin peuvent aider à la découverte et à la clarté.

Charger les données de produit des magasins afin que les prix, 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 prix de magasin dans l'interface utilisateur. Affichez product.priceStringtitre de produit localisé, la période de facturation et les termes de la période d'essai à partir des données de magasin chaque fois que possible.

Construire un premier mur payant

Un premier mur payant doit être clair, pas ingénieux :

• Titre : le résultat payant, tel que « Déverrouillez 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.
• CTA: « Démarrer la version d'essai » ou « Mise à niveau maintenant ».
• Liens : termes, politique de confidentialité, restauration d'achats et gestion d'abonnements.

Placez le premier mur de payement après l'inscription, une fois que l'utilisateur comprend ce que l'application fait. Plus tard, testez des déclencheurs supplémentaires tels que des limites d'utilisation, des appuis sur des fonctionnalités premium ou des actions de base terminé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,
  });
}

Validez toujours les achats sur votre serveur avant de concéder des droits d'accès durables. Gardez une cache de droits locaux pour une interface utilisateur rapide, mais traitez le magasin et votre serveur comme source de vérité.

Apportez les premiers utilisateurs

Le revenu a besoin de trafic. Commencez par les canaux qui peuvent fonctionner avant que vous n'ayez 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 bêta : TestFlight, Google Play internal testing, Discord et forums de niche.

Chaque canal devrait envoyer les utilisateurs dans le même tube mesuré afin que vous puissiez comparer la rétention, les vues de la paroi payante, les essais et les achats.

Lisez la chute correctement

Quelques départs signifient 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 l'essai : valeur incertaine, onboarding défectueux ou trafic incorrect.
• Annulations après un cycle : pas assez de valeur répétitive ou boucle de habitude faible.
• Remboursements : incohérence de tarifs, risque d'achat accidentel ou conditions non claires.
• Aucun rétablissement : gestion de l'entitlement brisée ou interface de rétablissement manquante.

Ajoutez un sondage d'annulation à une seule question lorsque possible. Utilisez les réponses pour améliorer l'onboarding, la portée des fonctionnalités, les captures d'écran du magasin et le texte de la paroi payante.

Liste de lancement

• Le produit résout un problème payant clair.
• Les produits de la boutique sont actifs et testés sur iOS et Android.
• Le mur de payement affiche les prix et les conditions de la boutique chargés.
• Acheter, restaurer, gérer l'abonnement et valider l'arrière-plan 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 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 la Revenue Playbook

Si vous utilisez Revenue Playbook pour planifier les paiements et les achats, connectez-le avec 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/achats natifs pour le détail d'implémentation dans @capgo/achats natifs, et Démarrage pour le détail d'implémentation dans Démarrage.