Livre des revenus

La vente SDK est seulement une partie de gagner de l'argent avec une application. Les revenus proviennent d'un 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.

Construirez le produit payant le plus petit

1. Choisissez une utilisation pénible

   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 reçus 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, 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

   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 vos tarifs sont plausibles.

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 ouvrir 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éfaillance

Si beaucoup d'utilisateurs ne voient pas le mur payant, corrigez l'inscription avant de modifier le mur payant. Si les utilisateurs voient le mur payant 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
Contexte : Page/zone : Capgo Builder / page de produit de build cloud natif. Rôle : Petit élement de navigation ou d'interface utilisateur. Message clé `native_build_builder_credit_first` (Premier crédit du buildur natif).	Freemium	Utilitaires, suiveurs, outils avec utilisation répétée
Action gratuite de base, limites payantes ou fonctionnalités premium	Paywall avec essai gratuit	Applications qui délivrent une valeur rapide après l'inscription
Un verrouillage unique	Petits outils avec une valeur récurrente limitée	Produit à vie plus option de souscription facultatif ultérieure

Évitez de livrer trois niveaux, de nombreux lots 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 souscriptions. 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 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 recherchent, comme “Meal Planner Pro Mensuel” au lieu de seulement “Mensuel”. Les métadonnées et les noms de vente en magasin 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 codez jamais les tarifs de magasin dans l'interface utilisateur. Affichez product.priceStringlocaliser le titre du produit, la période de facturation et les termes de la période d'essai à partir des données du magasin chaque fois que possible.

Construire un premier mur de payement

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

• Sous-titre : le résultat payant, tel que « Désbloquer 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 « Mettre à jour maintenant ». 
• Lien : conditions, politique de confidentialité, restaurer les achats et gérer les abonnements.

Placer le premier mur de payement après l'inscription, une fois que l'utilisateur comprend ce que l'application fait. Plus tard, tester d'autres déclencheurs tels que les limites d'utilisation, les touches de fonctionnalités premium ou les 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,
  });
}

Validez toujours les achats sur votre serveur avant de concéder des droits durables. Gardez une cache de droits locaux pour un affichage 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 de vote 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 que vous puissiez comparer la rétention, les vues de la barrière payante, les essais et les achats.

Lisez correctement la dérive

Le déclin de certains utilisateurs signifie qu'ils 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, mauvaise prise en charge 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 redémarrage : gestion de l'entitlement brisée ou interface de redémarrage manquante.

Ajoutez un sondage d'annulation d'une seule question lorsque possible. Utilisez les réponses pour améliorer la prise en charge, la portée des fonctionnalités, les captures d'écran du magasin et le texte de la barrière de paiement.

Liste de lancement

• Le produit résout un problème payant clair.
• Les produits du magasin sont actifs et testés sur iOS et Android.
• La barrière de paiement affiche les prix et les conditions chargés par le magasin.
• 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 du magasin d'applications expliquent la valeur dans les premières captures d'écran.
• Au moins un canal d'acquisition est actif avant le lancement.
• Les retours d'information sur le taux de rotation 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.