Plan de revenus

L’achat SDK est qu'une partie de gagner de l'argent à partir d'une application. Le revenu provient 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 plan lors de l'ajout de souscriptions ou de déverrouillages premium avec @capgo/native-purchases.

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

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

Construisez 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 de travail pour de nouveaux parents, un gestionnaire 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

   Search App Store and Google Play for the core keyword. Read low and mid-score reviews of competing apps to find missing features, confusing onboarding, pricing complaints, and UI friction.

3. Expédiez un MVP étroit

   La première version devrait inclure l'inscription, une action de base utile, 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 à 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	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é des achats
subscription_status_checked	Fiabilité des droits
cancel_feedback_submitted	Raison de déchiffrement

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 gratuite de base, limites payantes ou fonctionnalités premium
Mur de payement 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
Un verrouillage unique	Petits outils avec une valeur récurrente limitée	Produit à vie plus option de souscription facultative 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

Maintenez 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 produits de magasin peuvent aider à la découverte et à la clarté.

Charger les données de produit des magasins pour que les prix, les devises 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'));

Never hardcode store pricing in the UI. Render product.priceString, titre de produit localisé, période de facturation et conditions 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.
• Démarrer une évaluation gratuite ou Mise à niveau maintenant.
• Links: terms, privacy policy, restore purchases, and manage subscriptions.

Place the first paywall after onboarding, once the user understands what the app does. Later, test additional triggers such as usage limits, premium feature taps, or completed core actions.

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 une interface rapide, mais traitez la boutique et votre serveur comme source de vérité.

Apportez les premiers utilisateurs

Le revenu nécessite du trafic. Commencez par les canaux qui fonctionnent avant d'avoir une marque :

• ASO : titre, sous-titre, mots-clés, captures d'écran, description de l'application, icône, notes et noms de produits intégrés.
• 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 bêta : TestFlight, Google Play testing interne, Discord et forums de niche.

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

Comprenez correctement le déclin.

Certains déclins 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, mauvaise prise en charge ou mauvaise publicité.
• Annulations après un cycle : pas assez de valeur répétitive ou faible boucle de habitude.
• Remboursements : incohérence de tarifs, risque d'achat accidentel ou conditions d'utilisation floues.
• Pas de rétablissements : gestion de droits brisée ou interface de rétablissement manquante.

Add a one-question cancellation survey when possible. Use the answers to improve onboarding, feature scope, store screenshots, and paywall copy.

Liste de lancement

• L'application 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 de magasin chargés.
• 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 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.
• La feedback de dérive est collectée auprès des premiers abonnés.

Liens connexes

• Getting started
• 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 Plan de revenus pour planifier les paiements et les achats, connectez-l’avec En utilisant @capgo/achats natifs pour la capacité native en En utilisant @capgo/achats natifs, Capgo Tarification pour le flux de travail du produit dans Capgo Tarification, Système de paiement pour les détails d'implémentation dans le système de paiement, @capgo/achats natifs pour les détails d'implémentation dans @capgo/achats natifs, et Prise en main pour les détails d'implémentation dans Prise en main.