Saltare al contenuto

Revenue Playbook

GitHub

Libro delle entrate per acquisti in-app

La compravendita 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 archivio 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.

Fai che il primo obiettivo sia concreto. Ad esempio:

Prezzo mensileSottoscrittori attivi necessari per circa $1K MRR
$4.99201
$7.99126
$9.99101
29,99 dollari all'anno Circa 400 sottoscrittori annuali, a seconda del timing

I numeri sono prima delle commissioni di negozio, 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

    Costruisci intorno a un risultato 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.

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

Sottotitolo: "Instrumenta il funnel prima di ottimizzare"

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

EventoPerché è importante
install o apri per primoTraffico di base
onboarding_completedSe gli utenti capiscono la configurazione
core_action_completedSe il prodotto fornisce valore
paywall_viewedSe gli utenti raggiungono la monetizzazione
trial_startedSe l'offerta è convincente
purchase_completedConversione a pagamento
restore_started e restore_completedRecupero dell'acquisto e conformità alla revisione
subscription_status_checkedAffidabilità dell'entitazione
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 una prova, migliora l'offerta, la prova o la presentazione del prezzo.

Inizia con un modello per rendere i dati leggibili.

ModelloBuon adattamentoPrima versione
Monetizzazione a base di abbonamentoStrumenti utilizzati quotidianamente, tracker, strumenti con uso ripetutoAzione gratuita con limiti o funzionalità premium a pagamento
Paywall con prova gratuita di 1-14 giorniApp che forniscono un valore rapido dopo l'accesso inizialePaywall dopo l'accesso iniziale con prova gratuita di 3-14 giorni
Attivazione una volta solaPiccoli strumenti con valore ricorrente limitatoProdotto a vita più opzione di sottoscrizione futura in seguito

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 sottoscrizioni. Aggiungi prezzi localizzati dopo aver visto traffico significativo da un paese.

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 del negozio e dei prodotti per l'acquisto 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 mai i prezzi del negozio nella UI. Visualizza product.priceStringCostruiamo un primo muro di pagamento

Sottosezione intitolata “Costruiamo un primo muro di pagamento”

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

Sottotitolo: l'outcomet 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 saldi annuali reali se offerti.
  • Prova gratuita: lunghezza della prova gratuita e cosa accade dopo che finisce.
  • CTA: “Inizia prova gratuita” o “Aggiorna ora”.
  • Collegamenti: termini, politica sulla privacy, ripristina acquisti e gestisci abbonamenti.
  • Collocare il primo muro di pagamento dopo l'onboarding, una volta che l'utente capisce cosa fa l'app. In seguito, testare trigger aggiuntivi come limiti di utilizzo, tocchi di funzionalità premium o azioni core completate.

Acquista e ripristina flusso

Costruiamo un primo muro di pagamento dopo l'onboarding, una volta che l'utente capisce cosa fa l'app. In seguito, testare trigger aggiuntivi come limiti di utilizzo, tocchi di funzionalità premium o azioni core completate.

Sezione intitolata “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 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à.

Il reddito richiede 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 cosa hai costruito come storia utile invece di un annuncio.
  • Gruppi beta: TestFlight, Google Play testing interno, Discord e forum niché.

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

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

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

Aggiungi un sondaggio 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 della paywall.

  • 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.
  • L'acquisto, la ripristino, la gestione della sottoscrizione e la validazione del backend sono implementati.
  • Gli eventi di funnel vengono tracciati dalla prima apertura all'acquisto.
  • I metadati dello store dell'app spiegano il valore nelle prime schermate.
  • Almeno un canale di acquisizione è attivo prima del lancio.
  • Il feedback di churn viene raccolto dai primi sottscriventi.

Se stai utilizzando Revenue Playbook per pianificare pagamenti e acquisti, connettilo con Utilizza @capgo/native-purchases per la capacità nativa in Utilizza @capgo/native-purchases, Capgo Pricing per il workflow 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.