Revenue Playbook

La transazione SDK dell'acquisto è solo una parte di guadagnare denaro da un'app. I ricavi provengono da un problema chiaro, un prodotto piccolo che gli utenti possono provare, una fatturazione di archiviazione affidabile e un muro di pagamento che insegna cosa le persone sono disposte a comprare.

Usa questo playbook quando stai aggiungendo sottoscrizioni o sbloccaggi premium con @capgo/native-purchases.

Inizia con un obiettivo di ricavo semplice

Fai che il primo obiettivo sia concreto. Ad esempio:

Prezzo mensile	Sottoscrittori attivi necessari per circa 1.000 dollari di MRR
$4.99	201
$7.99	126
$9.99	101
29,99 dollari all'anno	Circa 400 sottoscrittori annuali, a seconda del timing

Questi numeri sono prima delle commissioni dei negozi, delle tasse, dei rimborsi e delle differenze di valuta. Sono ancora utili perché tengono il piano di lancio pratico: hai bisogno di poche centinaia di utenti motivati, non di un grande pubblico.

Costruisci il prodotto pagato più piccolo

1. Scegli un caso d'uso doloroso

   Costruisci intorno a un esito che gli utenti cercano già. Esempi: un piano di allenamento per genitori nuovi, un tracciato di budget per coppie, uno scanner di ricevute per freelance, o un'app di esercizi linguistici per un esame.

2. Controlla la domanda nei negozi

   Cerca l'App Store e Google Play per la parola chiave principale. Leggi le recensioni con voti bassi e medi delle app concorrenti per trovare funzionalità mancanti, onboarding confuso, reclami sui prezzi e frizione dell'interfaccia utente.

3. Invia un MVP ristretto

   La prima versione dovrebbe includere l'onboarding, un'azione utile principale, il trattamento di errori base e abbastanza analisi per vedere se gli utenti raggiungono il momento di valore.

4. Aggiungi le transazioni presto

   Non aspettare fino a quando l'app non si sente completa. Una paywall base ti aiuta a imparare se gli utenti capiscono il valore e se i tuoi prezzi sono plausibili.

Instrumenta il canale prima di ottimizzare

Traccia questi eventi prima di iniziare a cambiare prezzi o schermate:

Evento	Perché è importante
install Ecco il primo passo	Flusso di traffico di base
onboarding_completed	Se gli utenti capiscono la configurazione
core_action_completed	Se il prodotto fornisce valore
paywall_viewed	Se gli utenti raggiungono la monetizzazione
trial_started	Se l'offerta è convincente
purchase_completed	Conversione a pagamento
restore_started E restore_completed	Recupero e conformità della compravendita
subscription_status_checked	Affidabilità dell'entitazione
cancel_feedback_submitted	Motivo di abbandono

Se molti utenti non vedono la barriera di pagamento, risolvi l'onboarding prima di modificare la barriera di pagamento. Se gli utenti vedono la barriera di pagamento ma non iniziano una prova, migliora l'offerta, la prova o la presentazione del prezzo.

Scegli un modello di monetizzazione

Inizia con un modello affinché i dati siano leggibili.

Modello	Buon adattamento	Prima versione
Scegli un modello di monetizzazione	Freemium	Utilità, tracker, strumenti con uso ripetuto
Azione gratuita di base, limiti paganti o funzionalità premium	Paywall con prova gratuita	Applicazioni che forniscono un valore rapido dopo l'accesso iniziale
Abbinamento unico	Piccoli strumenti con valore ricorrente limitato	Prodotto a vita più opzione di sottoscrizione futura in seguito

Evita di spedire tre livelli, molti pacchetti e percorsi di aggiornamento complessi già al primo giorno. Utilizza un piano mensile e un piano annuale quando hai bisogno di sottoscrizioni. Aggiungi prezzi localizzati dopo aver visto traffico significativo da un paese.

Configura i prodotti per l'apprendimento dei ricavi

Conserva gli identificatori dei prodotti stabili e leggibili:

com.example.app.premium.monthly
com.example.app.premium.yearly
com.example.app.premium.lifetime

Utilizza i nomi dei prodotti delle store che rafforzino il valore che gli utenti stanno cercando, ad esempio “Meal Planner Pro Mensile” al posto di solo “Mensile”. I metadati e i nomi degli acquisti in-app possono aiutare la scoperta e la chiarezza.

Carica i dati dei prodotti dai store in modo che i prezzi, la valuta e le offerte introduttive siano sempre precisi:

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'));

Non hardcoded mai i prezzi delle store nella UI. Visualizza product.priceStringUtilizzare sempre i dati del negozio per localizzare il titolo del prodotto, il periodo di fatturazione e le condizioni di prova.

Costruisci un primo muro di pagamento.

Un primo muro di pagamento dovrebbe essere chiaro, non astuto:

• Sottotitolo: l'esito a pagamento, ad esempio “Sblocca piani di allenamento illimitati”.
• Benefici: 3 a 5 miglioramenti concreti, non una lunga lista di funzionalità.
• Piani: mensili e annuali, con salvezza reale annuale se offerti.
• Prova: lunghezza di prova esatta e cosa succede dopo che finisce.
• CTA: “Inizia prova gratuita” o “Aggiorna ora”.
• Collegamenti: termini, politica sulla privacy, ripristina acquisti e gestisci abbonamenti.

Colloca il primo muro di pagamento dopo l'accesso, una volta che l'utente capisce cosa fa l'app. In seguito, testa anche altri trigger come limiti di utilizzo, tocchi di funzionalità premium o azioni core completate.

Ciclo di acquisto e ripristino

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,
  });
}

Verifica sempre gli acquisti sul tuo backend prima di concedere diritti duraturi. Mantieni un cache di diritti locali per una UI veloce, ma considera il negozio e il tuo backend come fonte di verità.

Porta i primi utenti

Il reddito ha bisogno di traffico. Inizia con i canali che possono funzionare prima che tu abbia un marchio:

• ASO: titolo, sottotitolo, parole chiave, screenshot, descrizione dell'app, icona, voti e nomi degli acquisti in-app.
• Video corto: pubblica demo veloci, clip problema/soluzione e esempi prima/dopo per il paese di destinazione.
• Reddit e comunità: unisciti alla conversazione prima di condividere ciò che hai costruito come storia utile invece di un annuncio.
• Gruppi beta: TestFlight, Google Play testing interno, Discord e forum di nicchia.

Ogni canale dovrebbe inviare gli utenti nello stesso flusso misurato in modo che tu possa confrontare la retention, le visualizzazioni della paywall, le prove e gli acquisti.

Leggi correttamente la churn

Qualche churn significa che gli utenti hanno provato l'app e hanno deciso che non era per loro. È normale. Ciò che conta è il pattern:

• Annullamenti durante la prova: valore incerto, onboarding povero o traffico sbagliato.
• Annullamenti dopo un ciclo: valore di ripetizione insufficiente o ciclo di abitudine debole.
• Rimborsi: incongruenza di prezzo, rischio di acquisto accidentale o termini non chiari.
• Senza restauri: gestione di entità rotta o interfaccia di ripristino mancante.

Aggiungi un questionario di annullamento di una sola domanda quando possibile. Utilizza le risposte per migliorare l'onboarding, lo scope delle funzionalità, le schermate dello store e il testo della paywall.

Elenco di lancio

• Il prodotto risolve un problema pagato chiaro.
• Gli store dei prodotti sono attivi e testati su iOS e Android.
• La paywall visualizza i prezzi e i termini caricati dallo store.
• Acquisto, ripristino, gestione sottoscrizione e validazione backend sono implementate.
• Gli eventi di funnel vengono tracciati dalla prima apertura all'acquisto.
• I metadati delle app store spiegano il valore nelle prime schermate.
• Almeno un canale di acquisizione è attivo prima del lancio.
• La feedback di churn è raccolta dai primi sottoscrittori.

Guida correlata

• Inizio
• Crea sottoscrizioni iOS
• Crea sottoscrizioni Android
• Test sandbox iOS
• Test sandbox Android

Continua da Revenue Playbook

Se stai utilizzando Revenue Playbook per pianificare pagamenti e acquisti, connettilo con Utilizzando @capgo/native-purchases per la capacità nativa in Utilizzando @capgo/native-purchases, Capgo Pricing per il flusso di lavoro del prodotto in Capgo Pricing, Sistema di pagamento per la dettaglio di implementazione in Sistema di pagamento, @capgo/native-purchases per i dettagli di implementazione in @capgo/acquisti nativi, e Iniziare per i dettagli di implementazione in Iniziare.