Revenue Playbook
Copia un prompt di configurazione con i passaggi di installazione e la guida markdown completa per questo plugin.

L'acquisto SDK è solo una parte della creazione di ricavi 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 paywall che insegna cosa le persone sono disposte a comprare.
Usa questo libro delle strategie quando stai aggiungendo abbonamenti o sbloccaggi premium con @capgo/native-purchases.
Partenza con un obiettivo di ricavo semplice
Sezione intitolata “Partenza con un obiettivo di ricavo semplice”Rendere il primo obiettivo 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 della tempistica |
Questi numeri sono prima delle commissioni sui negozi, le tasse, i rimborsi e le 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 pagante più piccolo
Sezione intitolata “Costruisci il prodotto pagante più piccolo”-
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 tracciante di budget per coppie, uno scanner di ricevute per freelance, o un'app di esercizio linguistico per un esame.
-
Verifica la domanda nei negozi
Cerca App Store e Google Play per la parola chiave principale. Leggi le recensioni con punteggio basso e medio delle app concorrenti per trovare funzionalità mancanti, onboarding confuso, reclami sui prezzi e frizione dell'interfaccia utente.
-
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.
-
Aggiungi le vendite presto
Non aspettare fino a quando l'app non sembra completa. Un paywall base ti aiuta a capire se gli utenti comprendono il valore e se il prezzo è plausibile.
Instrumenta il funnel prima di ottimizzare
Sezione intitolata “Instrumenta il funnel prima di ottimizzare”Segui questi eventi prima di iniziare a modificare i prezzi o le schermate:
| Evento | Perché è importante |
|---|---|
install o prima di aprire per la prima volta | 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 dell'acquisto e conformità alla revisione |
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
Scegli un modello di monetizzazioneInizia con un modello per rendere i dati leggibili.
| Modello | Adatto | Prima versione |
|---|---|---|
| Freemium | Utilità quotidiana, tracker, strumenti con uso ripetuto | Azione gratuita, limiti paganti o funzionalità premium |
| Paywall con prova gratuita | App che forniscono un valore rapido dopo l'accesso | Paywall dopo l'accesso con prova gratuita di 3-14 giorni |
| Un tempo sblocca | Strumenti piccoli con valore ricorrente limitato | Prodotto a vita più abbonamento facoltativo in futuro |
Evita di spedire tre livelli di tariffa, molti pacchetti e percorsi di aggiornamento complessi già al primo giorno. Utilizza un piano mensile e un piano annuale quando hai bisogno di abbonamenti. Aggiungi prezzi localizzati dopo aver visto traffico significativo da un paese.
Configura i prodotti per l'apprendimento dei ricavi
Sezione intitolata “Configura i prodotti per l'apprendimento dei ricavi”Mantieni stabili e leggibili gli identificatori dei prodotti:
com.example.app.premium.monthlycom.example.app.premium.yearlycom.example.app.premium.lifetimeUtilizza 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 metadati del negozio e i nomi degli acquisti in-app possono aiutare la scoperta e la chiarezza.
Carica i dati dei prodotti dai negozi in modo che i prezzi, la valuta e gli offerti di introduzione 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 del negozio nella UI. Visualizza product.priceString, titolo del prodotto localizzato, periodo di fatturazione e termini di prova da dati del negozio ogni volta che è possibile.
Costruisci un primo muro di pagamento
Sottosezione intitolata “Costruisci un primo muro di pagamento”Un primo muro di pagamento dovrebbe essere chiaro, non astuto:
- Sottotitolo: l'esito pagato, 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 annuale reale se offerti.
- Prova: lunghezza di prova esatta e cosa accade 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'onboarding, una volta che l'utente capisce cosa fa l'app. In seguito, test ulteriori trigger come limiti di utilizzo, tocchi di funzionalità premium o azioni di base completate.
Ciclo di acquisto e ripristino
Sottosezione intitolata “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 le vendite 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
Sezione intitolata “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 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 cosa 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 canale misurato per poter confrontare la retention, le visualizzazioni della paywall, le prove e le vendite.
Leggi la fuga di utenti correttamente
Sezione intitolata “Leggi la fuga di utenti correttamente”Alcuni cambiamenti significativi indicano che gli utenti hanno provato l'app e hanno deciso che non era per loro. È normale. Ciò che conta è il pattern:
- Annulla durante la prova: valore incerto, onboarding scadente o traffico sbagliato.
- Annulla dopo un ciclo: valore di ripetizione insufficiente o ciclo di abitudine debole.
- Rimborso: incongruenza di prezzo, rischio di acquisto accidentale o termini non chiari.
- Nessuna ripristino: gestione di entità rotta o interfaccia di ripristino mancante.
Aggiungi un questionario di annullamento di una 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 controllo di lancio
Sezione intitolata “Elenco di controllo di lancio”- Il prodotto risolve un problema pagato chiaro.
- I prodotti dello store sono attivi e testati su iOS e Android.
- La paywall visualizza i prezzi e i termini caricati dallo store.
- Esegui l'acquisto, il ripristino, la gestione della sottoscrizione e la validazione del backend sono implementati.
- Gli eventi del funnel vengono tracciati dalla prima apertura all'acquisto.
- La metadata del negozio dell'app spiega il valore nelle prime schermate.
- Almeno un canale di acquisizione è attivo prima della lancio.
- La feedback di churn viene raccolta dai primi sottscriventi.
Guide correlate
Sezione intitolata “Guide correlate”Prosegui dal Revenue Playbook
Se continui con il "Piano di Gioco di Riscossione"Se stai utilizzando Piano di Gioco di Riscossione 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 la dettaglio di implementazione in @capgo/native-purchases Iniziare per i dettagli di implementazione in Iniziare.