Per quale evento dovrebbe ottimizzare una subscription app?

Meta vuole circa 50 eventi per ad set a settimana. Google vuole dieci utenti al giorno. Il tuo evento di acquisto scatta 17 volte.

L’evento per cui ottimizzi decide quali utenti ottieni. Mandi install e la piattaforma trova persone che installano. Mandi trial start e trova persone che iniziano trial. Mandi acquisti e trova buyer, ma solo se ne vede abbastanza da poter imparare.

Quest’ultima clausola è dove la maggior parte degli account subscription si rompe. L’evento di acquisto è quello che corrisponde alle tue unit economics. È anche quello che scatta meno spesso. Quindi i team o lo scelgono e affamano l’algoritmo, oppure tornano agli install e riempiono il funnel di persone che non aprono mai il paywall.

C’è una regola che risolve questo problema. Prima della regola, i numeri.

Cosa serve a ciascuna piattaforma prima di poter imparare

Queste soglie sono state verificate sulle pagine di aiuto di ciascuna piattaforma il 23 settembre 2026, quella di Meta il 24 settembre. Cambiano. La data conta più del numero.

Da questa tabella emergono due cose.

Le soglie non sono le stesse tra piattaforme, quindi “50 a settimana” è un numero di Meta, non una legge. Lo uso come soglia minima per quante campagne può reggere un account, ed è una soglia per imparare, non per fidarsi di un risultato. Un annuncio aveva bisogno di 50 o più acquisti prima che il suo ROAS predicesse la settimana successiva, e anche allora solo in modo moderato.

E Apple Ads sta completamente fuori da questa decisione. La domanda sull’evento riguarda Meta, Google e TikTok.

L’evento che scegli è l’utente che ottieni

La piattaforma fa esattamente quello che le dici. Sposta un account dall’ottimizzazione per acquisto a quella per trial perché il volume di acquisti per ad set è troppo basso, e il costo per trial di solito scende. Spesso scende anche il tasso da trial a pagamento, e il costo per abbonato pagante può salire. La piattaforma ha trovato persone che iniziano trial, e alcune di quelle persone iniziano trial ovunque.

I dati 2026 di RevenueCat mostrano perché questo colpisce di più sui trial brevi. Tra le app con trial di tre giorni, il 55,4% delle cancellazioni di trial avviene al giorno 0, e l’84% entro il giorno 1. Una campagna ottimizzata per trial può sembrare eccellente martedì ed essere inutile giovedì, e la piattaforma non vede mai la differenza perché la cancellazione non è un evento contro cui ottimizza. Se il trial abbia davvero un posto nel funnel è una domanda a sé.

Perché l’evento più profondo di solito è la scelta sbagliata all’inizio

L’acquisto è l’evento che corrisponde al tuo conto economico. Se potessi sempre ottimizzare per quello, lo faresti.

Di solito non puoi, per due motivi.

Volume. Prendi una subscription app illustrativa e segui i suoi primi pagamenti fino all’ad set.

Aritmetica illustrativa, non un account. Presume che ogni dollaro sia un nuovo primo pagamento di un piano annuale da 60 $ e una suddivisione uniforme tra gli ad set. I tuoi numeri veri vanno al suo posto. La struttura conta quanto la spesa nel decidere se l’evento profondo è utilizzabile.

Ritardo. Il primo pagamento di un trial di sette giorni cade al giorno 7 o 8, e su iOS, per gli utenti che hanno rifiutato il tracking, il postback che lo riporta arriva alla piattaforma giorni dopo. La piattaforma sta imparando da un segnale che descrive cosa hai comprato la settimana scorsa. I parametri di valore predetto di Meta e il value bidding di Google esistono per accorciare quel ritardo, e funzionano solo se la previsione è stata verificata su coorti che sono davvero maturate. È lì che la value optimization va storta quando la attivi troppo presto. Che SKAN riesca a riportare il pagamento dopo un trial dipende dalla durata del trial, e ne parlo in SKAN può misurare il pagamento di una subscription dopo la fine del trial gratuito.

Quindi l’evento più profondo è il traguardo, non il punto di partenza.

La regola

Ottimizza per l’evento più profondo che sia abbastanza frequente da superare la soglia della piattaforma al tuo budget, abbastanza tempestivo da arrivare entro la finestra di apprendimento, e abbastanza predittivo che migliorarlo migliori gli abbonati paganti.

Tutte e tre le condizioni insieme. Un evento frequente che non predice i paganti è una trappola. Un evento predittivo che scatta 17 volte a settimana è un blocco.

In pratica significa seguire una scala.

Solo Meta, Google e TikTok. Apple Ads resta fuori dalla scala, come mostra la tabella delle piattaforme. Quale modalità di bidding si adatta a quale app è una decisione separata dall’evento. Nelle campagne iOS che usano Aggregated Event Measurement, Meta deve anche segnare l’evento come idoneo prima che tu possa ottimizzare su di esso, e perché gli eventi trial e purchase tornano come non idonei copre i controlli.

Il test per il passaggio 2 è semplice. Estrai coorti abbastanza vecchie da avere 60 giorni di revenue. Confronta il tasso da trial a pagamento e la revenue a 60 giorni per install tra gli utenti che hanno fatto scattare l’evento candidato e quelli che non l’hanno fatto. Se il divario è piccolo, l’evento non sta qualificando nessuno. Scegline un altro. Se il divario è ampio, confermalo su un set di coorti successivo prima di farci bidding. Un evento può predire i paganti senza che farci bidding te ne porti di più. Su un account il valore al giorno zero ha predetto il ROAS D28 meglio di quanto abbia fatto il costo per acquisto, ed è il tipo di verifica che ti dice se un segnale merita di essere usato per ottimizzare.

L’errore che sembra un successo

I trial economici sono il caso classico. Un costo per trial di 10 $ con un tasso di cancellazione dell’85% al giorno 0 è peggio di un costo per trial di 30 $ con un tasso di cancellazione normale. La dashboard dice che la prima campagna sta vincendo. Il conto in banca dice il contrario, sei settimane dopo.

Il secondo errore è più silenzioso. I team scelgono l’ottimizzazione per acquisto, la guardano restare in Apprendimento limitato per un mese, e concludono che Meta non funziona per loro. Funziona. Non ha mai ricevuto abbastanza dati per provarci.

Il terzo è consolidare gli ad set per superare la soglia e poi riframmentarli una settimana dopo per un test creativo. Ogni modifica significativa azzera il conto alla rovescia.

Quale tetto di CPA dovrebbe fissare una subscription app prima di aumentare il budget pubblicitario?

Non prendo il tetto da un benchmark. Lo ricavo dalle tue unit economics prima di spendere qualsiasi cosa, ovvero da quello che un abbonato pagante porta come proceeds dopo commissione dello store, tasse e rimborsi, meno i costi variabili per servirlo. La pagina Reconciling with App Store Financial Reports di RevenueCat separa così i proceeds dalla revenue, con tasse e commissione stimate (verificato il 29 settembre 2026). Il tetto è quindi un costo per abbonato pagante, e lo giudico su coorti abbastanza vecchie da mostrare quelle unit economics.

Se ottimizzi su un evento proxy, riportalo prima a costo per abbonato pagante, che è più o meno il costo per trial diviso per il tasso da trial a pagamento, preso da coorti abbastanza vecchie perché i loro trial abbiano già convertito.

Prima che il test parta, decidi il massimo che sei disposto a perderci. Quel numero, fissato in anticipo, decide quanta pazienza avere, non i primi giorni di risultati.

Poi controlla cosa conta l’evento ottimizzato. Di default, l’integrazione Meta Ads di RevenueCat invia Trial Converted, Initial Purchase e Renewal tutti come Subscribe (verificato il 29 settembre 2026). Un costo per Subscribe in Ads Manager può mescolare nuovi paganti e rinnovi, e quindi sembrare più basso di quanto sia davvero costato un nuovo pagante.

Aumento il budget solo finché il costo per abbonato pagante, a parità di età della coorte, resta sotto il tetto. Il calcolo, con un esempio svolto per una subscription app e uno per un gioco, è in come calcolare il tuo tetto di CPA.

Cosa questa pagina non può dirti

Non ho trovato un esperimento controllato pubblicato che tenga costanti audience, creative e spesa e confronti l’ottimizzazione per install, trial e acquisto sulla revenue subscription matura. Quello che esiste sono le indicazioni delle piattaforme, la ricerca sui proxy a breve termine per risultati a lungo termine, e i benchmark dei vendor. La regola sopra è un principio difendibile. Non è una legge di natura, e le soglie nella tabella saranno diverse tra sei mesi.

Quello che puoi fare è far girare la scala sulle tue coorti, confrontate alla stessa età di coorte, così non giudichi mai una coorte di una settimana rispetto a una di tre mesi.

Dove si trova il tuo account

Se il tuo evento di acquisto non supera la soglia e sei stato sull’ottimizzazione per trial per più di un trimestre, di solito è una conversazione di 90 minuti. Una sessione a pagamento di 90 minuti copre il tuo setup e cosa cambiare, e in quale ordine. La prenoti attraverso lo stesso calendario della chiamata introduttiva. Il quadro completo del paid UA per subscription app e cosa risolve la signal engineering si trovano nelle loro pagine dedicate.

Fonti e ambito

Le soglie delle piattaforme sono state verificate il 23 settembre 2026, la pagina di Meta il 24 settembre. Meta: Informazioni sulla fase di apprendimento, Meta Business Help Center; secondo questa pagina, gli ad set di solito escono dalla fase di apprendimento dopo circa 50 risultati nella settimana successiva all’ultima modifica significativa dell’ad set. Google: Guida alle best practice: impostare le tue App campaign e Configurare una App campaign per il ritorno sulla spesa pubblicitaria target, Google Ads Help. TikTok: Consigli per l’ottimizzazione basata sul valore per app, TikTok Business Help Center, aggiornato a maggio 2026. Apple: Best practice per Maximize Conversions, Apple Ads. Mappatura predefinita su Subscribe e definizione dei proceeds di RevenueCat: Meta Ads e Reconciling with App Store Financial Reports, RevenueCat Docs, entrambe verificate il 29 settembre 2026. Tempistiche di cancellazione dei trial: State of Subscription Apps 2026, RevenueCat, oltre 115.000 app, anno solare 2025, prodotto da RevenueCat; una distribuzione delle cancellazioni, non una quota su tutti i trialist. L’argomento sui risultati surrogati segue Athey, Chetty, Imbens e Kang, NBER Working Paper 26463, un working paper. L’esempio da 80K $ è aritmetica illustrativa, non un account.