Migra da Firebase Dynamic Links a Elido

Firebase Dynamic Links e' stato chiuso il 2025-08-25. Ogni link FDL restituisce ora 404. Se la tua app li stava usando per l'attribuzione delle installazioni, il deferred deep linking o il routing post-installazione a una schermata specifica, questi flussi sono interrotti in produzione adesso. Branch.io parte da $199/mese per il livello che sostituisce cio' che FDL faceva gratuitamente. Il routing deep link di Elido copre gli stessi pattern a una frazione del costo, con residenza dei dati UE inclusa.

Questo e' il percorso piu' breve dai link FDL rotti a Universal Links e Android App Links funzionanti.

Riepilogo

• Firebase Dynamic Links e' stato chiuso il 25 agosto 2025; tutti gli URL *.page.link restituiscono HTTP 404 da quella data, secondo le FAQ sulla deprecazione di Firebase Dynamic Links
• L'attribuzione delle installazioni, il routing post-installazione e i deferred deep link della tua app sono interrotti se non hai gia' migrato
• La migrazione e' una modifica DNS, due file JSON (uno Apple, uno Google) e una riscrittura dei link - non una riscrittura del codice
• Il livello entry-level di Branch.io per questo caso d'uso e' $199/mese; Elido Pro copre lo stesso routing a un costo sostanzialmente inferiore senza metering per link
• Non devi toccare il codice di gestione del deep link esistente in Swift o Kotlin - l'handoff Universal Link / App Link a livello OS funziona allo stesso modo indipendentemente da quale servizio ospita il routing

Cosa faceva davvero Firebase Dynamic Links

FDL era la risposta di Google a tre problemi che i normali link HTTPS non possono risolvere da soli.

Deferred deep linking. Un utente su un dispositivo senza la tua app clicca un link. Il sistema operativo apre l'App Store o il Play Store. L'utente installa l'app. L'app si apre su una schermata home generica e non sa che l'utente stava cercando di raggiungere un contenuto specifico. FDL memorizzava la destinazione prevista e la passava attraverso il gap di installazione - l'app poteva interrogare l'SDK di FDL al primo avvio e instradare l'utente alla schermata giusta.

Attribuzione delle installazioni. I link FDL trasportavano parametri di campagna (utm_source, utm_medium, parametri personalizzati tramite ?st= e ?si=) che sopravvivevano all'installazione. Questo e' il meccanismo che permetteva di attribuire un'installazione a una specifica campagna email, creativita' social a pagamento o link di influencer senza un MMP di terze parti.

Routing platform-aware. Un link, tre destinazioni: gli utenti iOS andavano all'App Store (o direttamente nell'app se installata), gli utenti Android andavano al Play Store (o nell'app) e i browser desktop ricevevano un URL di fallback configurabile. Il routing avveniva lato server all'edge di Google, non nel codice della tua app.

Quando FDL e' andato giu', tutte e tre queste capacita' sono andate a 404 simultaneamente. Se stavi usando l'SDK FDL nella tua app, sta chiamando un endpoint che non esiste piu'.

L'equivalente Elido

Elido replica gli stessi tre comportamenti attraverso il rilevamento della piattaforma all'edge di reindirizzamento e meccanismi di deep link nativi del sistema operativo.

Rilevamento della piattaforma all'edge. Un short link Elido ispeziona l'header User-Agent al momento del reindirizzamento e instrада verso destinazioni diverse in base alla piattaforma: iOS → URL App Store (o universal link dell'app), Android → URL Play Store (o intent app link), desktop → il tuo fallback web. Questo accade in meno di 5ms al piano di reindirizzamento. Nessuna chiamata SDK, nessun round-trip a un servizio di attribuzione separato.

iOS Universal Links. Quando la tua app e' installata sul dispositivo, iOS intercetta il link HTTPS prima che il browser si apra. Questo richiede di servire un file Apple App Site Association (apple-app-site-association) dal percorso well-known del tuo dominio personalizzato. Elido ospita questo file per tuo conto quando configuri un dominio personalizzato con il routing deep link abilitato. Il risultato e' identico a cio' che FDL forniva: l'app si apre direttamente alla schermata linkata.

Android App Links. Stesso meccanismo su Android, formato di file diverso. Il file assetlinks.json di Google si trova in /.well-known/assetlinks.json sul tuo dominio. Elido genera e serve questo file quando fornisci il nome del pacchetto della tua app e l'impronta digitale del certificato SHA-256. Gli Android App Links aprono la tua app direttamente senza un interstitial del browser.

Pass-through del deferred deep link. Per il caso del gap di installazione (l'utente non ha ancora l'app), Elido memorizza la destinazione deep link prevista rispetto allo short URL e la espone tramite un endpoint di query leggero. La tua app chiama questo endpoint al primo avvio con lo short URL da cui e' stata installata - recuperabile dal referrer di installazione su Android (INSTALL_REFERRER) e dall'API di attribuzione dell'App Store su iOS - e riceve il percorso deep link originale. Nessun SDK FDL, nessun handshake proprietario. La guida ai deep link copre il contratto dell'endpoint di query.

La pagina completa della funzione e' su /features/deep-links.

Migrazione passo-passo

Questo assume che tu abbia un account Elido su Pro o superiore e un dominio personalizzato che controlli. Concedi 30 minuti per una migrazione semplice; aggiungi un buffer se il volume dei tuoi link FDL e' abbastanza grande da richiedere uno script di riscrittura in blocco.

Passo 1: aggiungi il tuo dominio personalizzato a Elido

Nel dashboard Elido, vai su Workspace → Domini personalizzati → Aggiungi dominio. Inserisci il tuo dominio branded previsto (es. links.yourapp.com). Elido ti mostrera' un record CNAME da creare.

Nel tuo registrar DNS, aggiungi il CNAME:

links.yourapp.com.  CNAME  cname.elido.me.

Raccomandazione TTL: abbassalo a 300 secondi qualche ora prima di fare questo se e' attualmente a 3600+. Il provisioning TLS e' automatico tramite il TLS automatico on-demand e si completa entro pochi minuti dalla propagazione DNS.

Passo 2: configura iOS Universal Links (file AASA)

Nelle impostazioni del dominio, abilita Routing deep link e fornisci:

• Il tuo bundle identifier iOS (es. com.yourcompany.yourapp)
• I pattern del percorso URL che dovrebbero aprire l'app (es. /l/* per tutti i short link, o percorsi specifici)

Elido genera e serve il file AASA su https://links.yourapp.com/.well-known/apple-app-site-association. Verifica che si risolva correttamente prima di procedere:

curl -s https://links.yourapp.com/.well-known/apple-app-site-association | python3 -m json.tool

La risposta dovrebbe includere il tuo bundle ID nell'array applinks.details. Il CDN iOS mette in cache il file AASA e lo aggiorna secondo un programma; forza un aggiornamento nel testing reimpostando la cache AASA del dispositivo tramite Sviluppatore → Reimposta nelle Impostazioni iOS, o installando l'app da zero.

Il file Info.plist della tua app deve dichiarare il dominio associato. Se lo fa gia' per il tuo dominio FDL, aggiungi il nuovo dominio insieme ad esso durante il periodo di sovrapposizione:

<key>com.apple.developer.associated-domains</key>
<array>
  <string>applinks:links.yourapp.com</string>
  <!-- mantieni il dominio FDL durante la sovrapposizione se necessario -->
</array>

Passo 3: configura Android App Links (assetlinks.json)

Nello stesso pannello delle impostazioni deep link, fornisci:

• Il nome del pacchetto della tua app (es. com.yourcompany.yourapp)
• L'impronta digitale SHA-256 del tuo certificato di firma release

Recupera l'impronta digitale se non ce l'hai in cache:

keytool -list -v -keystore release.keystore -alias your-alias | grep SHA256

Elido genera e serve il file su https://links.yourapp.com/.well-known/assetlinks.json. Verifica:

curl -s https://links.yourapp.com/.well-known/assetlinks.json | python3 -m json.tool

Il filtro intent del tuo AndroidManifest.xml dovrebbe gia' essere configurato per App Links se stavi usando FDL con la funzione auto-verify dell'SDK Android. In caso contrario, aggiungi l'attributo android:autoVerify="true" al tuo filtro intent per i deep link e puntalo al nuovo dominio.

Passo 4: riscrivi i tuoi link FDL esistenti

I link FDL hanno la forma https://yourapp.page.link/SLUG o https://yourapp.page.link/?link=https%3A%2F%2F...&.... Nessuno dei due pattern continuera' a funzionare - il dominio page.link e' morto.

Se hai coniato un numero ridotto di link FDL (meno di qualche centinaio), riscrivili manualmente nel dashboard Elido. Se ne hai coniati migliaia - comune per campagne email o stampe di codici QR - usa l'API di importazione bulk di Elido:

curl -X POST https://api.elido.app/v1/links/bulk \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "links": [
      {
        "slug": "welcome",
        "destination": "https://yourapp.com/welcome",
        "routing": {
          "ios": "https://apps.apple.com/app/id12345678",
          "android": "https://play.google.com/store/apps/details?id=com.yourcompany.yourapp",
          "fallback": "https://yourapp.com/welcome"
        }
      }
    ]
  }'

Per i link gia' stampati su materiali fisici (packaging, poster, biglietti da visita), non puoi aggiornare l'URL stesso - ma se l'URL stampato era un link FDL su dominio personalizzato che punta a un dominio che controlli, puoi reindirizzare il CNAME di quel dominio su Elido e il link stampato iniziera' a funzionare di nuovo con la tua nuova configurazione di routing.

Passo 5: aggiorna la query del deferred deep link al primo avvio della tua app

Le app FDL chiamano FirebaseDynamicLinks.dynamicLinks().handleUniversalLink(url) o il metodo SDK equivalente al primo avvio. Rimuovilo. Sostituiscilo con una chiamata all'endpoint di deferred deep link di Elido:

// iOS - al primo avvio dopo l'installazione
let installURL = "https://links.yourapp.com/welcome" // recuperato dall'attribuzione StoreKit
let endpoint = URL(string: "https://api.elido.app/v1/deferred?url=\(installURL.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed)!)")!
URLSession.shared.dataTask(with: endpoint) { data, _, _ in
    guard let data, let result = try? JSONDecoder().decode(DeferredLink.self, from: data) else { return }
    DispatchQueue.main.async { self.navigate(to: result.deepLink) }
}.resume()

L'equivalente Android usa la Play Install Referrer API per recuperare lo short URL, poi chiama lo stesso endpoint. La guida ai deep link ha esempi di codice completi per entrambe le piattaforme.

Passo 6: testa end-to-end

Prima di effettuare il cutover, testa i tre casi:

1. App installata, link cliccato sul dispositivo - tocca lo short link in Safari/Chrome, conferma che l'app si apre direttamente alla schermata giusta senza un interstitial del browser.
2. App non installata, link cliccato - tocca il link, conferma che instrада alla pagina corretta dell'App Store / Play Store.
3. App installata dallo store dopo aver cliccato il link - installa l'app da zero, conferma che si apre alla schermata prevista al primo avvio (percorso deferred deep link).

Testa su un dispositivo fisico per Universal Links. I simulatori iOS non eseguono in modo affidabile l'handoff AASA.

Casi limite

Parametri FDL che leggevi nell'app. Se la tua app chiamava DynamicLink.dynamicLink().url per leggere i parametri da un link FDL dopo l'apertura, quei parametri sono ora scomparsi. Devi codificare le stesse informazioni nell'URL di destinazione del tuo short link Elido come parametri di query e leggerli dall'URL del deep link che iOS o Android consegna alla tua app. La codifica dei parametri e' la stessa - ?screen=onboarding&ref=email_april - semplicemente spostata dal wrapper proprietario link= di FDL nell'URL di destinazione stesso.

Perdita di attribuzione. L'attribuzione di FDL era autonoma: Google memorizzava i parametri della campagna e li restituiva all'SDK. Elido memorizza i dati degli eventi di clic (timestamp, piattaforma, paese, referrer) nel nostro archivio di analisi e li espone tramite l'API analytics, ma non e' un MMP (mobile measurement partner). Se hai bisogno di un'attribuzione delle installazioni probabilistica o deterministica su larga scala - analisi della coorte, LTV per fonte di acquisizione, stitching SKAdNetwork - hai bisogno di un MMP (Adjust, AppsFlyer) o di instrumentare il webhook dei clic Elido nella tua pipeline analytics. Per la maggior parte delle app indie e dei team nelle prime fasi che usavano FDL esclusivamente per "instrada l'utente alla schermata giusta", le analytics di Elido sono sufficienti. Per i team di acquisizione a pagamento che gestiscono l'attribuzione multicanale, vedi la sezione successiva.

URL short FDL esistenti gia' incorporati nel binario della tua app. Se hai hardcodato URL short FDL nel codice della tua app (payload di notifiche push generati lato client, link di referral coniati dall'app), quelle stringhe fanno riferimento a un dominio morto. Hai bisogno di un aggiornamento forzato dell'app o di un endpoint lato server che generi il nuovo short URL on demand. Non c'e' modo di reindirizzare page.link - Google ha chiuso completamente il dominio.

URL FDL lunghi con parametri codificati. FDL supportava URL in forma lunga come https://yourapp.page.link/?link=https%3A%2F%2F...&ibi=com.yourapp&ifl=...&afl=.... Questi parametri (ibi, ifl, afl, isi) sono specifici di FDL. Mappali ai campi di routing Elido: ifl (fallback iOS) → routing.ios, afl (fallback Android) → routing.android, ibi (bundle ID iOS) e' gia' configurato a livello di dominio in Elido. Il parametro link diventa il tuo URL di destinazione.

Residenza dei dati UE. Se la tua app opera nell'UE e tratti dati di utenti UE, gli eventi di reindirizzamento - inclusi indirizzi IP e stringhe User-Agent - sono dati personali ai sensi del GDPR. FDL era ospitato sull'infrastruttura globale di Google con elaborazione negli USA. Elido e' ospitato di default nella regione UE; gli eventi di clic UE rimangono nell'UE. La pagina trust e la panoramica sulla conformita' coprono le specifiche contrattuali.

Quando hai davvero bisogno di Branch.io invece

Elido e' la scelta giusta per la maggior parte delle app che usavano FDL per il routing delle schermate e l'attribuzione di base delle installazioni. Non e' la scelta giusta se dipendi da:

Attribuzione probabilistica per la UA a pagamento. Branch si integra con le reti pubblicitarie (Meta, Google, TikTok, Snap) tramite postback e puo' attribuire le installazioni probabilisticamente quando l'impronta digitale deterministica non e' disponibile - es. su iOS 14.5+ con ATT non acconsentito. Elido non fa attribuzione probabilistica. Se il tuo team di crescita sta gestendo UA a pagamento e ha bisogno di riconciliare le installazioni con la spesa pubblicitaria a livello di coorte, Branch o un MMP (Adjust, AppsFlyer) e' lo strumento giusto per quel problema specifico.

Fingerprinting a livello SDK e matching dei dispositivi. L'SDK di Branch raccoglie segnali del dispositivo (risoluzione dello schermo, IP, lingua, fuso orario) per identificare un dispositivo attraverso il gap di installazione senza fare affidamento su un referrer di installazione. Il matching solo basato su referrer degrada in ambienti dove il referrer viene rimosso - se il tuo tasso di successo del deferred deep link deve superare l'80% circa, l'approccio a livello SDK funziona meglio.

Integrazione profonda con specifiche reti pubblicitarie. Branch ha integrazioni dedicate con la CAPI di Meta, il tracciamento delle conversioni di Google e l'API degli eventi di TikTok che vanno oltre cio' che il forwarding delle conversioni lato server di Elido copre. Se il tuo stack di attribuzione e' strettamente accoppiato a una di quelle reti, valuta la documentazione specifica di integrazione di Branch prima di passare.

Il test pratico: se stavi usando FDL principalmente per instradare gli utenti alla schermata giusta dopo l'installazione, e le tue esigenze di attribuzione sono coperte dai parametri UTM nel tuo strumento analytics, Elido sostituisce FDL a un costo inferiore. Se stai gestendo performance marketing su larga scala e l'accuratezza dell'attribuzione guida le decisioni di budget, questa e' la proposta di valore effettiva di Branch e $199/mese compra infrastruttura reale per quello.

FAQ

La mia app ha short link FDL nei payload delle notifiche push - cosa succede quando gli utenti li toccano?

I link puntano a page.link, che restituisce 404. La gestione dei link del sistema operativo passa il 404 al browser o al gestore universal link della tua app, che fallira'. Devi aggiornare il tuo servizio di notifiche push per generare short link Elido. Se generi i payload push lato server (l'approccio corretto), e' una modifica di una riga per chiamare l'API Elido invece dell'API FDL. Se i payload vengono generati lato client da template hardcoded, hai bisogno di un aggiornamento dell'app.

Devo rilasciare un aggiornamento dell'app per completare la migrazione?

Per la query del deferred deep link (routing attraverso il gap di installazione), si - devi sostituire la chiamata all'SDK FDL con la chiamata all'endpoint Elido, che richiede un aggiornamento dell'app. Per Universal Links e Android App Links verso l'app gia' installata, non e' necessario alcun aggiornamento dell'app una volta che DNS e i file AASA/assetlinks.json sono a posto - il sistema operativo interroga questi file dal server, non dal binario dell'app. L'unica eccezione: se il tuo Info.plist / AndroidManifest.xml non dichiara ancora il tuo nuovo dominio come dominio associato, questo richiede un aggiornamento dell'app.

Cosa succede ai clic sui vecchi link FDL dopo aver completato la migrazione?

Se il vecchio link era su un dominio page.link: niente - quel dominio e' morto e quei link sono irrecuperabili. Se stavi usando un dominio personalizzato per FDL (meno comune ma supportato), reindirizza il CNAME del dominio su Elido e configura regole di routing equivalenti; i vecchi URL inizieranno a risolvere di nuovo.

Elido ha un SDK?

Elido non richiede un SDK per Universal Links o App Links - questi sono meccanismi nativi del sistema operativo. Per l'endpoint di query del deferred deep link, fai una chiamata HTTPS standard; non e' necessaria alcuna dipendenza SDK. Se vuoi un client tipizzato, l'Elido Go SDK, il TypeScript SDK e il Python SDK wrappano tutti l'API deep link, ma non c'e' un SDK iOS/Android e non ne hai bisogno. Questo e' intenzionale - meno SDK di terze parti in un'app in produzione, meglio e'.

Quanto tempo richiede la propagazione di AASA / assetlinks.json?

Una volta propagato il DNS (da pochi minuti a un'ora a seconda del TTL), i file AASA e assetlinks.json sono immediatamente disponibili dall'edge di Elido. iOS aggiorna la sua copia in cache del file AASA all'installazione dell'app e periodicamente in seguito; il ritardo che noterai nei test e' la stale della cache di iOS, non la latenza di serving di Elido. Per un test pulito, installa l'app da zero dopo che la modifica DNS si e' propagata.

---

Se stai guardando il set completo di funzionalita' deep link, la pagina /features/deep-links copre la matrice di supporto della piattaforma e la profondita' delle regole di routing. Per le specifiche sulla residenza dei dati UE rilevanti per le app mobili che raccolgono dati di utenti UE, la panoramica sulla conformita' ha il DPA e l'elenco dei sub-responsabili che il tuo team privacy richiechera'.

Correlati sul blog

• Deep link senza SDK: come funzionano davvero Universal Links e App Links
• Residenza dei dati UE per gli strumenti di marketing: cosa chiede davvero il tuo DPO
• Smart link spiegati: routing per dispositivo, geo, orario e referrer
• Migrare da Bitly senza rompere i link: un playbook sui modi di fallimento