Deep link su iOS e Android: una guida pratica

Un deep link è un URL che apre una schermata precisa dentro un'app installata invece di una pagina web. L'idea è tutta qui, ed è stata implementata in tre modi diversi nell'arco di quindici anni, ognuno con i suoi modi caratteristici di rompersi. Il motivo per cui i team di marketing continuano ad aprire segnalazioni su questo tema è che tutti e tre esistono ancora contemporaneamente, e lo stesso URL può comportarsi diversamente a seconda che sia stato toccato in un messaggio, in un browser, in un client di posta o in una webview incorporata dentro un'app social.

Questa guida spiega i meccanismi con onestà, compreso quello che non sanno fare. Se devi portarti via una cosa sola, sia questa: instradare un clic verso la schermata giusta di un'app è infrastruttura ormai risolta, mentre portare un utente alla schermata giusta dopo che ha installato l'app non lo è, o quantomeno non a partire dalla sola piattaforma di link.

Le tre generazioni dei link verso le app

Schemi URL personalizzati

Il meccanismo originario. Un'app registra uno schema come myapp, e un URL del tipo myapp://product/42 le consegna la richiesta. Gli schemi sono banali da implementare e restano utili come formato di instradamento interno, ma portano con sé due problemi strutturali.

Non esiste una verifica della proprietà: qualsiasi app può registrare qualsiasi schema, e quando due app rivendicano lo stesso, su iOS l'esito è indefinito e su Android compare una finestra di scelta. E non esiste un ripiego: su un dispositivo senza l'app installata, un URL con schema produce una pagina di errore o proprio nulla, quindi ogni link con schema ha bisogno di un involucro che rilevi il fallimento e mandi l'utente da qualche parte di utile. Quell'involucro è esattamente il pezzo fragile che si è rotto man mano che i browser hanno irrigidito la gestione dei timer di navigazione.

Universal Links su iOS

Il rimpiazzo introdotto da Apple usa normali URL HTTPS. La tua app dichiara un entitlement di dominio associato nella forma applinks:yourbrand.com, e il dominio pubblica un file JSON all'indirizzo /.well-known/apple-app-site-association che descrive quali percorsi appartengono all'app.

{
  "applinks": {
    "details": [
      {
        "appIDs": ["ABCDE12345.com.yourbrand.app"],
        "components": [{ "/": "/p/*", "comment": "Product pages" }]
      }
    ]
  }
}

Il file va servito su HTTPS senza reindirizzamenti, come JSON, esattamente a quel percorso. iOS lo scarica attorno al momento dell'installazione e dell'aggiornamento, in larga parte attraverso la CDN di Apple, il che significa che le modifiche non hanno effetto immediato. Il vantaggio è che lo stesso URL funziona ovunque: se l'app è installata e il percorso corrisponde, si apre; altrimenti Safari carica la pagina web. Non esiste uno stato di errore.

App Links su Android

L'equivalente Android usa un file Digital Asset Links all'indirizzo /.well-known/assetlinks.json, che indica il package dell'app e l'impronta SHA-256 del certificato di firma.

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.yourbrand.app",
      "sha256_cert_fingerprints": ["A1:B2:C3:D4:E5:F6:..."]
    }
  }
]

Dal lato dell'app si dichiara un intent filter per il dominio con la verifica automatica attiva. Quando la verifica riesce, il link apre l'app senza nessuna finestra di scelta. Quando fallisce, il link apre il browser, e la causa di gran lunga più frequente è un'impronta che non corrisponde: i team pubblicano l'impronta della propria chiave di release locale mentre Play App Signing rifirma l'app con un'altra. L'impronta che va messa nel file è quella che lo store mostra per l'artefatto distribuito.

Come un link breve sceglie la propria destinazione

Un link breve è un punto di decisione più che un puntatore fisso, ed è proprio questo a renderlo utile per le campagne app: un solo codice stampato può servire in modo diverso chi usa iPhone, chi usa Android e chi arriva da desktop, e la decisione può cambiare dopo che il codice è stato stampato.

Il motore di reindirizzamento vede lo user agent della richiesta, i client hints che porta con sé e i segnali derivati dalla rete, come il paese. Un link configurato per il traffico verso le app tiene di solito tre destinazioni: un URL iOS, un URL Android e un URL web usato per tutto il resto. Sopra a questo, le regole di targeting possono instradare per paese, dispositivo, sistema operativo o lingua, così una campagna può mandare il traffico Android canadese a una destinazione e tutti gli altri a un'altra senza creare link separati.

Vale la pena conoscere due dettagli implementativi, perché spiegano la maggior parte dei comportamenti che sembrano incomprensibili.

Il primo sono i crawler social. Quando un bot come quello di Facebook o di Telegram richiede un link per costruire una card di anteprima, un motore di reindirizzamento corretto risponde con i metadati dell'anteprima invece di contare la richiesta come clic e invece di instradarla come se fosse un telefono. Se i tuoi conteggi di clic si impennano nel momento in cui un link viene pubblicato, prima che qualcuno lo abbia toccato, il motore non sta facendo questo.

Il secondo è il confine dell'associazione, ed è il punto tecnico più importante di questo articolo. Gli Universal Links vengono valutati rispetto al dominio dell'URL che l'utente ha toccato davvero. Se qualcuno tocca go.yourbrand.com/p/42 e quel dominio risponde con un reindirizzamento a yourbrand.com/p/42, iOS non considera la destinazione del reindirizzamento un link associato, quindi l'app non si apre. Perché un link breve apra l'app in modo nativo, il file di associazione deve essere servito sul dominio breve stesso. Dove questo non è possibile, il ripiego pratico è un passaggio di consegne verso uno schema personalizzato o direttamente allo store, ed è quello che fanno davvero quasi tutte le funzioni di deep link degli accorciatori. Chiedi a qualsiasi fornitore quale delle due cose implementa, perché i testi di marketing sono identici in entrambi i casi.

La catena di ripiego

Un link verso l'app che funziona è in realtà un piccolo albero di decisione, e ogni ramo ha bisogno di una risposta pensata.

| Situazione | Che cosa dovrebbe succedere | Errore frequente | | --- | --- | --- | | App installata, percorso riconosciuto | L'app si apre sulla schermata giusta | La catena di reindirizzamenti rompe l'associazione | | App installata, percorso non riconosciuto | Si carica la pagina web, con l'app suggerita | Finestra di scelta mostrata a ogni tocco | | App non installata, mobile | La scheda dello store della piattaforma giusta | Link allo store fissato su una sola piattaforma | | Desktop | L'equivalente web completo di quella schermata | Atterraggio su una homepage generica | | Crawler social | I metadati di anteprima, nessun clic contato | Il recupero dell'anteprima gonfia le analytics |

Punta il ramo dello store alla scheda giusta per ciascuna piattaforma invece che a un unico link, e tieni il ramo web davvero equivalente alla schermata dell'app. Una quota rilevante del traffico delle campagne app finisce sul ramo web per quanto bene sia configurato tutto il resto, e trattarlo come un vicolo cieco spreca gran parte del budget.

Il confine dell'installazione, detto onestamente

È qui che il marketing dei fornitori e la realtà divergono. Immagina che un nuovo utente tocchi un link verso un prodotto preciso, non abbia l'app, atterri nello store, installi e apra. L'app adesso mostra la sua schermata iniziale predefinita, perché niente ha portato l'identificatore del prodotto attraverso l'installazione. Far funzionare questo passaggio si chiama deferred deep linking, e non è qualcosa che una piattaforma di link possa fare da sola.

Richiede un SDK dentro l'app che, al primo avvio, chieda a un server che cosa l'utente ha toccato prima di installare. Il server deve mettere in corrispondenza i due eventi, e i segnali disponibili per quella corrispondenza si sono ristretti bruscamente. Il fingerprinting dei dispositivi è inaffidabile e sempre più limitato dalle policy delle piattaforme. Gli identificatori pubblicitari richiedono un consenso che la maggior parte degli utenti nega. I framework di attribuzione di Apple riportano agli inserzionisti un'attribuzione a livello di installazione, invece di passare un percorso alla tua app. La tecnica degli appunti che un tempo trasportava un token ora fa comparire una notifica visibile di incollaggio.

Quello che resta funziona, ma è un prodotto diverso con un costo di integrazione diverso: l'SDK di un mobile measurement partner, un'inizializzazione dentro l'app e una finestra di corrispondenza probabilistica invece che esatta. LinkProfit instrada i clic per dispositivo e passa la mano allo store, e non dichiara di gestire l'instradamento dopo l'installazione, perché farlo come si deve significa spedire codice dentro la tua app. Se l'instradamento differito è un requisito imprescindibile, metti in conto quell'SDK accanto alla tua piattaforma di link, non al posto suo.

Le webview e altre trappole pratiche

I browser dentro le app

La maggior parte dei link toccati dentro le app social si apre in una webview incorporata invece che nel browser di sistema, e le webview gestiscono l'associazione con le app in modo incoerente: alcune ignorano gli Universal Links, altre bloccano gli schemi personalizzati, e il comportamento cambia da una versione all'altra dell'app. È il motivo più comune per cui un link che in prova funziona alla perfezione in produzione apre il sito web, dato che le prove si fanno di solito toccando un link in un'app di messaggistica, che si comporta correttamente.

Non esiste una configurazione che risolva la cosa globalmente. Quello che funziona è rendere buona la destinazione web, aggiungerci sopra un comando visibile per aprire l'app e provare ogni canale di pubblicazione singolarmente invece di dare per scontato che si comportino allo stesso modo.

Gli errori nel file di associazione

Ne ricorrono quattro. Servire il file di associazione attraverso un reindirizzamento, compreso quello automatico dal dominio apex a www, che lo invalida. Servirlo con il content type sbagliato o da un percorso che un framework riscrive. Pubblicare l'impronta di firma Android sbagliata, come descritto sopra. E dimenticare che iOS tiene il file in cache, quindi una correzione può metterci un giorno o più ad arrivare sui dispositivi che hanno già l'app installata.

Le analytics sul ramo dell'app

Una volta che un clic entra dentro un'app, le tue analytics web smettono di vederlo, ed è qui che la reportistica si sfalda in silenzio. Tieni i parametri di campagna sul link, così il motore di reindirizzamento li registra, e passa un identificatore alla destinazione dentro l'app, così la sessione in-app si può unire al clic. La nostra guida al tracciamento dei clic sui link spiega che cosa può e non può dirti un evento di clic, e qui valgono le stesse avvertenze su bot e visitatori unici.

Le prove prima di pubblicare

curl -sSI https://yourbrand.com/.well-known/apple-app-site-association
curl -sS https://yourbrand.com/.well-known/assetlinks.json

# Android: open a URL as if it were tapped, then inspect verification state
adb shell am start -a android.intent.action.VIEW -d "https://yourbrand.com/p/42"
adb shell pm get-app-links com.yourbrand.app

# iOS simulator
xcrun simctl openurl booted "https://yourbrand.com/p/42"

I primi due comandi devono rispondere 200 senza reindirizzamenti. Tieni presente che digitare un Universal Link nella barra degli indirizzi di Safari deliberatamente non apre l'app, quindi fai le prove da una nota, da un messaggio o dal comando del simulatore, altrimenti inseguirai un bug che non esiste.

Che cosa includono davvero le piattaforme di link

Il supporto dei deep link è confezionato in modi molto diversi dentro questa categoria, e le differenze riguardano quale piano devi comprare più che le capacità del prodotto.

| Fornitore | Disponibilità dei deep link, ad agosto 2026 | | --- | --- | | BL.INK | Tutti i piani, fascia di ingresso a 48 USD al mese per un utente e un dominio | | Short.io | Dal piano Team, a 48 USD al mese | | Rebrandly | Dal piano Growth, da 99 a 119 USD al mese | | Switchy | Copertura dichiarata di più di 130 app | | LinkProfit | Destinazioni per dispositivo su tutti i piani |

Qui il metro di paragone onesto è BL.INK: includere i deep link in ogni fascia è insolito, anche se il prezzo di ingresso è alto per un solo dominio. La collocazione scelta da Rebrandly su Growth è invece lo schema da tenere d'occhio in generale, dato che la fascia di cui hai bisogno per una singola funzione tende a determinare l'intera fattura.

Una sequenza di messa in opera che funziona

1. Decidi l'URL web canonico per ogni schermata dell'app verso cui vuoi mandare link; la pagina web è il ripiego e la fonte di verità.
2. Pubblica entrambi i file di associazione sul dominio che comparirà nei link, e verificali su HTTPS senza reindirizzamenti.
3. Aggiungi l'entitlement di dominio associato su iOS e l'intent filter verificato su Android, usando l'impronta della build distribuita.
4. Accertati su quale dominio verranno toccati i tuoi link brevi, e se l'associazione vive lì oppure la piattaforma passa la mano a uno schema o allo store.
5. Configura su ogni link le destinazioni per dispositivo più un ripiego web, con la scheda dello store giusta per ciascuna piattaforma.
6. Fai le prove su entrambe le piattaforme da un'app di messaggistica, dal browser di sistema e da ogni app social in cui pubblichi.
7. Verifica che i parametri di campagna sopravvivano al reindirizzamento e vengano registrati nelle analytics.
8. Automatizza la creazione tramite API se i link vengono generati per campagna, per destinatario o per prodotto.

Niente di tutto questo è difficile preso da solo. La difficoltà è che i pezzi vivono in tre posti — il progetto dell'app, la zona DNS e la piattaforma di link — di solito in mano a tre persone diverse. Mettere per iscritto chi dei tre è responsabile del file di associazione vale più di qualsiasi singolo consiglio di configurazione contenuto in questo articolo.