Revenue Playbook

L'acquisto SDK è solo una parte della creazione di entrate da un'app. Le entrate provengono da un problema chiaro, un prodotto piccolo che gli utenti possono provare, una fatturazione di store affidabile e un paywall che insegna cosa le persone sono disposte a comprare.

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

Inizia con un obiettivo di entrate semplice

Fai che il primo obiettivo sia concreto. Ad esempio:

Prezzo mensile	Sottoscrittori attivi necessari per circa $1K MRR
$4.99	201
$7.99	126
$9.99	101
$29.99 all'anno	Circa 400 sottoscrittori annuali, a seconda del timing

Questi numeri sono prima delle commissioni dei store, 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 più piccolo a pagamento

1. Scegli un caso d'uso doloroso

   Costruisci intorno a un risultato 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 di prezzo e frizione dell'interfaccia utente.

3. Consegna un MVP stretto

   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 vendite presto

   Non aspettare fino a quando l'app non sembra completa. Una paywall base ti aiuta a capire se gli utenti comprendono il valore e se il prezzo è plausibile.

Insegna il canale prima di ottimizzarlo

Segui questi eventi prima di iniziare a modificare i prezzi o le schermate:

Evento	Perché conta
install o apri per primo	Traffico di base
onboarding_completed	Se gli utenti comprendono 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 recensione dell'acquisto
subscription_status_checked	Affidabilità dell'accesso
cancel_feedback_submitted	Motivo di abbandono

Se molti utenti non vedono la barriera del pagamento, risolvi l'onboarding prima di modificare la barriera del pagamento. Se gli utenti vedono la barriera del 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 per cui i dati siano leggibili.

Modello	Buon adattamento	Prima versione
Freemium	Utilità quotidiana, tracker, strumenti con uso ripetuto	Azione gratuita, limiti paganti o funzionalità premium
Paywall con prova gratuita	Applicazioni che forniscono un valore rapido dopo l'iscrizione	Paywall dopo l'iscrizione con prova gratuita di 3-14 giorni
Unico sblocco	Strumenti piccoli con valore ricorrente limitato	Prodotto a vita più opzione di sottoscrizione futura facoltativa

Evita di spedire tre livelli, molte offerte 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 prodotti per l'apprendimento dei ricavi

Mantieni stabili e leggibili gli identificatori dei prodotti:

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

Utilizza i nomi dei prodotti del negozio che rafforzano il valore che gli utenti stanno cercando, ad esempio “Meal Planner Pro Mensile” invece di solo “Mensile”. I nomi dei metadati e delle transazioni in-app possono aiutare la scoperta e la chiarezza.

Carica i dati dei prodotti dai negozi 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 codificare mai i prezzi dei negozi nella UI. Visualizza product.priceStringtitolo del prodotto localizzato, il periodo di fatturazione e le condizioni di prova dai dati del negozio ogni volta che è possibile.

Crea un primo paywall

Un primo paywall dovrebbe essere chiaro, non astuto:

• Titolo: l'esito a pagamento, ad esempio “Sblocca piani di allenamento illimitati”.
• Vantaggi: 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 è finita.
• CTA: “Inizia prova gratuita” o “Aggiorna ora”.
• Collegamenti: termini, politica sulla privacy, ripristino delle acquisizioni e gestione delle sottoscrizioni.

Colloca la prima barriera di pagamento dopo l'onboarding, una volta che l'utente comprende cosa fa l'app. In seguito, testa altri trigger come limiti di utilizzo, tocchi delle funzionalità premium o azioni di base completate.

Flusso 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 le acquisizioni sul tuo backend prima di concedere diritti duraturi. Conserva 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 di avere un marchio:

• ASO: titolo, sottotitolo, parole chiave, screenshot, descrizione dell'app, icona, voti e nomi delle acquisizioni 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 cosa hai costruito come storia utile invece di un annuncio.
• Gruppi di beta: TestFlight, Google Play internal testing, Discord, e forum di nicchia.

Ogni canale dovrebbe inviare gli utenti nello stesso canale misurato in modo che possiate confrontare la retention, le visualizzazioni del paywall, le prove e le vendite.

Leggi la churn correttamente

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

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

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

Elenco di controllo di lancio

• Il prodotto risolve un problema chiaro e pagato.
• I prodotti della store sono attivi e testati su iOS e Android.
• La paywall visualizza i prezzi e le condizioni caricati dalla store.
• Sono implementati acquisto, ripristino, gestione sottoscrizione e validazione backend.
• Vengono tracciati eventi di funnel dal primo apertura all'acquisto.
• I metadati dello store dell'app spiegano il valore nelle prime schermate.
• Attenzione: almeno un canale di acquisizione è attivo prima del lancio.
• Si raccoglie feedback di churn dai primi sottoscrittori.

Guida correlata

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

Continua da Revenue Playbook

Se stai utilizzando Revenue Playbook per pianificare pagamenti e acquisti, connettilo con Usando @capgo/native-purchases per la capacità nativa in Usando @capgo/native-purchases, Capgo Pricing per il workflow del prodotto in Capgo Pricing, Sistema di pagamento per il dettaglio di implementazione in Sistema di pagamento, @capgo/acquisti nativi per il dettaglio di implementazione in @capgo/acquisti nativi, e Avvio rapido per il dettaglio di implementazione in Avvio rapido.