Deep link. Apri l'app. Ripiega con eleganza.
Manifest Universal Links e App Links serviti dal tuo dominio personalizzato. iOS apre la tua app al tocco; Android fa lo stesso. Fallback del browser su desktop.
- Universal Links (iOS) e App Links (Android) serviti dal tuo dominio
- Deep link differiti - il contesto sopravvive all'installazione dell'app
- Rilevamento intelligente della piattaforma con fallback eleganti
- Nessun SDK richiesto - funziona con i meccanismi OS standard
Universal Links e App Links
File manifest, serviti automaticamente dal tuo dominio
iOS Universal Links richiede un file apple-app-site-association . Android App Links richiede assetlinks.json. Elido genera e serve entrambi dal tuo dominio personalizzato automaticamente - nessun hosting separato, nessuna gestione manuale dei file.
- iOS Universal LinksBundle ID + Team ID → AASA servito a /.well-known/ automaticamente
- Android App LinksNome pacchetto + impronta SHA-256 → assetlinks.json, HTTPS imposto
- Fallback smart-linkApp non installata → App Store / Play Store via routing basato su regole
- Passthrough UTMParametri UTM preservati nell'URL dello store - l'attribuzione non si rompe
- Nessun SDK nella tua appSolo intercettazione a livello OS; intent-filter e continueUserActivity
{ "applinks": { "apps": [], "details": [ { "appID": "TEAMID.com.yours.app", "paths": [ "/product/*", "/referral/*", "/invite/*" ] } ] } }
[{ "relation": [ "delegate_permission/ common.handle_all_urls" ], "target": { "namespace": "android_app", "package_name": "com.yourcompany.app", "sha256_cert_fingerprints": [ "AB:12:CD:34:EF:56:..." ] } }]
Servito dal tuo dominio personalizzato automaticamente. Configura bundle ID + Team ID (iOS) o nome pacchetto + impronta SHA-256 (Android) nelle impostazioni del dominio - Elido genera e ospita entrambi i file.
Deep link differiti
Contesto che sopravvive all'installazione
Quando l'app non è installata, l'utente va allo store, installa e apre l'app. Il deep-linking differito passa il contesto deep-link originale attraverso questo percorso così l'app può portare l'utente esattamente sulla schermata giusta dopo il primo avvio.
- 01
Clicca sul link
L'utente tocca un link breve Elido - da email, social, QR.
go.yourcompany.com/p/12345 - 02
Niente app → Store
App non installata. Il SO rileva dalla verifica AASA / assetlinks. Ripiega su App Store o Play Store.
iOS → App Store · Android → Play Store - 03
Installa l'app
L'utente installa dallo store. L'install referrer porta il contesto del clic come parametro di query.
click_id + UTM preservati nell'URL referrer - 04
Apre l'app
L'app si apre per la prima volta. MMP legge l'install referrer; mappa click_id all'evento di installazione.
Appsflyer / Adjust / Branch lo coglie - 05
Atterra sulla pagina esatta
L'app instrada alla schermata originariamente collegata - product/12345 - come se l'utente avesse già l'app.
product/12345 - contesto preservato attraverso l'installazione
Il parametro click_id e i parametri UTM dal link breve originale vengono passati come parametri di query all'URL dello store. Le Mobile Measurement Platforms (MMPs) che catturano l'install referrer - Appsflyer, Adjust, Branch - possono fare il match dell'installazione con il clic originale. Il deep-linking differito completo (passare contesto in-app attraverso l'installazione) richiede l'SDK MMP nella tua app; Elido copre il layer di link.
Rilevamento intelligente della piattaforma
Un link. Tre percorsi di reindirizzamento.
L'edge legge User-Agent e segnali di piattaforma al livello di reindirizzamento - prima che qualsiasi JS venga eseguito. iPhone ottiene Universal Links, Android ottiene App Links, desktop ottiene il tuo fallback web. Nessun ritardo di reindirizzamento JavaScript; nessun rilevamento di piattaforma lato client.
- Parsing UA sull'edge, sotto-millisecondo
- iOS → intercettazione Universal Link dal SO
- Android → intercettazione App Link via intent-filter
- Desktop → URL web, nessuna deviazione verso lo store
- Browser in-app rilevati e reindirizzati al browser di sistema
- Si combina con regole smart-link - geo + dispositivo + deep-link
Cosa puoi fare
- Apple App Site Association
- Android Asset Links
- Regole Smart-link per fallback dello store
- Testato con adb e xcrun
Come funzionano realmente i deep link - e dove si rompono
Universal Links e App Links sono meccanismi a livello di sistema operativo. La configurazione è semplice; i casi limite no. Questa sezione copre il quadro completo.
apple-app-site-association servito automaticamente dal tuo dominio personalizzato
I Universal Links richiedono un file apple-app-site-association (AASA) in /.well-known/apple-app-site-association sul tuo dominio personalizzato. iOS scarica questo file quando la tua app viene installata; mappa il tuo dominio al bundle ID e al team ID della tua app. Se la mappatura è corretta, toccando un link HTTPS sul tuo dominio in qualsiasi app iOS (Safari, Mail, Twitter, Instagram) si aprirà direttamente la tua app invece di andare su un browser. Elido genera e serve il file AASA dal percorso well-known del tuo dominio personalizzato automaticamente, in base al bundle ID e al team ID configurati nelle impostazioni del dominio. Non è necessario ospitare il file separatamente. iOS mette in cache il file AASA e lo riscarica periodicamente; se modifichi la configurazione del bundle ID nelle impostazioni del dominio di Elido, il nuovo AASA è attivo in pochi secondi, ma i dispositivi iOS lo rileveranno al prossimo aggiornamento della cache (solitamente 24-48 ore, o alla reinstallazione dell'app). Testato con il validatore Apple AASA ad ogni rilascio di Elido.
assetlinks.json servito automaticamente - impronta SHA-256 dalla tua chiave di firma
Android App Links richiedono un file Digital Asset Links in /.well-known/assetlinks.json sul tuo dominio. Il file mappa il tuo dominio al package name della tua app e all'impronta SHA-256 del tuo certificato di firma. Android verifica questo file durante l'installazione dell'app e periodicamente. Elido lo serve automaticamente dal tuo dominio personalizzato, in base al package name e all'impronta SHA-256 configurati. La verifica di Android richiede HTTPS (imposto dal TLS di Elido sul dominio personalizzato) e il file deve rispondere entro pochi secondi (anche questo gestito). Una modalità di errore comune: diverse chiavi di firma per le build di debug e release hanno impronte SHA-256 diverse. Configura entrambe le impronte nelle impostazioni del dominio di Elido se stai testando con una build di debug; le build di produzione necessitano solo dell'impronta di release. Testato con adb shell pm get-app-links ad ogni rilascio.
App installata → deep link. App non installata → store. Desktop → web. UTM preservati ovunque.
La catena di fallback è impostata per link o per dominio nelle impostazioni di Elido. Per uno short link con configurazione deep-link: se il sistema operativo intercetta il tocco (app installata, dominio verificato), l'app si apre. In caso contrario (app non installata), il link si apre nel browser; la destinazione del browser dovrebbe essere il link all'App Store / Play Store o un fallback web. Le regole degli smart-link gestiscono questo in modo pulito: configura una regola per iOS → URL App Store, una regola per Android → URL Play Store e il fallback alla destinazione web. I parametri UTM dello short link originale vengono preservati negli URL di fallback in modo che l'attribuzione non si interrompa quando l'utente arriva allo store. Il deep-linking differito (passare un percorso deep-link specifico attraverso un'installazione, in modo che l'app si apra sulla schermata corretta dopo l'installazione) richiede un SDK nell'app - Elido non lo fornisce. Per il deep-linking differito, sono ancora necessari Appsflyer, Adjust o Firebase App Distribution.
Retargeting post-installazione: click ID passato alla destinazione per l'attribuzione
Su un reindirizzamento deep-link, Elido passa il click_id come parametro di query all'URL di fallback. Se l'utente atterra nell'App Store e installa l'app, il click_id è nell'URL di riferimento ma non viene propagato automaticamente nell'app dopo l'installazione - ciò richiede SKAdNetwork su iOS o un SDK per deep-link differito su Android. Cosa fa Elido: passa il click_id e i parametri UTM all'URL dello store in modo che una piattaforma di attribuzione mobile (MMP) che sta acquisendo il referrer dell'installazione possa rilevarli. Questo funziona con Appsflyer e Adjust se passi il click_id nel parametro campaign dell'URL dello store. Se non stai usando una MMP, il click_id nell'URL dello store viene effettivamente perso dopo l'installazione.
Migrazione da Firebase Dynamic Links (sunset 2025)
Firebase Dynamic Links è stato dismesso da Google nel 2025. Elido può gestire il pattern principale: un unico short link HTTPS che apre la schermata corretta in un'app installata, torna allo store in caso contrario e al web su desktop. Configura AASA e assetlinks.json nelle impostazioni del dominio di Elido (sostituisce l'hosting Firebase di questi file), aggiorna i tuoi link di condivisione per puntare agli short link di Elido invece degli URL page.link e configura la catena di fallback tramite le regole smart-link. Cosa non replica Elido: il deep-linking differito di Firebase (contesto deep link post-installazione tramite l'SDK Firebase) e i deep link di Firebase App Distribution. Se la tua app si affida pesantemente al deep-linking differito, avrai bisogno di Appsflyer, Adjust o Branch insieme a Elido per il livello di attribuzione. Per le app che necessitano solo di 'apri la schermata corretta se installata, altrimenti vai allo store', Elido sostituisce completamente Firebase Dynamic Links.
Team mobile che utilizzano i deep link di Elido
I nomi sono segnaposto per ora - i nomi dei clienti reali appariranno qui man mano che i casi studio verranno pubblicati.
“Siamo passati da Firebase Dynamic Links la settimana in cui hanno annunciato la dismissione. La configurazione di AASA e assetlinks.json in Elido ha richiesto mezza giornata. La catena di fallback smart-link ha sostituito la logica dell'SDK Firebase che avevamo nell'app per l'instradamento allo store.”
“L'analisi dei clic per link sui deep link ci ha detto che il 35% dei nostri link di condivisione veniva cliccato su desktop - non avevamo configurato alcun fallback web. Aggiungere il fallback ha richiesto 10 minuti; il tasso di conversione dei link di condivisione è aumentato perché gli utenti che cliccavano da desktop potevano ora completare l'azione.”
“Usiamo gli short link di Elido con configurazione deep-link per i programmi di referral. Il passthrough UTM all'URL dell'App Store significa che la nostra MMP rileva correttamente il referrer dell'installazione - l'attribuzione funziona senza lavoro personalizzato sull'SDK da parte nostra.”
Elido deep links vs Branch.io vs Adjust vs Firebase Dynamic Links (sunset)
Branch e Adjust sono piattaforme complete di attribuzione mobile - più potenti per il deep-linking differito e l'attribuzione MMP. Elido è lo strumento giusto quando i deep link fanno parte di una configurazione di abbreviazione più ampia, non il prodotto principale.
| Feature | Elido | Branch.io | Adjust |
|---|---|---|---|
| Universal Links (iOS) | AASA servito automaticamente dal tuo dominio | Gestito completamente su scala | No - solo MMP, non host per deep-link |
| App Links (Android) | assetlinks.json servito automaticamente dal tuo dominio | Gestito completamente | No |
| SDK richiesto nell'app | No - intercettazione a livello di sistema operativo | Sì - SDK Branch | Sì - SDK Adjust |
| Deep-linking differito | No - richiede SDK nell'app | Sì - funzionalità principale | Sì - con SDK Adjust |
| Mobile attribution (MMP) | Passthrough click ID; cablaggio MMP manuale | MMP nativo - integrazioni Appsflyer, Kochava | Piattaforma MMP completa |
| UTM passthrough allo store | Sì - tramite parametro query sull'URL di fallback | Sì, con contesto di attribuzione | Sì |
| Analytics on link clicks | Archivio di analisi - geo, dispositivo, per link | Analitiche approfondite di attribuzione mobile | Dati di attribuzione installazione + evento |
| Sostituzione Firebase Dynamic Links | Sì per il pattern di base; no deep-link differito | Sostituzione completa incluso differito | Parziale - solo lato MMP |
Domande sui deep link
Ho bisogno di un SDK Branch o di un qualsiasi SDK nella mia app per usare i deep link di Elido?
No. I deep link di Elido utilizzano iOS Universal Links e Android App Links - meccanismi a livello di sistema operativo. La tua app deve solo gestire l'URL in entrata nel modo standard di iOS (scene:openURLContexts o application:continueUserActivity) o Android (intent-filter nel manifest). Non viene installato alcun SDK di terze parti; il sistema operativo gestisce l'intercettazione in base ai file AASA e assetlinks.json che Elido serve dal tuo dominio.
Qual è il flusso di configurazione AASA?
Nelle impostazioni del dominio Elido → Deep link: inserisci il bundle ID della tua app iOS (es. com.tuasocieta.app) e il Team ID Apple (stringa di 10 caratteri dal tuo account Apple Developer). Elido genera il JSON AASA e lo serve in /.well-known/apple-app-site-association sul tuo dominio personalizzato. Verifica che sia raggiungibile con curl prima di inviare la tua app a TestFlight o all'App Store. iOS scarica il file AASA durante l'installazione dell'app su dispositivi con iOS 9+.
Posso avere più app su un solo dominio?
Sì - il file AASA supporta più voci per app. Configura il bundle ID e il Team ID di ogni app nelle impostazioni del dominio; Elido genera un AASA combinato con tutte le app elencate. Anche assetlinks.json di Android supporta più combinazioni di package name + impronta. Caso d'uso comune: app principale e un App Clip, o app principale e un'estensione widget.
Dismissione di Firebase Dynamic Links - qual è il percorso di migrazione?
Sostituisci gli URL brevi page.link con gli short link di Elido (il tuo dominio personalizzato o il dominio condiviso di Elido). Configura AASA e assetlinks.json nelle impostazioni del dominio di Elido. Imposta la catena di fallback tramite le regole smart-link (regola iOS → App Store, regola Android → Play Store, fallback → web). Aggiorna la generazione dei link di condivisione nella tua app per chiamare l'API create_link di Elido invece di Firebase. Cosa non migra: se la tua app si affida al deep-linking differito di Firebase (passaggio dell'intento post-installazione), avrai bisogno di Branch o Adjust per quella parte.
Come posso testare i Universal Links prima di pubblicare sull'App Store?
Usa xcrun simctl openurl booted 'https://go.tuasocieta.com/test-slug' con la tua app installata su un simulatore. Su un dispositivo fisico con una build di debug, premi a lungo su un link in Safari e vedi se appare 'Apri nella tua app'. Apple fornisce anche l'App Association File Validator su developer.apple.com - incolla l'URL del tuo AASA e controlla raggiungibilità, Content-Type e validità JSON. L'AASA di Elido supera tutti e tre i controlli.
Cos'è il deep-linking differito e perché Elido non lo fa?
Il deep-linking differito passa il contesto (es. 'l'utente stava visualizzando il prodotto ID 123') dal clic sul link attraverso l'installazione di un'app e al primo avvio dell'app. Richiede un SDK di fingerprinting o attribuzione nell'app (Branch, Appsflyer, Adjust) che abbini l'installazione al clic durante il processo di installazione. Elido non installa codice SDK nella tua app; serviamo solo AASA e assetlinks.json. Senza l'SDK, non c'è alcun meccanismo per passare il contesto attraverso un'installazione. Per il caso d'uso base 'apri la schermata corretta se installata', Elido è sufficiente. Per passare l'intento attraverso l'installazione, è necessaria una MMP.
Posso usare i deep link sul dominio condiviso di Elido (s.elido.me)?
No. I Universal Links e gli App Links richiedono il tuo dominio - non puoi rivendicare *.elido.me come dominio Universal Link per la tua app. I deep link richiedono un dominio personalizzato su Pro o Business. Il dominio personalizzato è quello che configuri nel tuo AASA e assetlinks.json, ed Elido serve quei file da esso.
Come gestisco il caso in cui il browser dell'utente blocca l'intercettazione dell'app?
Alcuni browser (in particolare Chrome su Android precedente alla 6.0 e alcuni browser in-app come quello di Instagram) bloccano l'intercettazione di App Links o Universal Link. L'URL di fallback è ciò che vedono. Per i browser in-app: reindirizza prima al browser di sistema utilizzando un URL intent (Android) o un messaggio per l'utente. Per i browser in-app di Instagram / TikTok: l'approccio standard è mostrare un messaggio 'tocca per aprire nel tuo browser'. Elido non inserisce questo messaggio automaticamente - l'URL di fallback è la tua destinazione e tu controlli cosa succede lì.
Continua a leggere
Configurazione dominio personalizzato - richiesta per i deep link; AASA e assetlinks.json serviti dal tuo hostname.
iOS → App Store, Android → Play Store, desktop → web - la catena di fallback che utilizza le regole smart-link.
Come i team di prodotto utilizzano i deep link insieme a varianti A/B e regole smart-link.
Integrazioni MMP - Appsflyer, Adjust e Branch per il deep-linking differito insieme a Elido.
Pronto a provarlo?
Inizia con il piano gratuito, effettua l'upgrade quando hai bisogno di un dominio personalizzato.