UrlEdge
Torna al blog
2026-03-16 UrlEdge Editorial8 min read

Alternativa a Firebase Dynamic Links dopo la chiusura

Firebase Dynamic Links è stato dismesso il 25 agosto 2025. Ecco come sostituirlo con smart link brandizzati, app link e fallback controllati.

Smartphone accanto a un laptop per rappresentare deep link mobile, routing app e migrazione smart link

Se nel 2026 stai cercando un'alternativa a Firebase Dynamic Links, il primo passo è separare ciò che ti serve davvero da ciò che il vecchio prodotto metteva nello stesso pacchetto.

Molti team non hanno bisogno di ricostruire un'intera piattaforma di deep linking. Hanno bisogno di tre cose più concrete:

  • una URL HTTPS con dominio del brand
  • routing affidabile per dispositivo
  • fallback puliti per desktop, mobile web e store

Meno team hanno davvero bisogno di deferred deep linking completo o attribuzione mobile post-installazione. Questa distinzione cambia costo, stack e tempi di migrazione.

Secondo la FAQ ufficiale di Firebase Dynamic Links, Firebase Dynamic Links è stato deprecato e la chiusura era prevista per il 25 agosto 2025. Se campagne, QR code, onboarding mobile o link di referral dipendevano ancora da quelle URL, ora conviene ricostruire il livello dei link con primitive stabili: domini personalizzati, redirect HTTP, file di associazione app nativi e destinazioni fallback esplicite.

Se questa sostituzione fa parte di una migrazione più ampia del sito o del dominio, tieni aperta anche la checklist redirect per migrazioni sito. Gli errori sono spesso gli stessi: inventario incompleto e fallback non documentati.

Per cosa veniva usato Firebase Dynamic Links

Quando un team dice di cercare un sostituto per Firebase Dynamic Links, di solito intende uno di questi casi:

  1. mandare utenti iPhone su App Store e utenti Android su Google Play
  2. mandare visitatori desktop a una landing page o a una pagina con QR code
  3. condividere una URL breve e brandizzata invece di un link lungo allo store
  4. mantenere parametri campagna per analytics e attribuzione
  5. aprire l'app installata quando possibile

Non sono lo stesso problema.

[!TIP] La migrazione più veloce raramente è "sostituire Firebase funzione per funzione". Di solito è "sostituire solo i comportamenti da cui marketing e prodotto dipendono davvero".

Albero decisionale rapido

Ti serve solo smart routing

Se il tuo obiettivo è:

  • iOS -> App Store
  • Android -> Google Play
  • desktop -> sito web o pagina con QR code

allora un layer di smart redirect può bastare. È il caso più pulito per uno strumento come UrlEdge Device Targeting.

Vuoi aprire l'app installata

Se vuoi che:

  • l'app iOS installata si apra direttamente
  • l'app Android installata si apra direttamente
  • gli utenti senza app vadano allo store o al web

ti servono due livelli:

  1. un layer di routing del link
  2. configurazione nativa di app link su app e dominio

Questo significa pubblicare correttamente i file AASA e assetlinks.json, e verificare che l'app sappia gestire il path di destinazione.

Ti serve deferred deep linking o attribuzione

Se il team growth dipende da:

  • attribuzione installazione
  • routing post-install verso una schermata precisa
  • matching campagna lungo il funnel di installazione

non dare per scontato che un generico servizio redirect basti. In quel caso usa un layer di redirect per il controllo delle URL brandizzate e abbinalo allo stack mobile che già gestisce attribuzione e stato app.

Architettura pratica per sostituire Firebase Dynamic Links

Per molti team la migrazione assomiglia a questo schema:

Laptop e smartphone usati insieme per rappresentare smart link brandizzati, device targeting e fallback verso app store

smart.tuobrand.it/promo
  -> rilevamento dispositivo all'edge
  -> iOS: App Store o target Universal Link
  -> Android: Google Play o target App Link
  -> Desktop: landing page, docs o pagina QR

Questa architettura ha vantaggi concreti:

  • il dominio resta sotto il tuo controllo
  • il fallback è esplicito e testabile
  • i link marketing non dipendono da un vendor mobile
  • puoi aggiungere analytics, regole geografiche o override temporanei in seguito

Per team che devono soprattutto gestire routing e fallback, è spesso più semplice di ricostruire una piattaforma monolitica di deep linking.

Piano di migrazione

1. Fai l'inventario di tutti i Dynamic Link attivi

Non migrare a memoria. Esporta tutti i link ancora usati da:

  • campagne paid
  • email lifecycle
  • bio social
  • QR code
  • documenti partner
  • onboarding mobile
  • referral in-app

Crea un foglio con almeno queste colonne:

old_dynamic_link,owner,use_case,ios_destination,android_destination,desktop_destination,notes
https://xyz.page.link/saldi,growth,download app,https://apps.apple.com/app/...,https://play.google.com/store/apps/...,https://tuobrand.it/saldi,campagna stagionale

Questo evita il classico errore: engineering migra i link ovvi e marketing scopre due settimane dopo che QR code o email vecchie puntano ancora a destinazioni sbagliate.

2. Classifica i link per comportamento

Raggruppa ogni link in una categoria:

  1. solo fallback store
  2. solo fallback web
  3. app link nativo con fallback
  4. logica speciale per campagna, paese o dispositivo

La classificazione ti dice se basta una piattaforma redirect o se serve anche lavoro nell'app.

3. Sposta i link brandizzati su un dominio tuo

La migrazione è il momento giusto per smettere di dipendere da short domain di prodotto quando possibile. Un dominio tuo ti dà:

  • controllo su DNS e HTTPS
  • proprieta di lungo periodo dei link
  • maggiore coerenza di brand
  • meno lock-in

Un dominio come go.tuobrand.it o link.tuobrand.it è spesso più facile da governare rispetto a mescolare app link e marketing sul dominio principale.

4. Definisci destinazioni esplicite per piattaforma

Non lasciare "fallback" come parola vaga. Scrivilo.

Esempio:

  • iPhone -> App Store
  • Android -> Google Play
  • desktop -> landing page con QR code
  • tablet -> web o store, secondo il prodotto

Se sai gia che ti serve comportamento per dispositivo, usa routing per dispositivo invece di forzare tutto dentro una destinazione unica.

5. Configura gli app link nativi dove servono

Se l'app installata deve aprirsi direttamente, completa la parte nativa:

Questo è il pezzo che molti team sottostimano. Un livello di redirect può instradare bene il traffico, ma non può inventare la gestione nativa dei link dentro l'app.

6. Testa su dispositivi reali

Al minimo testa:

  • iPhone Safari
  • browser in-app su iPhone
  • Android Chrome
  • browser in-app Android
  • desktop Chrome
  • desktop Safari

Testa anche con:

  • app installata
  • app non installata
  • parametri campagna presenti
  • scansione QR da desktop

Per debug, uno strumento come Redirect Checker ti mostra il comportamento reale del redirect invece di farti indovinare dai dashboard campagna.

Errori comuni

Trattare tutto come un unico requisito

Fallback store, apertura dell'app installata e deferred deep linking sono requisiti diversi. Se li metti nello stesso blocco, rischi di comprare troppo o costruire troppo poco.

Dimenticare il desktop

Molti progetti mobile-link si rompono su desktop perché ottimizzano solo iOS e Android. Il fallback desktop è parte dell'esperienza prodotto.

Perdere i parametri campagna

Se i vecchi link portavano utm_, codici creator o parametri paid, preservali deliberatamente. Non assumere che ogni percorso li mantenga di default.

Aspettare il monitoraggio post-lancio

Una migrazione senza osservabilità è solo speranza. Devi poter vedere clic, destinazioni fallite e pattern anomali subito con analytics.

Dove UrlEdge funziona bene

UrlEdge è adatto quando la sostituzione riguarda soprattutto controllo del routing:

  • domini personalizzati brandizzati
  • fallback App Store e Google Play
  • fallback web per desktop
  • regole per dispositivo
  • regole geografiche
  • validazione redirect
  • analytics all'edge

È particolarmente utile quando vuoi che il layer di routing sia indipendente dal ciclo di release dell'app.

Se ti servono anche attribuzione post-installazione pesante o deferred deep linking avanzato, mantieni lo scope onesto: usa UrlEdge per il routing del traffico e abbinalo allo stack mobile che possiede attribuzione e stato app.

FAQ

Sì. È uno dei pattern più comuni: una URL brandizzata può mandare iOS su App Store, Android su Google Play e desktop su web o pagina QR.

Sì, se vuoi aprire direttamente l'app installata. Redirect HTTP e associazioni native risolvono livelli diversi del problema.

La migrazione è spesso più semplice del previsto. In molti casi bastano smart link per dispositivo, fallback store espliciti e gestione corretta delle query campagna.

Meglio di no. Parti da inventario, classificazione e destinazioni in blocco. È molto più sicuro di una sostituzione manuale caso per caso.

Guide correlate UrlEdge

Riferimenti autorevoli

Pronto a ottimizzare i tuoi reindirizzamenti?

Usa UrlEdge per gestire redirect, domini e traffico all'Edge da un unico posto.

Inizia

Articoli correlati

Visualizza tutto