Deferred deep linking senza SDK: come funziona davvero sotto il cofano
Puoi portare il contesto di un link oltre l’installazione senza incorporare un SDK di attribution. Ecco cosa sopravvive davvero al confine dello store su Android e iOS, cosa si rompe e quanto costa in privacy ogni scorciatoia.
Il contesto muore al confine dello store
Qualcuno tocca un link verso /product/42. L’app non è installata, quindi il redirect lo manda allo store. Installa, apre l’app e atterra su una home generica. La richiesta HTTP che portava la sua intenzione è finita sulla scheda dello store: l’app appena installata parte senza URL, senza cookie, senza referrer. Del clic non è sopravvissuto nulla.
Portare quel contesto oltre l’installazione è il deferred deep linking, e la risposta standard è "incorpora un SDK di MMP". Molti team non vogliono quella risposta — il thread 772811 degli Apple Developer Forums è solo uno dei tanti che chiedono come farlo senza SDK di terze parti — e il pubblico si è allargato nell’agosto 2026, quando AppsFlyer ha tolto il deferred deep linking dal piano gratuito. Quindi: si può costruire da soli? Su Android sì, in modo pulito e ufficiale. Su iOS più o meno, con scorciatoie dai costi reali.
Una nota di perimetro: cos’è il deferred deep linking e quando conviene lo trattiamo in un altro articolo. Questo post riguarda solo l’idraulica: quale trasporto può far passare un token oltre un’installazione, e quanto fidarsi di ciascuno.
Cosa sopravvive all’installazione e cosa no
Android: l’Install Referrer API è la buona notizia onesta
Google Play lo risolve nativamente. L’URL dello store accetta un parametro referrer, Play conserva quella stringa insieme all’installazione e l’app la rilegge identica dopo il primo avvio tramite l’Install Referrer API. Questo è l’intero meccanismo: niente fingerprinting, niente appunti, niente supposizioni.
Non è esattamente "zero codice": leggere il valore richiede la libreria com.android.installreferrer, un piccolo artefatto che parla localmente con l’app del Play Store. Non fa chiamate di rete a nessuno, non è un SDK di analytics che telefona a casa e non aggiunge nulla alle tue dichiarazioni sulla privacy oltre a ciò che decidi di fare con la stringa.
Cosa mettere nel parametro sta a te: un ID del link, una campagna, una destinazione di deep link codificata. Tienilo corto e URL-encoded — il referrer su play.google.com/store/apps/details?id=com.example&referrer=tok_8f2 torna esattamente come inviato.
Il ciclo completo, da capo a fondo
- 1Al tap, il redirect aggiunge referrer=<token> all’URL Play; il token punta al contesto del clic salvato sul tuo server.
- 2Al primo avvio, l’app connette un InstallReferrerClient e legge la stringa installReferrer.
- 3L’app scambia il token presso la tua API con il contesto salvato — percorso del deep link, campagna — e instrada l’utente.
- 4Il server marca il token come consumato. La stringa persiste sul dispositivo, quindi il monouso deve vivere lato server.
I limiti sono stretti e prevedibili: l’API copre solo le installazioni passate da Google Play. Sideload, Huawei AppGallery e altri store non portano un referrer Play, e il valore va letto una volta, poco dopo il primo avvio.
I link Appy fanno già la metà Android
Da settembre 2026 ogni link Appy che manda qualcuno a una scheda di Google Play aggiunge il parametro referrer da solo. Non c’è niente da configurare e nessun SDK da aggiungere. Il referrer contiene sempre appy_slug, lo slug del link toccato, così l’app sa quale link ha portato l’installazione. Questa parte funziona su ogni piano, Free compreso.
Se sul link è attivo l’inoltro dei parametri, anche la query string del tocco finisce nel referrer. Un QR code che punta a appy.to/summer?screen=product-42&utm_source=poster arriva al primo avvio come la stringa qui sotto. Per questo non salviamo nulla dalla nostra parte e non tiriamo a indovinare nessun abbinamento.
- Scansionato o toccato
- https://appy.to/summer?screen=product-42&utm_source=poster
- Inviato a Google Play
- https://play.google.com/store/apps/details?id=com.example.app&referrer=appy_slug%3Dsummer%26screen%3Dproduct-42%26utm_source%3Dposter&screen=product-42&utm_source=poster
- Letto dall’app al primo avvio
- appy_slug=summer&screen=product-42&utm_source=poster
L’impostazione nella dashboard
L’inoltro dei parametri è un interruttore per singolo link nel piano Business. Quando crei un link è l’opzione “Abilita l’inoltro dei parametri”; su un link esistente la stessa impostazione si chiama “Inoltra i parametri in ingresso”. Se è spento, il referrer porta comunque appy_slug e nient’altro.
Qualche regola da sapere. Quello che hai scritto tu nell’URL di Play ha la precedenza: se la destinazione contiene già referrer=utm_source%3Dposter, Appy mantiene quel valore e ci aggiunge appy_slug. appy_slug non si può sovrascrivere dalla query string, quindi un link non può prendersi le installazioni di un altro. E se i parametri inoltrati portassero il referrer oltre 1 KB, Appy li scarta e tiene solo lo slug.
I parametri viaggiano in chiaro. Per il nome di una campagna o l’ID di una schermata va benissimo. Per un dato personale, o per più di qualche valore, inoltra un token breve e risolvilo sul tuo server, seguendo lo schema descritto più sotto.
Leggerlo nell’app
Aggiungi la libreria Install Referrer, leggi il valore una volta al primo avvio e analizzalo come una query string. Questo è tutto il lato client:
implementation("com.android.installreferrer:installreferrer:2.2")fun readAppyReferrer(context: Context, onResult: (Map<String, String>) -> Unit) {
val client = InstallReferrerClient.newBuilder(context).build()
client.startConnection(object : InstallReferrerStateListener {
override fun onInstallReferrerSetupFinished(responseCode: Int) {
val raw = if (responseCode == InstallReferrerClient.InstallReferrerResponse.OK) {
runCatching { client.installReferrer.installReferrer }.getOrNull()
} else null
client.endConnection()
val uri = Uri.parse("?" + raw.orEmpty())
onResult(uri.queryParameterNames.associateWith { uri.getQueryParameter(it).orEmpty() })
}
override fun onInstallReferrerServiceDisconnected() = Unit
})
}
readAppyReferrer(this) { params ->
val slug = params["appy_slug"] ?: return@readAppyReferrer
params["screen"]?.let { openScreen(it) }
analytics.logInstallSource(slug, params["utm_source"])
}Eseguilo solo al primo avvio dopo l’installazione e ricordati di averlo fatto. Il referrer resta sul dispositivo, quindi leggerlo a ogni avvio a freddo porterebbe le persone sempre alla stessa schermata. Le installazioni da AppGallery o da APK arrivano senza referrer; in quel caso apri semplicemente la normale schermata iniziale.
iOS: nessun equivalente ufficiale, tre scorciatoie in ordine
Apple non offre nulla di simile all’Install Referrer. Una scheda dell’App Store non trasporta parametri arbitrari attraverso l’installazione; tutto ciò che segue è un espediente per aggirare quell’assenza. Dal meno peggio al più di nicchia:
Passaggio via appunti
01 · affidabilità media, dietro permessoLa pagina di clic scrive un token corto negli appunti — dietro il tocco di un pulsante, perché Safari richiede un gesto utente per copiare — e poi inoltra all’App Store. Alla prima apertura l’app legge gli appunti, trova il token e lo scambia con il tuo server.
L’inghippo è arrivato con iOS 16: leggere gli appunti fa scattare l’avviso di incolla del sistema. L’utente vede "Consentire di incollare da Safari?" sulla primissima schermata di un’app installata trenta secondi prima, e molti rifiutano. Il rifiuto è perdita silenziosa: indistinguibile da "nessun token esisteva". UIPasteboard.detectPatterns verifica un pattern senza avviso ma non legge il valore. E gli appunti possono essere sovrascritti tra tap e apertura. Funziona con frequenza misurabile, ma la seconda faccia della moneta è ben visibile.
Il matching probabilistico, fatto con onestà
02 · una stima con punteggio, mai una certezzaAl clic il server conserva un record breve: quale link, quale piattaforma, la versione dell’OS dallo user agent, un timestamp e un modo per riconoscere la rete da cui arriva il clic. Alla prima apertura l’app chiede un clic recente che sembri dello stesso telefono sulla stessa rete. Nessun token viaggia. La corrispondenza è una stima, e l’unica vera domanda è se chi la fornisce lo ammette.
Fatto con leggerezza, si merita la sua cattiva fama: indirizzi IP grezzi conservati per giorni, il candidato migliore restituito come se fosse certo e uno sconosciuto sulla stessa Wi-Fi d’ufficio in grado di prendersi il referral di un altro. Anche i segnali sono più deboli di quanto sembrino. iCloud Private Relay nasconde gli indirizzi, il CGNAT mette molti telefoni dietro uno solo, Chrome su Android dichiara Android 10 per ogni telefono e Safari su iOS 26 congela la sua versione a 18.6.
Fatto con cura, resta una stima, ma utile. Dai un punteggio a ogni candidato e restituiscilo insieme ai segnali che lo spiegano. Non lasciare mai che una stima arrivi alla certezza. Lascia che sia l’app a scegliere la soglia, e non consumare un clic che resta sotto quella soglia, così il telefono che ha cliccato davvero può ancora aggiudicarselo. Tieni corta la finestra e non salvare alcun indirizzo IP. L’SDK Enterprise di Appy tiene tutto questo dalla parte di Appy. La tua app riceve il link oppure niente, il tuo backend può controllare se un’installazione è verificata e le reti vengono riconosciute tramite un hash con chiave dell’indirizzo che cambia ogni giorno e scade dopo due ore. Con l’attribuzione rigorosa attiva contano solo le installazioni verificate, e tutto il resto è organico.
App Clip e altre vie di nicchia
03 · affidabile ma strettoUn App Clip invocato dal tuo link riceve l’URL completo e può passare il contesto all’app completa tramite un container condiviso dopo l’installazione. Nella sua nicchia è la via iOS più affidabile — ma richiede di costruire e mantenere un App Clip e si adatta solo ai flussi in cui un’esperienza istantanea leggera ha senso. Le shared web credentials risolvono la continuità di sessione, non il contesto generale del link. Da conoscere, raramente la risposta.
Il pattern di progettazione che regge con qualunque meccanismo
Qualunque sia il trasporto del token — stringa referrer, appunti o persino un ID di match probabilistico — l’architettura lato server è la stessa, e farla bene conta più del trasporto. Non infilare l’intero deep link nel canale: salva il contesto del clic sul server e sposta solo una chiave a vita breve.
Salva il contesto sotto un token casuale
Al clic, scrivi {deep_link, campagna, timestamp} sotto un token corto e casuale, e metti nel trasporto solo il token. I payload restano piccoli, i dati di campagna non finiscono negli appunti o nei log, e puoi cambiare cosa significa "contesto" senza toccare il client.
Fai scadere in fretta
Un TTL di 30–60 minuti copre il vero viaggio tap-installazione. Una rotta differita risolta una settimana dopo il clic sbaglia più spesso di quanto indovini.
Imponi il monouso
Consuma il token al primo scambio. Le stringhe referrer persistono e gli appunti si leggono due volte; senza monouso, una reinstallazione o un secondo dispositivo può riprodurre il contesto di qualcun altro.
Fallisci verso il default, non verso una congettura
Nessun token, token scaduto, permesso rifiutato: porta l’utente sulla home normale. Una prima apertura generica delude un po’; finire nel carrello di un altro utente è un ticket di supporto.
L’affidabilità, detta onestamente
Cifre approssimative da team che usano questi meccanismi in produzione. Il tuo mix di sorgenti, il ritardo di installazione e la versione iOS del pubblico spostano ogni numero.
| Meccanismo | Piattaforma | Affidabilità | Note |
|---|---|---|---|
| Play Install Referrer | Android | Alta | API ufficiale, sopravvive alle installazioni ritardate, nessun avviso. Solo installazioni da Play. |
| Token negli appunti | iOS | Media | Vincolato all’avviso di incolla di iOS 16+; i rifiuti sono silenziosi; gli appunti sono volatili. |
| Matching probabilistico con punteggio | iOS, Android senza referrer | Media, con punteggio | Stessa rete, versione dell’OS e tempi. Forte sulla stessa Wi-Fi pochi minuti dopo il tap; debole tra reti diverse, con CGNAT e Private Relay. Da usare solo con un punteggio visibile e una soglia. |
| Passaggio via App Clip | iOS | Alta, stretta | Deterministico, ma solo per flussi che giustificano un App Clip. |
Cosa significa per il tuo stack
Se il tuo bisogno di routing differito è solo Android, ti serve pochissimo: un link che aggiunge il parametro referrer, la piccola libreria e un endpoint di scambio token. È un pomeriggio di lavoro, ed è davvero senza SDK nel senso che conta: nessun codice di terze parti osserva i tuoi utenti.
iOS è dove le soluzioni gestite si guadagnano il pane, perché lì le scorciatoie sono il prodotto: l’infrastruttura di matching, un modello di punteggio che qualcuno deve mantenere onesto e ogni versione di OS che sposta il terreno, come iOS 26 che congela la versione di Safari. Per questo l’SDK iOS e Android di Appy, con deferred deep linking e attribuzione delle installazioni, è nel piano Enterprise, mentre il referrer Android arriva con ogni link.
Sii onesto su quale problema hai. Se ciò che ti serve davvero è che "gli utenti che hanno già l’app atterrino sulla schermata giusta", quello è deep linking standard, senza confine di installazione. Lo shim di deep link di Appy copre quel caso nel piano Pro a 9,99 $/mese, manda allo store chi non ha l’app, sempre senza SDK. Misura quanta parte del tuo funnel è davvero installazione nuova con contesto prima di comprare la macchina pesante.
Leggi anche
Domande frequenti
L’Install Referrer funziona da una scansione QR?
Sì, purché il QR si risolva tramite un link che aggiunge il parametro referrer all’URL Play. Al meccanismo non importa come è iniziato il clic — scansione, tap o NFC — conta solo che l’URL dello store portasse il referrer all’apertura di Play. Un QR che punta a un URL Play nudo non trasporta nulla.
Perché il mio approccio con token negli appunti si è rotto all’improvviso?
Quasi certamente l’avviso di incolla di iOS. Da iOS 16, la prima lettura degli appunti fa scattare un dialogo di permesso, e una quota significativa di utenti rifiuta. Il tuo codice non è peggiorato; la tua lettura ora ha un umano nel circuito. Controlla se il tasso di token trovati è calato invece di azzerarsi: è la firma.
Il matching probabilistico è consentito su iOS?
L’accordo per sviluppatori di Apple vieta di ricavare dati da un dispositivo per identificarlo in modo univoco, e App Review può respingere le app i cui SDK lo fanno. Un fingerprint che riconosce un telefono tra app diverse e per settimane sta dalla parte sbagliata di quella linea. Confrontare un clic e una prima apertura sulla stessa rete entro due ore, per il tuo link, senza salvare l’IP e con un punteggio, è molto più circoscritto, ma quei dati vanno comunque dichiarati nelle informazioni sulla privacy. Qualunque strumento usi, chiedi cosa conserva, per quanto tempo e se ti dice quando sta tirando a indovinare.
Mi serve davvero il deferred deep linking?
Solo se la schermata di atterraggio post-installazione cambia materialmente il tuo funnel. Se la maggior parte delle installazioni arriva da campagne generiche senza destinazione precisa, un buon onboarding rende di più. Misura prima: conta i clic con una vera destinazione di deep link e app non installata. Se il numero è piccolo, investi altrove.
Continua a esplorare
Scopri quale link ha portato ogni installazione: l’SDK iOS e Android di Appy
Ora Appy segue i tuoi link anche oltre lo store. Il nuovo SDK ti mostra installazioni, eventi in-app e ricavi per ogni link, QR code e campagna, e apre ai nuovi utenti la schermata giusta.
Chrome dice a ogni server che il tuo telefono ha Android 10
Chrome su Android dichiara Android 10, modello K, per qualsiasi telefono. Cosa ha rotto nel matching dei deferred deep link, perché Critical-CH conterebbe ogni clic due volte e come i Client Hints restituiscono versione e modello reali.
Deferred deep linking: come funziona e quando usarlo
Porta l’intento originale del link oltre l’installazione, così i nuovi utenti arrivano sulla schermata giusta in-app invece che su una home generica.
Cerchi altro? Sfoglia tutti gli argomenti su il blog.
Instrada le installazioni che hai già guadagnato
L’install referrer di Play su ogni link e, nel piano Pro, deep link che mandano allo store chi non ha l’app, senza un SDK nella tua app. Quando ti servono deferred deep link e attribuzione delle installazioni su iOS e Android, l’SDK Enterprise attribuisce ogni installazione al link che l’ha portata.
Inizia con Appy