Cahier des charges de revenus

La vente SDK est qu'une partie de gagner de l'argent à partir d'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 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 du calendrier

Ces chiffres 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.

Construire 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 suivi 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 des applications concurrentes avec des notes basses et moyennes 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 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 à savoir 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	Pourquoi cela compte
install 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 de l'achat et conformité à 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 d'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 gratuite de base, limites payantes ou fonctionnalités premium
Paywall avec essai gratuit	Applications qui délivrent une valeur rapide après l'abonnement	Paywall après l'abonnement 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 lancement. 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 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 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'));

N'insérez jamais les tarifs 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é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 l'essai gratuit » ou « Passer à l'étape supérieure ».
• Liens : conditions d'utilisation, politique de confidentialité, restaurer les achats et gérer les abonnements.
• Placez le premier mur payant 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 complétées.

Utilisez les informations de magasin pour récupérer le titre du produit, 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,
  });
}

Validez toujours les achats sur votre serveur avant de concéder des droits durables. Gardez une cache de droits locaux pour une interface 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 :

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

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

Lisez correctement le déclin

Certain churn 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, 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 rétablissement : gestion de droits 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 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 backend 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'app store 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 clients sont collectés des premiers abonnés.

Guides connexes

• Prise en main
• Créer des abonnements iOS
• Créer des abonnements Android
• Test de sandbox iOS
• Test de sandbox Android

Continue de la feuille de route des revenus

Si vous utilisez Feuille de route des revenus pour planifier les paiements et les achats, connectez-le avec En utilisant @capgo/native-purchases pour la capacité native en 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.