Livre de bord des revenus

L'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 livre de planification 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 date

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

Construirez le produit payant le plus petit

1. Choisissez une utilisation pénible

   Construit autour d'un résultat 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 confuse, 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, un traitement d'erreur 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 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 ouvrir d'abord	Le 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	La conversion payante
restore_started et restore_completed	La récupération et la conformité de l'achat
subscription_status_checked	La fiabilité de l'entitlement
cancel_feedback_submitted	La raison de la défaillance

Si beaucoup d'utilisateurs ne voient pas le mur de payement, corrigez la phase d'abord 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è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 fournissent une valeur rapide après l'inscription
Un verrouillage unique	Petits outils avec une valeur récurrente limitée	Produit à vie plus abonnement facultatif ultérieur

É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 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 identificateurs 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 fixez jamais les tarifs de magasin dans l'interface utilisateur. Affichez product.priceStringUtilisez les informations de produit localisées, la période de facturation et les termes de la période d'essai à partir des données de magasin chaque fois que possible.

Construirez la première barrière payante.

La première barrière payante doit être claire, pas ingénieuse :

• En-tête : le résultat payant, tel que « Désbloquez 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 « Mise à niveau maintenant ».
• Lien : conditions, politique de confidentialité, restauration des achats et gestion des abonnements.

Placez la première barrière payante 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 appels de fonctionnalités premium ou des 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 durables. Gardez une cache de droits locaux pour une interface rapide, mais considérez le magasin et votre serveur comme la source de vérité.

Apporter 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 au lieu d'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 de payement, les essais et les achats.

Lire la dérive correctement

Le dégonflement 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 l'entitlement endommagée ou interface de rétablissement manquante.

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

Liste de lancement

• Le produit résout un problème payant clair.
• Les produits de l'application sont actifs et testés sur iOS et Android.
• La barrière de paiement affiche les prix et les conditions chargés par l'application de magasin.
• Les achats, la restauration, la gestion de l'abonnement et la 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'application 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 d'abandon sont collectés auprè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

Continuez de là du Cahier des charges des revenus

Si vous utilisez Le 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.