Come configurare Universal Links e App Links dopo Firebase

Se hai ancora vecchi link app dentro QR code, campagne paid, email, pagine di download o flussi referral, il problema non è trovare "un altro Firebase". Il problema è tenere in piedi i link pubblici senza rompere apertura dell’app, fallback e misurazione.

Per farlo bene conviene separare le parti che Firebase Dynamic Links teneva insieme:

1. URL pubblica di marca
2. apertura nativa dell’app installata
3. fallback verso App Store, Google Play o web
4. conservazione dei parametri di campagna

La FAQ ufficiale di Firebase Dynamic Links indica che il servizio è stato spento il 25 agosto 2025. Se quei link vivono ancora in campagne, QR o onboarding, la mossa più sana non è cercare un clone. È ricostruire un layer di linking più pulito.

Universal Links e App Links: cosa fanno davvero

Universal Links

Apple Universal Links aprono l’app iOS installata da un normale link HTTPS se:

• il dominio è associato correttamente all’app
• la capability è configurata
• il dominio espone un apple-app-site-association valido
• il path ricevuto è gestito dall’app

Android App Links

Android App Links fanno lo stesso lato Android. Servono:

• dominio verificato
• manifest configurato correttamente
• assetlinks.json valido
• gestione dei path dentro l’app

Cosa non coprono da soli

Da soli non risolvono:

• fallback desktop
• fallback per utenti senza app
• URL di marca condivisa da marketing
• routing per dispositivo
• conservazione UTM
• override temporanei di campagna

Per questo serve ancora un layer di redirect controllato.

L’architettura più semplice da mantenere

Per molti team il modello più robusto è questo:

go.tuomarchio.com/promo
  -> rilevamento dispositivo all’edge
  -> iPhone con app: Universal Link
  -> iPhone senza app: App Store
  -> Android con app: App Link
  -> Android senza app: Google Play
  -> Desktop: landing page, docs o pagina con QR

Questo approccio funziona bene perché:

• il dominio resta sotto il tuo controllo
• il fallback è esplicito
• marketing usa un solo link pulito
• mobile e growth possono testare lo stesso percorso reale

Dove molti team si bloccano

Il collo di bottiglia spesso non è il concetto. Sono i file di verifica:

• apple-app-site-association
• assetlinks.json

Quando il sito principale gira su Shopify, Webflow, Wix o un CMS che non gestisce bene root path e .well-known, questa parte diventa fastidiosa.

Qui UrlEdge ha un vantaggio pratico: con custom response puoi servire questi file dall’edge senza dover trasformare la pubblicazione in un progetto separato.

Come impostare la migrazione

1. Fai inventario di tutti i link pubblici

Controlla:

• campagne paid
• QR stampati
• pulsanti di download
• email lifecycle
• pagine supporto
• bio social
• referral

2. Separa apertura app e fallback

Per ogni link importante chiarisci:

1. se l’app è installata, deve aprirsi?
2. se non è installata, va allo store o al web?
3. cosa vede desktop?
4. gli UTM devono restare?

3. Scegli il dominio pubblico canonico

Esempi tipici:

• go.tuomarchio.com
• app.tuomarchio.com
• links.tuomarchio.com

Questo ti evita di legare il linking pubblico a un hostname di terze parti.

4. Valida i file di associazione

Usa sempre la documentazione ufficiale:

• Apple Universal Links
• Android App Links

Se questa parte è sbagliata, l’apertura nativa resterà incostante anche se il redirect generale sembra corretto.

5. Definisci fallback espliciti

Per esempio:

• iOS con app -> app
• iOS senza app -> App Store
• Android con app -> app
• Android senza app -> Google Play
• desktop -> landing o pagina QR

Non lasciare questo comportamento sottinteso.

6. Testa nei contesti reali

Verifica almeno:

• iPhone Safari
• Android Chrome
• browser in-app delle campagne social
• desktop
• QR da scansione mobile
• link con parametri UTM

È lì che vedi la differenza tra "il link risponde" e "l’esperienza completa è corretta".

Errori frequenti

Pensare che il routing per dispositivo sostituisca Universal Links e App Links

Non è così. Il routing sceglie la destinazione. Universal Links e App Links sbloccano l’apertura nativa affidabile.

Dimenticare desktop

Se il fallback desktop è lasciato al caso, si rompono facilmente pagine di supporto, documentazione, sales enablement e flussi QR.

Perdere i parametri di campagna

Se i link passano da email, QR, paid social o campagne partner, gli UTM vanno preservati intenzionalmente.

Sommare troppi passaggi

Più shortener, redirect intermedi e pagine ponte aggiungi, più il debugging diventa lento.

Dove entra UrlEdge

UrlEdge è utile quando vuoi combinare:

• URL pubblica di marca
• routing per dispositivo
• fallback verso store o web
• conservazione UTM
• analytics del clic
• pubblicazione dei file di verifica all’edge

Non sostituisce da solo tutta la parte di mobile attribution avanzata. Ma rimette sotto controllo la parte più visibile: il link pubblico e il comportamento di fallback.

In sintesi

Dopo Firebase Dynamic Links, la soluzione migliore raramente è "un’altra scatola nera". Più spesso è una struttura più pulita:

• dominio di marca
• routing per dispositivo
• Universal Links e App Links verificati bene
• fallback esplicito
• parametri di campagna conservati

Meno magia. Più controllo.