Sono passati cinque anni da quando Apple ha lanciato App Tracking Transparency su iOS 14.5. Da allora i presupposti fondamentali del performance marketing mobile sono cambiati radicalmente. L'attribution deterministico a livello utente è morto; i modelli probabilistici e aggregati sono diventati obbligatori. Con iOS 17 e SKAdNetwork 4, il nuovo schema di conversion value, la finestra post-lookback maturity e le conversioni modellate stanno riconfigurando completamente il gioco. In questo articolo spieghiamo come costruire l'attribution su iOS nel 2026: quali segnali usare, in quale ordine, e come integrare MMP + test di incrementalità per una strategia coerente.
L'anatomia dell'attribution dopo ATT
Prima di iOS 14.5, gli MMP (Adjust, AppsFlyer, Kochava) potevano leggere l'IDFA a livello di dispositivo e collegare ogni conversione direttamente a una campagna. Con ATT, questo meccanismo si è chiuso per oltre il 95% degli utenti (dato Statista 2025: opt-in intorno al 7%). Oggi abbiamo tre strati:
1. Deterministico (utenti con IDFA opt-in): Il 7% che ha concesso il permesso continua a fluire nel classico workflow MMP. Timestamp click/impression, install, in-app event — tutto a livello utente. Ma questo segmento ormai non ha più forza rappresentativa.
2. SKAdNetwork (postback aggregato): Il framework privacy-first di Apple. Finestra di attribuzione 0-72 ore; conversion value limitato a 6 bit (0-63). Con SKAdNetwork 4, Apple ha aggiunto il secondo e terzo postback (finestra 8-35 giorni), rendendo ora possibile misurare la retention D7-D30.
3. Conversioni modellate: Dönüşümler che gli MMP prevedono con machine learning. Combinano dati aggregati click/impression + conteggio install + segnali SKAN. L'affidabilità è inferiore al deterministico, ma garantisce scala.
Questi tre strati vanno usati insieme. Nessuno singolarmente è sufficiente: IDFA è troppo ristretto, SKAN è aggregato e ritardato, il modeled è basato su previsioni. Costruire uno stack che bilanci questi tre elementi è diventato una core competency.
Cosa porta SKAdNetwork 4
SKAdNetwork 4 (arrivato con iOS 16.1, maturo con iOS 17) introduce tre grandi innovazioni:
Gerarchia di conversion value e catena di postback
Non c'è più un singolo 6-bit, ma tre postback: il primo 0-2 giorni, il secondo 3-7 giorni, il terzo 8-35 giorni. Ogni postback porta il suo valore 6-bit. Questo consente di separare il segnale di IAP precoce (install-to-purchase <48h) dal segnale di retention nel secondo postback (session count D3-D7). Prima dovevamo comprimere tutti i segnali in 64 slot, ora abbiamo 64×3=192 combinazioni (non esattamente 192 per il sequential encoding, ma lo spazio di informazione è triplicato).
Esempio di mapping:
- Postback 1 (0-2 giorni): Stato IAP D0 (0=nessun evento, 1-10=fascia di ricavi, 11-20=SKU specifico, 21-63=blend personalizzato)
- Postback 2 (3-7 giorni): Tier di retention D3-D7 (0=churn, 1-20=fascia conteggio sessioni, 21-40=profondità engagement)
- Postback 3 (8-35 giorni): Proxy LTV D30 (0-63=fascia ricavi cumulativi)
Per implementare correttamente questa struttura, devi revisionare il mapping del conversion value ogni settimana. Il segnale più informativo cambia slot al variare del comportamento utente.
Source identifier e source ID gerarchico
SKAdNetwork 4 espone gli ID dell'app editore e dei sottoreti di editori in una gerarchia a quattro livelli. Non è più solo "viene da Meta", ma "Meta → Audience Network → App Editore X" (se la rete di annunci lo espone). Questo consente di confrontare le performance dei sub-publisher.
In pratica, i walled garden come Facebook, TikTok, Google non espongono completamente questo campo, ma su reti programmatiche e video incentivato fa una differenza critica.
Web-to-app attribution support
Con iOS 17.4, SKAdNetwork ha iniziato a supportare click da web. Se un utente clicca da un banner Safari verso l'App Store e installa, questo entra anche nel postback SKAN. Per i brand che eseguono strategie UA cross-channel, è ora possibile combinare questo segnale con campagne Performance Marketing (PPC) e calcolare l'incrementalità cross-channel.
Modeled conversions: come funzionano, quando sono affidabili
Le conversioni modellate sono il meccanismo con cui gli MMP combinano postback SKAN, impression/click aggregati e conteggio install per fare attribution probabilistica tramite machine learning. AppsFlyer lo chiama "predictive analytics", Adjust "statistical modeling" — tecnicamente sono la stessa cosa: regressione + inferenza bayesiana.
Condizioni per l'affidabilità:
- Sufficiente volume di dati: Almeno 500+ install al giorno, 50+ conversioni per campagna (SKAN o IDFA). Sotto questa soglia il modello overfitting.
- Coerenza del segnale SKAN: Il mapping del conversion value deve essere stabile. Se lo modifichi ogni giorno, il modello non riesce a catturare pattern storici.
- Calibrazione con test di incrementalità: Almeno un test per trimestre su geo-holdout o time-based holdout. Confronti i numeri modellati con il lift reale e applichi correzione di bias.
Esempio di cattivo uso: Hai lanciato una nuova campagna, in 3 giorni hai ricevuto 20 install, l'MMP dice "modeled 15 IAP". È completamente rumore — sample insufficiente. Aspetta almeno 2 settimane.
Esempio di buon uso: In 30 giorni Meta + TikTok + Google UAC hanno portato 50K install complessivamente, da SKAN sono arrivate 3K postback di conversione. L'MMP le ha modellate a 8K. Nello stesso periodo un geo-test holdout (Francia vs Germania) ha mostrato un lift del +12%. Hai rivisto il numero modellato a 8K × 1.12 = 8.96K. È affidabile.
Post-lookback maturity: segnali oltre i 35 giorni
Il terzo postback di SKAdNetwork 4 trasporta eventi tra 8-35 giorni. Dopo il 35° giorno non arriva nessun postback SKAN. Ma il comportamento reale dell'utente non finisce a 35 giorni: retention D60, LTV D90, rinnovi di abbonamento annuale.
Approcci di soluzione:
- Proiezione cohort-based LTV: Usa dati SKAN + modeled conversions dei primi 35 giorni per adattare una curva di LTV per cohort (tipicamente power law o exponential decay). Estrapoli il LTV a 90-180 giorni. È una stima, ma con cohort sufficientemente grandi la varianza rimane bassa.
- Holdout cross-channel e incrementalità: Pausa un canale per 2 settimane, misura i cambiamenti in install organici e revenue in-app. Calcola l'incrementalità netta, utilizza il test per backfill il segnale post-35-giorni. Fai questo trimestralmente.
- Arricchimento di eventi server-side: Invia a MMP eventi late-stage non presenti nel postback SKAN (rinnovo abbonamento, IAP high-ticket) via server-to-server. Non è deterministico ma crea pattern in aggregato. L'MMP lo usa come input al modello.
Attenzione: Apple non vieta esplicitamente l'invio di segnali server-side non SKAN, ma l'MMP non può presentarlo come attribution a livello utente. Usarlo come input a modelli aggregate è accettabile.
Scenario pratico di setup dello stack
Supponiamo un'app fitness basata su abbonamento. La tua base install iOS è il 60%, miri a 100K nuovi install mensili. Ecco il tuo stack di attribution:
| Strato | Tool | Ruolo | Intervallo di fiducia |
|---|---|---|---|
| SKAN Postback | AppsFlyer | Conversion value + source ID primi 35 giorni | 95% (Apple verifica) |
| Modeled Conversions | AppsFlyer Predictive | Attribution probabilistica SKAN + aggregate | 70-80% (calibrato con geo-test) |
| IDFA Opt-in | AppsFlyer raw data | Segmento deterministico 7% | 100% (ma bassa rappresentatività) |
| Incrementalità | GeoLift (Meta) + holdout custom | Misurazione lift a livello canale | 90% (statisticamente rigoroso ma costoso) |
| Proiezione LTV | dbt interno + BigQuery | Fit cohort curve, previsione 90-180 giorni | 60-70% (accuratezza modello) |
Flusso:
- Estrai giornalmente postback SKAdNetwork per ogni campagna.
- Prendi le conversioni modellate di AppsFlyer, ma lascia un margine di fiducia del 20% nei calcoli CPA a livello campagna.
- Esegui un geo-holdout test mensile (ad esempio Meta pause in Spagna, continua in Portogallo). Calcola il lift netto.
- Trimestralmente, aggiorna la curva di LTV per cohort. Regredisci la correlazione tra segnale SKAN dei primi 35 giorni e ricavi a 90 giorni.
- Alloca il budget come media ponderata di SKAN + modeled + incrementalità.
Questo approccio multi-strato è costoso? Sì. Ma se il traffico iOS rappresenta il 60% e il CAC è $30+/utente, il costo dell'errore di attribution è molto più alto.
Tradeoff e contraddittori
"Le conversioni modellate non sono affidabili, perché le usiamo?"
Perché non c'è alternativa. SKAN è aggregato, IDFA è al 7%, nessun segnale significa volare completamente al buio. Le conversioni modellate sono imperfette ma calibrate. Quando correggi il bias con test holdout, raggiungi il 75-80% di accuratezza — molto meglio di nessun dato.
"SKAdNetwork 4 è sufficiente, o dovrei aspettare la 5?"
SKAdNetwork 5 (arrivato con iOS 18, annunciato nell'estate 2024) promette source ID più granulare e finestre di lookback più lunghe, ma l'adozione completa non c'è ancora. La base utenti iOS 17 è oltre il 70%, iOS 18 intorno al 30%. Costruire lo stack su SKAdNetwork 4 e aggiungere incrementalmente le funzionalità della 5 è l'approccio pragmatico.
"Devo fare test di incrementalità per ogni campagna?"
No. I test di incrementalità sono costosi e lenti. Un test per trimestre per canale è sufficiente (Meta Q1, TikTok Q2, Google Q3). Per campagne piccole fidati del blend modeled + SKAN; per spostamenti di budget significativi, testa.
L'attribution su iOS non è più deterministico; è ora disciplina probabilistica + aggregata + basata su test. Mappare correttamente la struttura a tre postback di SKAdNetwork 4, calibrare le conversioni modellate con test holdout e proiettare l'LTV post-35-giorni con projection su cohort è lo standard operativo 2026. Se costruisci il tuo stack su questi tre strati — SKAN + modeled + incrementalità — esci dalla navigazione cieca su iOS e fai allocazione di budget basata su dati.