Livres de revenus

Seul l'achat SDK est 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 vous enseigne ce que les gens sont prêts à acheter.

Utilisez ce livre d'or lors de l'ajout de souscriptions ou d'éléments premium avec @capgo/native-purchases.

Commencez par un objectif de revenus simple

Faites de l'objectif initial 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 de la chronologie

Ces nombres 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

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

2. Vérifier la demande dans les magasins

   Rechercher sur l'App Store et Google Play le mot-clé principal. Lire les critiques bas et moyennes des applications concurrentes pour trouver des fonctionnalités manquantes, une onboarding confusante, des plaintes de tarification et des obstacles dans l'interface utilisateur.

3. Lancer 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. Ajouter des 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.

Instrumenter le tunnel avant d'optimiser

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

Événement	Pourquoi 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 de l'achat et conformité de la revue
subscription_status_checked	Fiabilité de l'entitlement
cancel_feedback_submitted	Raison de la dérive

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èle pour 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 l'inscription	Paywall après l'inscription avec essai gratuit de 3 à 14 jours
Désactivation unique	Petits outils avec une valeur récurrente limitée	Produit à vie plus abonnement facultatif ultérieur

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

Configurez les produits pour l'apprentissage du chiffre d'affaires

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 ligne peuvent aider à la découverte et à la clarté.

Chargez les données de produit à partir 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'));

N'insérez jamais les prix de magasin en dur dans l'interface utilisateur. Affichez-les product.priceStringCréez un premier mur payant

Section intitulée « Créez un premier mur payant »

Titre : le résultat payant, tel que « Débloquez 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 qu'il s'est terminé.
• CTA : « Démarrer l'essai gratuit » ou « Passer à l'acte maintenant ».
• Liens : conditions d'utilisation, politique de confidentialité, restaurer les achats et gérer les abonnements.
• Placez le premier mur payant après le processus d'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 touches de fonctionnalités premium ou des actions de noyau terminées.

Utilisez les informations de données de magasin pour récupérer le titre du produit localisé, la période de facturation et les termes de l'essai chaque fois que possible.

Créez un premier mur payant

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 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é.

Accueillez les premiers utilisateurs

Le revenu nécessite du 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 au lieu d'une publicité.
• Groupes bêta : TestFlight, Google Play testing interne, Discord et forums de niche.

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

Lisez correctement le déchirement

Certains churns 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 :

• Annulation pendant la période d'essai : valeur incertaine, onboarding défectueux ou trafic incorrect.
• Annulation après un cycle : valeur de répétition insuffisante ou boucle de habitude faible.
• Remboursements : incohérence de prix, risque d'achat accidentel ou conditions non claires.
• Pas de restauration : 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, la portée des fonctionnalités, les captures d'écran du magasin et le texte de la barrière de paiement.

Liste de vérification 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.
• L'achat, la restauration, la gestion de l'abonnement et la validation back-end sont mis en œuvre.
• Les événements de canalisation 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 la lancement.
• Les retours d'expérience de défaillance sont collectés des premiers abonnés.

Guides connexes

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