Feuille de route 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 vous enseigne ce que les gens sont prêts à acheter.

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

Commencez par un objectif de revenu simple

Fixez un 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
Prix annuel de 29,99 $	Environ 400 abonnés annuels, en fonction de la date

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 grande audience.

Construire le produit payant le plus petit

1. Choisissez un cas d'utilisation douloureux

   Construire autour d'un résultat que les utilisateurs recherchent déjà. Exemples : un plan d'entraînement pour de nouveaux parents, un suivi de budget pour les couples, un scanner de factures pour les freelances, ou un jeu de drill 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 des utilisateurs avec des notes basses et moyennes pour trouver des fonctionnalités manquantes, une onboarding confusante, des plaintes de tarification et des obstacles dans l'interface utilisateur.

3. Lancez une MVP étroite

   La première version devrait inclure l'onboarding, une action utile principale, une gestion de base des erreurs 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 à 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	Pourquoi cela compte
install ou ouvrez d'abord	Trafic de référence
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 la revue de l'achat
subscription_status_checked	Fiableté des droits
cancel_feedback_submitted	Raison de rotation

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 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 un essai de 3 à 14 jours
Désactivation unique	Outils petits avec une valeur récurrente limitée	Produit à vie plus option de souscription future ultérieure

Évitez de livrer trois niveaux, 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 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é.

Charger les données de produit des magasins afin que les prix, la devise et les offres promotionnelles soient toujours précises :

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 codifiez jamais les prix des magasins dans l'interface utilisateur. Affichez product.priceString, titre de produit localisé, période de facturation et termes de période d'essai à partir des données du 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é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.
• CTA : « Démarrer l'essai gratuit » ou « Mettre à jour maintenant ».
• Liens : termes, politique de confidentialité, restauration des achats et gestion des abonnements.

Placez le premier mur payant après le processus d'accueil, une fois que l'utilisateur comprend ce que l'application fait. Plus tard, testez des déclencheurs supplémentaires tels que les limites d'utilisation, les appuis sur les 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,
  });
}

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

Apportez 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 vente 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é.
• Groupes de bêta : TestFlight, Google Play internal testing, Discord, et forums de niche.

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

Lire la dérive 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 la période d'essai : valeur incertaine, mauvaise prise en main 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 la prise en main, la portée des fonctionnalités, les captures d'écran du magasin et le texte de la paywall.

Liste de vérification de lancement

• Le produit résout un problème payant clair.
• Les produits de magasin sont actifs et testés sur iOS et Android.
• Le mur de paye affiche les prix et les conditions chargés dans le magasin.
• La mise en paiement, la restauration, la gestion de l'abonnement et la validation back-end sont mises en œuvre.
• Les événements de la truffe sont suivis de la première ouverture à la mise en paiement.
• 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 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 Utiliser @capgo/native-purchases pour la capacité native dans Utiliser @capgo/native-purchases, Capgo Pricing pour le flux de travail du produit dans Capgo Pricing, 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.