Saltare al contenuto

Libro dei Ricavi

GitHub

Libretto dei ricavi per acquisti in-app

L'acquisto SDK è 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 ti insegna cosa le persone sono disposte a comprare.

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

Assicurati che il primo obiettivo sia concreto. Ad esempio:

Prezzo mensileSottoscrittori attivi necessari per circa 1.000 dollari MRR
$4.99201
$7.99126
$9.99101
29,99 dollari all'anno Circa 400 sottoscrittori annuali, a seconda della tempistica

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.

  1. Scegli un caso d'uso doloroso

    Scegli 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 specifico.

  2. Verifica la domanda nei negozi

    Cerca l'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.

  3. Consegna un MVP ristretto

    La prima versione dovrebbe includere l'onboarding, un'azione utile principale, il trattamento degli 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 imparare se gli utenti capiscono il valore e se il prezzo è plausibile.

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

EventoPerché è importante
install o prima aperturaFlusso di traffico di base
onboarding_completedSia i utenti a conoscenza della configurazione
core_action_completedSia il prodotto in grado di fornire valore
paywall_viewedSia i utenti a raggiungere la monetizzazione
trial_startedSia l'offerta convincente
purchase_completedConversione a pagamento
restore_started e restore_completedRecupero e conformità della recensione dell'acquisto
subscription_status_checkedAffidabilità dell'entitlamento
cancel_feedback_submittedMotivo 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 un trial, migliora l'offerta, la prova o la presentazione del prezzo.

Scegli un modello di monetizzazione

Scegli un modello di monetizzazione

Inizia con un modello per rendere i dati leggibili.

ModelloBuon adattamentoPrima versione
FreemiumStrumenti quotidiani, tracciatori, strumenti con uso ripetutoUtilità, tracker, strumento con uso ripetuto giornaliero
Barriera di pagamento con prova gratuitaApplicazioni che forniscono un valore rapido dopo l'iscrizioneApplicazioni che forniscono un valore rapido dopo l'accesso
Blocco di attivazione unicoStrumenti piccoli con valore ricorrente limitatoProdotto 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.

Tieni 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 della store che rafforzano il valore che gli utenti stanno cercando, ad esempio “Meal Planner Pro Mensile” al posto di solo “Mensile”. I metadati della store 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 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 i prezzi della store nella UI. Visualizza product.priceString, titolo del prodotto localizzato, periodo di fatturazione e termini di prova da dati dello store ogni volta possibile.

Costruisci un primo muro di pagamento

Costruire un primo muro di pagamento

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

  • Sottotitolo: l'outcomes pagati, ad esempio “Sblocca piani di allenamento illimitati”.
  • Benefici: 3 a 5 miglioramenti concreti, non una lunga lista di funzionalità.
  • Piani: mensili e annuali, con salvezze annuali reali 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'onboarding, una volta che l'utente capisce cosa fa l'app. In seguito, testa trigger aggiuntivi come limiti di utilizzo, tocchi di feature premium o azioni core completate.

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 transazioni 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à.

Ricavi richiedono 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 transazioni 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 di misurazione affinché possiate confrontare la retention, le visualizzazioni del paywall, le prove e le vendite.

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: non abbastanza valore ripetuto 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 sondaggio di cancellazione a una domanda quando possibile. Utilizza le risposte per migliorare l'onboarding, la portata delle funzionalità, le schermate dello store e il testo della paywall.

Elenco di controllo di lancio

Section titled “Launch checklist”
  • Il prodotto risolve un problema pagato chiaro.
  • Gli store dei prodotti sono attivi e testati su iOS e Android.
  • Visualizza pagamenti mostra prezzi e termini caricati dal negozio.
  • Esegui acquisto, ripristino, gestisci sottoscrizione e validazione backend.
  • Eventi di flusso vengono tracciati dalla prima apertura all'acquisto.
  • La metadata del negozio di app spiega il valore nelle prime schermate.
  • Attenzione: almeno un canale di acquisizione è attivo prima del lancio.
  • La feedback di churn viene raccolta dai primi sottscriventi.

Continua dall'estratto del Revenue Playbook

Sezione intitolata “Continua con il Revenue Playbook”

Se stai utilizzando Libro dei Rendimenti per pianificare pagamenti e acquisti, connettilo con Utilizzando @capgo/native-purchases per la capacità nativa in Utilizzando @capgo/native-purchases, Prezzi di Capgo per il workflow del prodotto in Capgo Pricing, Sistema di pagamento per il dettaglio di implementazione in Sistema di pagamento, @capgo/native-purchases per il dettaglio di implementazione in @capgo/native-purchases, e Getting Started per i dettagli di implementazione in Avvio.