App mobili e deep link

Un link breve che porta a un'app mobile ha tre pubblici contemporaneamente: le persone che l'app ce l'hanno già, quelle che non ce l'hanno e quelle il cui browser vive dentro un'altra app. Questa pagina copre tutti e tre, più i due pezzi di configurazione che fanno la differenza: i file di associazione sul tuo dominio e il contesto del clic differito che la tua app può leggere al primo avvio.

Che cosa fa la sezione Mobile

Apri un link, vai alla scheda Mobile e attiva le destinazioni mobili. Per ogni piattaforma puoi impostare tre indirizzi:

• Link dell'app — l'indirizzo dentro la tua app: il tuo schema con un percorso (myapp://product/42), un intent Android oppure un link universale https.
• Indirizzo dello store — la pagina su App Store o Google Play, usata quando l'app non si apre.
• Ripiego web — una pagina per i visitatori che preferiresti non mandare affatto allo store.

Tutto è facoltativo. Un link con il solo indirizzo dello store è un semplice reindirizzamento allo store. Un link con un link dell'app e un indirizzo dello store ottiene il comportamento completo: la pagina prova prima l'app e passa allo store quando non succede nulla.

Altre due impostazioni decidono che cosa succede fuori da un normale browser del telefono:

• Tablet — trattarli come telefoni (impostazione predefinita) oppure come desktop.
• Browser interni alle app — che cosa fare quando il link si apre dentro Instagram, TikTok, Facebook o un'app simile.

I visitatori da desktop seguono la Destinazione desktop se ne imposti una, altrimenti la destinazione principale del link. Nulla della sezione Mobile cambia ciò che vedono i visitatori da desktop, a meno che tu non lo chieda.

Perché i browser interni alle app hanno bisogno di una regola tutta loro

La maggior parte dei clic sui link in un feed social non arriva mai a Safari o a Chrome. Si aprono in una web view dentro l'app stessa, e parecchie di quelle web view si tengono ogni navigazione per sé: un link universale resta nella web view e uno schema personalizzato, semplicemente, non fa nulla. Non è un difetto che puoi correggere dal link: è una decisione dell'app a cui la web view appartiene.

Perciò l'impostazione ti dà tre opzioni oneste:

| Scelta | Che cosa riceve il visitatore | | --- | --- | | Prova ad aprire l'app | La pagina intermedia prova il link dell'app; quando è noto che quella web view lo blocca, la pagina salta l'attesa e mostra come riaprire il link nel browser del telefono. | | Vai direttamente allo store | Nessun tentativo di aprire l'app: utile per le campagne di installazione, dove l'obiettivo è la pagina dello store. | | Vai al ripiego web | Il visitatore resta sul web, che spesso è la risposta migliore per i link a contenuti. |

File di associazione: la configurazione che fa aprire l'app in silenzio

Perché un link apra la tua app senza una sosta nel browser, il sistema operativo deve sapere che il tuo dominio e la tua app stanno insieme. Entrambe le piattaforme lo verificano con un file servito dal dominio stesso:

https://go.brand.com/.well-known/apple-app-site-association
https://go.brand.com/.well-known/assetlinks.json

Quei file non li scrivi tu. In Domini, apri il dominio e aggiungi le tue app sotto App mobili:

• per iOS: l'App ID nella forma TEAMID.com.company.app e i percorsi che l'app deve gestire (* copre tutti i link brevi);
• per Android: il nome del pacchetto e le impronte di firma SHA-256 prese dalla Play Console.

La piattaforma costruisce e serve entrambi i file dal tuo dominio con la risposta esatta che le due piattaforme pretendono: stato 200, nessun reindirizzamento, application/json, nessuna compressione di trasporto. Quest'ultimo punto conta più di quanto sembri: un proxy che comprime il file in transito è una delle cause più comuni per cui i link alle app smettono di funzionare senza dire niente.

Verificare la configurazione

Il pulsante Controlla i file recupera entrambi i file dal tuo dominio attivo e riporta ciò che vedrebbe una piattaforma. Ogni risultato corrisponde a una correzione precisa:

| Risultato | Che cosa fare | | --- | --- | | Il dominio non ha risposto | Il dominio non serve ancora traffico, oppure il DNS si sta ancora propagando. | | Il file manca | Per questo dominio non è configurata nessuna app, oppure la richiesta non arriva mai alla piattaforma. | | Il dominio reindirizza questo indirizzo | Qualcosa davanti al dominio riscrive /.well-known/. Qui le piattaforme non seguono i reindirizzamenti. | | Servito con il tipo sbagliato | La risposta è HTML, di solito una pagina 404 di un altro servizio. | | La risposta arriva compressa | Un proxy comprime il file. I controlli di entrambe le piattaforme possono fallire per questo. | | Nessuna app dichiarata | Il file è valido ma vuoto per quella piattaforma: aggiungi l'app nella dashboard. |

Una volta che i file sono al loro posto, entrambe le piattaforme li mettono in cache sulla propria CDN, quindi una nuova installazione dell'app può metterci un po' a recepire una modifica. Reinstallare l'app è il modo affidabile per forzare una rilettura durante i test.

Contesto del clic differito dopo l'installazione

Un visitatore che non ha la tua app clicca un link, atterra nello store, installa l'app e la apre. In quel momento l'app non sa nulla di dove quella persona sia arrivata: la sessione del browser e l'app sono due mondi che non si parlano.

Attiva Consegna il contesto del clic dopo l'installazione e la piattaforma conserva per un paio d'ore una breve impronta del dispositivo: piattaforma, versione principale del sistema operativo, lingua, paese, dimensioni dello schermo, fuso orario e operatore di rete. Dentro non c'è nessun indirizzo IP, nessun identificatore pubblicitario e niente che possa essere ricondotto a una persona.

Al primo avvio la tua app chiede alla piattaforma se c'è stato un clic:

curl -X POST https://go.brand.com/__dl/claim \
  -H 'content-type: application/json' \
  -d '{
    "platform": "ios",
    "os_version": "17.4",
    "language": "de",
    "timezone_offset": 120,
    "screen_width": 1170,
    "screen_height": 2532,
    "pixel_ratio": 3
  }'

In caso di corrispondenza la risposta contiene il link originale e i suoi tag di campagna:

{
  "matched": true,
  "confidence": "high",
  "score": 100,
  "matched_on": ["screen", "timezone_offset", "language", "os_version"],
  "url": "myapp://product/42",
  "domain": "go.brand.com",
  "slug": "promo",
  "link_id": "lnk_...",
  "utm": { "utm_source": "newsletter" },
  "click_id": "...",
  "clicked_at": "2026-08-14T10:00:00.000Z"
}

Senza corrispondenza la risposta è {"matched": false} — e lo stesso vale per una seconda richiesta sullo stesso clic, perché il record viene consegnato esattamente una volta.

I limiti, detti chiaramente

• L'abbinamento è probabilistico. Due dispositivi dello stesso modello, sulla stessa rete, con lo stesso fuso orario e la stessa lingua sono identici agli occhi di questo metodo. Per questo ogni risposta porta con sé un confidence e l'elenco degli attributi su cui è stata decisa: high significa che dimensioni dello schermo e fuso orario hanno coinciso entrambi su un clic recente, low significa trattarla come un indizio e non come un fatto.
• La finestra si misura in ore, non in giorni. L'impronta scade due ore dopo il clic, e la confidenza cala già dopo i primi quindici minuti.
• Manda la richiesta una volta sola, al primo avvio. Il record viene consumato dalla prima corrispondenza riuscita; una seconda chiamata non restituisce nulla.
• Un reindirizzamento diretto allo store, senza pagina intermedia, raccoglie meno. Le dimensioni dello schermo e il fuso orario li conosce solo la pagina che gira nel browser, quindi un link che va dritto allo store si abbina soltanto su lingua e versione del sistema operativo — e lo dichiara, con una confidenza più bassa.

Lista di controllo per i test

1. Apri il link su un telefono con l'app installata: deve atterrare dentro l'app.
2. Aprilo senza l'app: la pagina compare per un istante e si apre lo store.
3. Aprilo da un feed social: verifica che la tua scelta sui browser interni alle app corrisponda a quello che ti aspetti.
4. Aprilo su un browser desktop: la destinazione desktop oppure quella principale.
5. Lancia Controlla i file sul dominio e conferma che entrambi i file tornino puliti.