SKAN può misurare il pagamento di un abbonamento dopo il trial?

A volte, e solo come coarse value (low, medium o high), mai come fine value. L’addebito dopo un free trial avviene lato Apple e arriva a RevenueCat server to server, mentre SKAN registra solo ciò che l’app scrive sul dispositivo. Quindi il pagamento conta solo se il tuo unico writer del conversion value gira nell’app prima che si chiuda la finestra in cui cade. La durata del trial cambia la risposta. Senza trial il primo pagamento può cadere nella prima finestra come fine value. Il free trial più breve che Apple offre (3 giorni) lo spinge già nella seconda finestra e uno di 1 settimana di solito nella terza, in entrambi i casi solo coarse. Un trial che finisce dopo il giorno 35 manca tutte le finestre.

Ambito: subscription app iOS con RevenueCat, un MMP (AppsFlyer e Singular sono i due di cui ho verificato le regole di relay) o Firebase, su SKAdNetwork 4 e AdAttributionKit, che comprano su Meta e Google, in tutte le regioni. Ho verificato ogni fatto sulla pagina del vendor stesso il 1 ottobre 2026.

Cosa succede tra “RevenueCat ha registrato il pagamento” e “il dispositivo ha aggiornato il valore”?

Sei passaggi, e il vuoto sta tra il terzo e il quinto.

1. Primo avvio. L’orologio di Apple parte da qui. La pagina SKAdNetwork Receiving postbacks in multiple conversion windows fissa tre finestre a partire dal primo avvio: giorni da 0 a 2, da 3 a 7 e da 8 a 35. Solo il primo postback può portare un fine value, che il metodo di aggiornamento di Apple definisce come un numero da 0 a 63.
2. Inizio del trial. Di solito sul paywall nella prima sessione, dentro la finestra 1, dove l’SDK sul dispositivo lo vede.
3. Pagamento confermato. Quando il trial finisce, l’App Store addebita. La pagina Event Types and Fields di RevenueCat riporta un primo addebito riuscito come un RENEWAL con is_trial_conversion impostato su true. Un trial che nessuno ha annullato non è un pagamento, e non lo è nemmeno un entitlement attivo. La pagina di Apple Reducing involuntary subscriber churn dice che un rinnovo fallito entra in billing retry per un massimo di 60 giorni, e con Billing Grace Period attivo l’utente mantiene l’accesso completo mentre Apple prova a incassare.
4. Relay dal server. RevenueCat invia l’evento all’MMP server to server. La pagina SKAN Conversion Studio di AppsFlyer dice che AppsFlyer ricalcola il valore e che l’SDK aggiorna il dispositivo se l’app è aperta. Altrimenti il server aspetta la prossima apertura dell’app, che deve arrivare prima che la finestra scada, o l’evento viene ignorato. La S2S Support for Conversion Models FAQ di Singular descrive la stessa attesa per una funzione che chiedi a Singular di attivare. Funziona solo in modalità SKAN managed, e se la finestra si chiude o l’utente non riapre mai l’app, Singular non può aggiornare il valore.
5. Esecuzione sul dispositivo. L’SDK chiama il metodo di aggiornamento di Apple. Il valore finisce nella finestra aperta in quel momento, non in quella in cui è avvenuto l’addebito. La pagina updatePostbackConversionValue di Apple dice che il fine value viene ignorato dopo la prima finestra.
6. Postback. Chiusa la finestra, Apple invia il postback con un ritardo casuale: da 24 a 48 ore per il primo, da 24 a 144 ore per il secondo e il terzo. Apple dice anche che l’app deve aggiornare il valore durante ciascuna finestra per avere diritto a più di un postback, quindi un utente che non apre mai l’app tra il giorno 3 e il giorno 7 lascia la finestra 2 senza niente da riportare. Un annuncio nel tier più basso di Apple, il Tier 0, non riceve nessun secondo o terzo postback.

Chi scrive il conversion value?

Un solo writer, sul dispositivo. Ogni metodo di aggiornamento che Apple documenta è una chiamata fatta dall’app. Non ho trovato nessuna API lato server.

RevenueCat non è quel writer. La sua pagina Meta Ads dice che “doesn’t update SKAN conversion values” e consiglia un solo updater, che sia l’app, il Meta SDK o un MMP, così i valori non entrano in conflitto. La sua pagina Singular dice che non può modificarli dai suoi eventi server. La sua pagina AppsFlyer ti dice anche di rimuovere il tracking di revenue lato client per evitare il doppio conteggio, il che significa che con questo setup anche un acquisto del giorno 0 può arrivare all’SDK di AppsFlyer solo tramite il relay dal server.

Un secondo writer è l’errore da cui i vendor mettono in guardia. La pagina di Google Set up your SKAdNetwork conversion value schema dice che è fortemente consigliato configurare lo schema in un unico posto. La versione Google Analytics di Set up your SKAdNetwork conversion value schema ha un’opzione che permette all’SDK di Firebase di impostare il valore per ogni finestra, e la pagina Get started with Google Analytics for iOS+ di Firebase dice che l’SDK registra l’app con SKAdNetwork automaticamente, a meno che tu non imposti GOOGLE_ANALYTICS_REGISTRATION_WITH_AD_NETWORK_ENABLED su NO. L’articolo SKAN 4.0 anomalies explained di AppsFlyer dice che ogni aggiornamento sovrascrive il precedente, compresi gli aggiornamenti in stile SKAN 3 e le registrazioni di install da un altro SDK. Quel post è uscito per la prima volta ad agosto 2023 ed è il resoconto di un vendor, non di Apple. La pagina del metodo di Apple non dice cosa succede quando lo chiamano due SDK.

AdAttributionKit non aggiunge un writer. La pagina di Apple Understanding AdAttributionKit and SKAdNetwork interoperability dice che le chiamate di conversion value di SKAdNetwork vengono replicate in AdAttributionKit e che una sola impression vince tra i due framework.

In quale finestra può cadere il primo pagamento?

La tabella presuppone che il trial inizi nella prima sessione. Un trial iniziato il giorno 2 sposta ogni data di due giorni in avanti. Le durate dei trial sono quelle dei free trial che Apple elenca in Set up introductory offers for auto-renewable subscriptions, dove la più breve è di 3 giorni. Le celle della finestra 2 e della finestra 3 valgono solo per gli annunci in Tier 1 o superiore, perché un annuncio in Tier 0 non riceve nessun postback dopo il primo.

Aggiungi il ritardo del postback per leggerla come un calendario. Un pagamento della finestra 3 arriva al tuo MMP tra il giorno 36 e il giorno 41 dopo il primo avvio, a meno che la finestra non sia stata bloccata in anticipo.

Cosa copre la guida di RevenueCat, e cosa lascia fuori?

La guida di RevenueCat How to use RevenueCat server-to-server events for SKAdNetwork attribution, pubblicata il 18 febbraio 2025, è la più dettagliata tra le guide dei vendor su questo problema che io conosca. Colloca i trial più brevi di sette giorni nella finestra due e i trial di sette giorni nella finestra tre, il che coincide con la tabella, e propone due soluzioni: controllare lo stato del trial ogni volta che l’app torna in foreground, e un silent push quando il trial finisce. Dice anche che il suo approccio non garantisce una precisione completa. Aggiungerei questo:

• I limiti di Apple sul silent push. La pagina di Apple Pushing background updates to your App dice che le notifiche in background sono a bassa priorità, che la consegna non è garantita, che il sistema può limitarne la frequenza (Apple dice di non inviarne più di due o tre all’ora), e che una notifica trattenuta viene scartata se l’app viene chiusa con un force quit. Una delle conclusioni della guida, cioè che usare le server notification di Apple tramite RevenueCat tracci le conversioni senza che l’utente apra l’app, va oltre ciò che la documentazione di Apple permette di sostenere.
• Il writer. Il codice della guida scrive su SKAdNetwork dall’app. Se scrive anche l’SDK del tuo MMP, ora hai due writer. Fai passare invece l’evento dal tuo unico writer.
• Pagamento, non entitlement. Il controllo della guida legge un entitlement attivo che non è più nel periodo di trial. Mappa invece il valore sull’addebito incassato, perché Billing Grace Period può tenere attivo un entitlement mentre Apple sta ancora provando a incassare.
• Cosa fanno le piattaforme con il valore, nella prossima sezione.
• I cambiamenti ai framework da allora. La pagina AdAttributionKit Updates di Apple elenca cambiamenti a giugno 2024 e a giugno 2025, e niente nel 2026 alla data di questa verifica.

Cosa fanno Google e Meta con un pagamento del trial coarse?

Google dice che non lo usa. La pagina sullo schema di Google Ads dice che il conversion modeling di Google usa solo i fine value e che “we currently do not support SKAN version 4’s coarse conversion values”. La stessa pagina chiede più di 10 eventi di conversione al giorno per ogni evento nello schema e circa 50 install al giorno. Queste sono le linee guida di Google per lo schema, non la soglia di privacy di Apple, e Apple non pubblica nessun numero di install per i suoi tier. Quindi, per le App campaign iOS, il segnale SKAN da cui Google impara è ciò che succede nei primi due giorni. Le conversioni modellate di Google e il suo Integrated Conversion Measurement sono separati da SKAN, e metto i tre uno accanto all’altro in perché Google Ads, il tuo MMP e SKAN riportano conversioni iOS diverse.

Meta ha il suo setup. Configure Apple’s SKAdNetwork in Meta Events Manager ti permette di configurare eventi con fine value e coarse value per SKAdNetwork 4, seguendo le raccomandazioni di Meta, importando lo schema del tuo MMP, o a mano. Dice anche che Meta sta introducendo gradualmente il supporto a SKAdNetwork 4, che potrebbe non essere ancora disponibile per te. Prepare your app integration for Apple’s SKAdNetwork chiede la versione 16.2.1 o successiva alle app che usano il Facebook SDK for iOS, e sconsiglia di diminuire i conversion value o di usare i lock window. AppsFlyer offre entrambe le cose: un’impostazione che permette a una revenue negativa, come un rimborso, di abbassare il valore, e un lock che invia il postback in anticipo. Se è su Meta che va la maggior parte del tuo budget iOS, decidi queste due impostazioni con il consiglio di Meta davanti. La pagina di configurazione dice che gli eventi con coarse value possono aiutare la performance degli annunci. Non dice quanto pesi nella delivery un coarse value dalla finestra 3, e non ho trovato nessuna pagina di Meta che confermi i postback di AdAttributionKit, quindi non affermo nessuna delle due cose.

Cosa significa questo per l’evento di ottimizzazione di Meta?

Su SKAN, il pagamento del trial arriva tardi, coarse, e solo per gli utenti che aprono l’app dopo aver pagato. Un evento della prima sessione arriva nella finestra 1 e può essere un fine value. Quindi l’evento che SKAN può riportare a Meta in fretta è un evento precoce: un trial start, un trial start con una condizione che predice il pagamento, o un piano a pagamento comprato il giorno 0. Il pagamento può comunque stare nello schema per le finestre 2 e 3, come coarse value. Lì lo leggerei come un report tardivo sulla coorte e non ci conterei per guidare la delivery, dato che Meta non dice quanto pesi. L’Aggregated Event Measurement di Meta è un percorso separato con le sue regole, e quando Events Manager segna lì il trial o il purchase come non idoneo, i controlli sono in perché gli eventi trial e purchase non sono idonei a Meta AEM. La scelta dell’evento in sé è in per quale evento dovrebbe ottimizzare una subscription app.

Cosa cambia per un gioco mobile?

Gran parte del problema del relay sparisce, perché il pagamento avviene nella sessione. Quando l’SDK dell’MMP registra un acquisto in app sul dispositivo stesso, può scrivere il valore in quella sessione, e la finestra 1 può portarlo come fine value. Il Conversion Studio di AppsFlyer può misurare la revenue complessiva, ad revenue compresa, tramite un solo evento, af_skad_revenue, e nota che i valori di ad revenue non diventano mai negativi. Un gioco ibrido può dividere i suoi 64 fine value nella finestra 1 tra acquisti, ad revenue e progressione, e usare i coarse value nelle finestre 2 e 3 per la retention o un primo acquisto.

La parte più difficile è il volume. Apple stabilisce il tier in base alla crowd size, un soft launch è piccolo per scelta, e un annuncio in Tier 0 riceve un solo postback senza valore. Meno campagne, più grandi, superano i tier prima, cosa che tratto in meno campagne, più segnale. Cosa deve dimostrare un soft launch, e lo schema SKAN che gli serve, è in acquisizione utenti per giochi mobile.

Come lo testi prima che la spesa salga?

Farei quattro controlli prima di mettere budget su uno schema per il trial. Ognuno deriva dalle pagine dei vendor qui sopra.

1. Il writer. Un solo SDK chiama il metodo di aggiornamento di Apple, e a Google e a Meta viene dato lo stesso schema che quell’SDK segue. L’opzione di Firebase per impostare i valori e gli aggiornamenti SKAN di ogni altro SDK sono disattivati.
2. L’evento. Il pagamento è mappato sull’addebito incassato, il RENEWAL di RevenueCat con is_trial_conversion, non su trial start più nessun annullamento.
3. Entrambi i percorsi di relay. AppsFlyer documenta due percorsi per un evento server: l’SDK aggiorna subito il valore se l’app è in uso, oppure il server lo trattiene fino al prossimo avvio dell’app. Segui una conversione del trial inoltrata lungo ciascun percorso su un dispositivo di test e annota quando è stata eseguita la chiamata di aggiornamento.
4. La lettura della coorte. Per una coorte matura, almeno al giorno 41 dopo il primo avvio, confronta le conversioni del trial che RevenueCat registra per gli utenti che il tuo MMP attribuisce a quel network con i valori di pagamento che il tuo MMP ha decodificato per le finestre 2 e 3. Il divario mescola pagamenti scritti troppo tardi, annunci in Tier 0 che non ricevono postback successivi e differenze di attribuzione tra le due fonti, quindi riportalo come un divario. Non gonfiarlo per colmare la differenza.

Come lo imposto io?

Nel signal engineering questo si traduce in un solo writer, uno schema costruito attorno al tuo trial e al tuo volume, e un’aspettativa scritta su cosa SKAN mostrerà e cosa no, prima che qualcuno giudichi una campagna su questa base. Quando il dubbio è se il problema stia nella misurazione, lo chiarisco nel growth audit.

Fonti

Tutte verificate il 1 ottobre 2026.

• Apple Developer: Receiving postbacks in multiple conversion windows per SKAdNetwork, e la pagina AdAttributionKit con lo stesso nome, senza date di pagina.
• Apple Developer: Set up introductory offers for auto-renewable subscriptions, senza data di pagina.
• Apple Developer: Understanding AdAttributionKit and SKAdNetwork interoperability, senza data di pagina.
• Apple Developer: updatePostbackConversionValue(_:coarseValue:lockWindow:completionHandler:), senza data di pagina.
• Apple Developer: AdAttributionKit Updates, voci di giugno 2024 e giugno 2025.
• Apple Developer: Pushing background updates to your App, senza data di pagina.
• Apple Developer: Reducing involuntary subscriber churn, senza data di pagina.
• Google Ads Help: Set up your SKAdNetwork conversion value schema, senza data di pagina.
• Google Analytics Help: Set up your SKAdNetwork conversion value schema, senza data di pagina.
• Firebase: Get started with Google Analytics for iOS+, ultimo aggiornamento 1 ottobre 2026.
• Meta Business Help Center: Configure Apple’s SKAdNetwork in Meta Events Manager, senza data di pagina.
• Meta Business Help Center: Prepare your app integration for Apple’s SKAdNetwork, senza data di pagina.
• AppsFlyer: SKAN Conversion Studio, aggiornato il 26 aprile 2026.
• AppsFlyer blog: SKAN 4.0 anomalies explained, pubblicato l’8 agosto 2023, modificato il 13 novembre 2025.
• Singular: S2S Support for Conversion Models FAQ, aggiornato il 17 dicembre 2024.
• RevenueCat docs: Meta Ads, AppsFlyer, Singular e Event Types and Fields, senza date di pagina.
• RevenueCat blog: How to use RevenueCat server-to-server events for SKAdNetwork attribution, pubblicato il 18 febbraio 2025, aggiornato il 19 febbraio 2025.