Von Firebase Dynamic Links zu Elido migrieren

Firebase Dynamic Links wurde am 2025-08-25 abgeschaltet. Jeder FDL-Link liefert jetzt 404 zurück. Wenn Ihre App sie für Install-Attribution, Deferred Deep Linking oder Post-Install-Routing zu einem bestimmten Screen genutzt hat, sind diese Abläufe jetzt in der Produktion unterbrochen. Branch.io beginnt bei 199 Dollar pro Monat für die Stufe, die das ersetzt, was FDL kostenlos getan hat. Elidons Deep-Link-Routing deckt dieselben Muster zu einem Bruchteil der Kosten ab, mit integriertem EU-Datenspeicherort.

Das ist der kürzeste Weg von defekten FDL-Links zu funktionierenden Universal Links und Android App Links.

Kurzzusammenfassung

• Firebase Dynamic Links wurde am 25. August 2025 abgeschaltet; alle *.page.link-URLs geben ab diesem Datum HTTP 404 zurück, gemäß den Firebase Dynamic Links Deprecation-FAQ
• Install-Attribution, Post-Install-Routing und Deferred Deep Links Ihrer App sind unterbrochen, wenn Sie noch nicht migriert haben
• Die Migration ist eine DNS-Änderung, zwei JSON-Dateien (eine für Apple, eine für Google) und eine Link-Neuerstellung - kein Code-Umbau
• Branchs Einstiegsstufe für diesen Anwendungsfall kostet 199 Dollar pro Monat; Elido Pro deckt dasselbe Routing zu deutlich niedrigeren Kosten ohne klickbasierte Abrechnung ab
• Sie müssen Ihren bestehenden Deep-Link-Behandlungscode in Swift oder Kotlin nicht anfassen - der betriebssystemseitige Universal-Link-/App-Link-Übergabemechanismus funktioniert gleich, unabhängig davon, welcher Dienst das Routing hostet

Was Firebase Dynamic Links tatsächlich geleistet hat

FDL war Googles Antwort auf drei Probleme, die einfache HTTPS-Links allein nicht lösen können.

Deferred Deep Linking. Ein Nutzer auf einem Gerät ohne Ihre App klickt auf einen Link. Das Betriebssystem öffnet den App Store oder Play Store. Der Nutzer installiert die App. Die App öffnet sich auf einem generischen Startbildschirm und weiß nicht, dass der Nutzer versucht hat, bestimmte Inhalte aufzurufen. FDL speicherte das beabsichtigte Ziel und übertrug es über die Installationslücke - die App konnte beim ersten Start das FDL-SDK abfragen und den Nutzer zum richtigen Screen leiten.

Install-Attribution. FDL-Links trugen Kampagnenparameter (utm_source, utm_medium, benutzerdefinierte Parameter über ?st= und ?si=), die die Installation überlebten. Das war der Mechanismus, mit dem Sie eine Installation einem bestimmten E-Mail-Kampagnen-, bezahlten Social-Creative- oder Influencer-Link zuordnen konnten - ohne ein Drittanbieter-MMP.

Plattformbasiertes Routing. Ein Link, drei Ziele: iOS-Nutzer gelangten zum App Store (oder tief in die App, wenn installiert), Android-Nutzer zum Play Store (oder die App), und Desktop-Browser erhielten eine konfigurierbare Fallback-URL. Das Routing fand serverseitig am Google-Edge statt, nicht in Ihrem App-Code.

Als FDL abgeschaltet wurde, lieferten alle drei Fähigkeiten gleichzeitig 404 zurück. Wenn Sie das FDL-SDK in Ihrer App verwendeten, ruft es einen Endpunkt auf, der nicht mehr existiert.

Das Elido-Äquivalent

Elido repliziert dieselben drei Verhaltensweisen durch Plattformerkennung am Redirect-Edge und standardmäßige betriebssystemseitige Deep-Link-Mechanismen.

Plattformerkennung am Edge. Ein Elido-Kurzlink untersucht den User-Agent-Header zum Weiterleitungszeitpunkt und leitet je nach Plattform an verschiedene Ziele weiter: iOS an die App-Store-URL (oder App Universal Link), Android an die Play-Store-URL (oder App-Link-Intent), Desktop an Ihren Web-Fallback. Das geschieht in unter 5 ms auf der Redirect-Ebene. Kein SDK-Aufruf, kein Roundtrip zu einem separaten Attributionsdienst.

iOS Universal Links. Wenn Ihre App auf dem Gerät installiert ist, fängt iOS den HTTPS-Link ab, bevor der Browser öffnet. Dazu muss eine Apple-App-Site-Association-(apple-app-site-association-)Datei vom Well-known-Pfad Ihrer Custom Domain bereitgestellt werden. Elido hostet diese Datei in Ihrem Namen, wenn Sie eine Custom Domain mit aktiviertem Deep-Link-Routing konfigurieren. Das Ergebnis ist identisch mit dem, was FDL geliefert hat: die App öffnet sich direkt zum verlinkten Screen.

Android App Links. Gleicher Mechanismus auf Android, anderes Dateiformat. Googles assetlinks.json-Datei liegt unter /.well-known/assetlinks.json auf Ihrer Domain. Elido generiert und liefert diese Datei, wenn Sie den Paketnamen Ihrer App und den SHA-256-Zertifikat-Fingerabdruck angeben. Android App Links öffnen Ihre App direkt ohne Browser-Interstitial.

Deferred-Deep-Link-Durchleitung. Für den Installationslücken-Fall (Nutzer hat die App noch nicht) speichert Elido das beabsichtigte Deep-Link-Ziel gegen die Kurzlink-URL und stellt es über einen leichtgewichtigen Abfrage-Endpunkt bereit. Ihre App ruft diesen Endpunkt beim ersten Start mit der Kurzlink-URL auf, von der aus sie installiert wurde - abrufbar über den Install-Referrer auf Android (INSTALL_REFERRER) und die App-Store-Attributions-API auf iOS - und erhält den ursprünglichen Deep-Link-Pfad zurück. Kein FDL-SDK, kein proprietärer Handshake. Der Deep-Links-Leitfaden beschreibt den Abfrage-Endpunkt-Vertrag.

Die vollständige Feature-Seite finden Sie unter /features/deep-links.

Schritt-für-Schritt-Migration

Das setzt voraus, dass Sie ein Elido-Konto auf Pro oder höher und eine Custom Domain haben, die Sie kontrollieren. Rechnen Sie mit 30 Minuten für eine unkomplizierte Migration; planen Sie mehr Zeit ein, wenn Ihr FDL-Link-Volumen groß genug ist, um ein Bulk-Neuschreibskript zu erfordern.

Schritt 1: Ihre Custom Domain zu Elido hinzufügen

Gehen Sie im Elido-Dashboard zu Workspace - Custom domains - Add domain. Geben Sie Ihre beabsichtigte Branded Domain ein (z.B. links.yourapp.com). Elido zeigt Ihnen einen CNAME-Eintrag zum Erstellen an.

Fügen Sie bei Ihrem DNS-Registrar den CNAME ein:

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

TTL-Empfehlung: Senken Sie ihn einige Stunden vorher auf 300 Sekunden, wenn er derzeit bei 3600+ liegt. Die TLS-Bereitstellung erfolgt automatisch via On-Demand-TLS und wird innerhalb weniger Minuten nach DNS-Propagierung abgeschlossen.

Schritt 2: iOS Universal Links konfigurieren (AASA-Datei)

Aktivieren Sie in den Domain-Einstellungen Deep link routing und geben Sie an:

• Ihren iOS Bundle-Identifier (z.B. com.yourcompany.yourapp)
• Die URL-Pfadmuster, die die App öffnen sollen (z.B. /l/* für alle Kurzlinks oder bestimmte Pfade)

Elido generiert und liefert die AASA-Datei unter https://links.yourapp.com/.well-known/apple-app-site-association. Überprüfen Sie, ob sie korrekt auflöst, bevor Sie fortfahren:

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

Die Antwort sollte Ihre Bundle-ID im applinks.details-Array enthalten. iOS-CDN cached die AASA-Datei und aktualisiert sie planmäßig; erzwingen Sie eine Aktualisierung beim Testen, indem Sie den AASA-Cache des Geräts über Developer - Reset in den iOS-Einstellungen zurücksetzen oder die App frisch installieren.

Ihre App-Info.plist muss die Associated Domain deklarieren. Wenn sie das bereits für Ihre FDL-Domain tut, fügen Sie die neue Domain daneben hinzu, während der Überlappungszeitraum besteht:

<key>com.apple.developer.associated-domains</key>
<array>
  <string>applinks:links.yourapp.com</string>
  <!-- FDL-Domain während Überlappung falls nötig behalten -->
</array>

Schritt 3: Android App Links konfigurieren (assetlinks.json)

Geben Sie im selben Deep-Link-Einstellungsbereich an:

• Den Paketnamen Ihrer App (z.B. com.yourcompany.yourapp)
• Den SHA-256-Fingerabdruck Ihres Release-Signierzertifikats

Rufen Sie den Fingerabdruck ab, wenn Sie ihn nicht gecacht haben:

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

Elido generiert und liefert die Datei unter https://links.yourapp.com/.well-known/assetlinks.json. Überprüfen Sie:

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

Ihr AndroidManifest.xml-Intent-Filter sollte bereits für App Links konfiguriert sein, wenn Sie FDL mit der Auto-Verify-Funktion des Android SDK verwendet haben. Falls nicht, fügen Sie das Attribut android:autoVerify="true" zu Ihrem Deep-Link-Intent-Filter hinzu und zeigen Sie ihn auf die neue Domain.

Schritt 4: Ihre bestehenden FDL-Links neu schreiben

FDL-Links haben die Form https://yourapp.page.link/SLUG oder https://yourapp.page.link/?link=https%3A%2F%2F...&.... Kein Muster wird weiter funktionieren - die page.link-Domain ist tot.

Wenn Sie eine kleine Anzahl von FDL-Links erstellt haben (unter ein paar Hundert), schreiben Sie sie manuell im Elido-Dashboard neu. Wenn Sie Tausende erstellt haben - üblich bei E-Mail-Kampagnen oder QR-Code-Druckserien - verwenden Sie die Elido-Bulk-Import-API:

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"
        }
      }
    ]
  }'

Für bereits auf physischen Materialien gedruckte Links (Verpackungen, Poster, Visitenkarten) können Sie die URL selbst nicht aktualisieren - aber wenn die gedruckte URL ein Custom-Domain-FDL-Link war, der auf eine von Ihnen kontrollierte Domain zeigt, können Sie den CNAME dieser Domain auf Elido zeigen lassen, und der gedruckte Link funktioniert wieder mit Ihrer neuen Routing-Konfiguration.

Schritt 5: Die Deferred-Deep-Link-Abfrage beim ersten App-Start aktualisieren

FDL-Apps rufen beim ersten Start FirebaseDynamicLinks.dynamicLinks().handleUniversalLink(url) oder die entsprechende SDK-Methode auf. Entfernen Sie das. Ersetzen Sie es durch einen Aufruf des Elido-Deferred-Deep-Link-Endpunkts:

// iOS - beim ersten Start nach der Installation
let installURL = "https://links.yourapp.com/welcome" // über StoreKit-Attribution wiederhergestellt
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()

Das Android-Äquivalent nutzt die Play-Install-Referrer-API, um die Kurzlink-URL wiederherzustellen, und ruft dann denselben Endpunkt auf. Der Deep-Links-Leitfaden enthält vollständige Code-Beispiele für beide Plattformen.

Schritt 6: Ende-zu-Ende testen

Testen Sie vor dem Umschalten drei Fälle:

1. App installiert, Link auf Gerät angeklickt - tippen Sie auf den Kurzlink in Safari/Chrome und bestätigen Sie, dass die App sich direkt zum richtigen Screen öffnet, ohne Browser-Interstitial.
2. App nicht installiert, Link angeklickt - tippen Sie auf den Link und bestätigen Sie, dass er zur richtigen App-Store-/Play-Store-Seite weiterleitet.
3. App nach Link-Klick aus dem Store installiert - installieren Sie die App frisch und bestätigen Sie, dass sie sich beim ersten Start zum beabsichtigten Screen öffnet (Deferred-Deep-Link-Pfad).

Testen Sie auf einem physischen Gerät für Universal Links. iOS-Simulatoren führen den AASA-Handshake nicht zuverlässig durch.

Randfälle

FDL-Parameter, die Sie in der App gelesen haben. Wenn Ihre App DynamicLink.dynamicLink().url aufgerufen hat, um Parameter aus einem FDL-Link nach dem Öffnen zu lesen, sind diese Parameter jetzt verschwunden. Sie müssen dieselben Informationen als Query-Parameter in die Ziel-URL Ihres Elido-Kurzlinks codieren und sie aus der Deep-Link-URL lesen, die iOS oder Android an Ihre App liefert. Die Parametercodierung ist dieselbe - ?screen=onboarding&ref=email_april - nur aus dem proprietären link=-Wrapper von FDL in die Ziel-URL selbst verschoben.

Attributionsverlust. FDLs Attribution war eigenständig: Google speicherte die Kampagnenparameter und gab sie dem SDK zurück. Elido speichert Klick-Ereignisdaten (Zeitstempel, Plattform, Land, Referrer) in unserem Analysespeicher und stellt sie über die Analytics-API bereit, ist aber kein MMP (Mobile Measurement Partner). Wenn Sie probabilistische oder deterministische Install-Attribution im großen Maßstab benötigen - Kohortenanalyse, LTV nach Akquisitionsquelle, SKAdNetwork-Verknüpfung - benötigen Sie entweder ein MMP (Adjust, AppsFlyer) oder müssen den Elido-Klick-Webhook in Ihre eigene Analytics-Pipeline einbinden. Für die meisten Indie-Apps und frühe Teams, die FDL rein zum "Nutzer zum richtigen Screen leiten" verwendeten, reichen Elidons Analytics aus. Für Paid-Acquisition-Teams, die Multi-Channel-Attribution betreiben, lesen Sie den nächsten Abschnitt.

Bestehende page.link-Kurzlinks, die bereits in Ihrem App-Binary eingebettet sind. Wenn Sie FDL-Kurzlinks fest in Ihren App-Code codiert haben (clientseitig generierte Push-Notification-Payloads, in der App erstellte Referral-Links), verweisen diese Strings auf eine tote Domain. Sie benötigen ein erzwungenes App-Update oder einen serverseitigen Endpunkt, der die neue Kurzlink-URL on demand generiert. Es gibt keine Möglichkeit, page.link weiterzuleiten - Google hat die Domain vollständig abgeschaltet.

Lange FDL-URLs mit codierten Parametern. FDL unterstützte Langform-URLs wie https://yourapp.page.link/?link=https%3A%2F%2F...&ibi=com.yourapp&ifl=...&afl=.... Diese Parameter (ibi, ifl, afl, isi) sind FDL-spezifisch. Ordnen Sie sie Elido-Routing-Feldern zu: ifl (iOS Fallback) zu routing.ios, afl (Android Fallback) zu routing.android, ibi (iOS Bundle-ID) ist bereits auf Domain-Ebene in Elido konfiguriert. Der link-Parameter wird Ihre Ziel-URL.

EU-Datenspeicherort. Wenn Ihre App in der EU betrieben wird und Sie EU-Nutzerdaten verarbeiten, sind Weiterleitungsereignisse - einschließlich IP-Adressen und User-Agent-Strings - personenbezogene Daten im Sinne der DSGVO. FDL wurde auf Googles globaler Infrastruktur mit US-Verarbeitung gehostet. Elido wird standardmäßig in der EU-Region gehostet; EU-Klick-Ereignisse verbleiben in der EU. Die Trust-Seite und die Compliance-Übersicht decken die vertraglichen Einzelheiten ab.

Wann Sie tatsächlich Branch.io brauchen

Elido ist die richtige Wahl für die meisten Apps, die FDL für Screen-Routing und grundlegende Install-Attribution verwendeten. Es ist nicht die richtige Wahl, wenn Sie abhängig sind von:

Probabilistische Attribution für bezahlte UA. Branch integriert sich mit Werbenetzwerken (Meta, Google, TikTok, Snap) über Postbacks und kann Installationen probabilistisch zuordnen, wenn der deterministische Fingerabdruck nicht verfügbar ist - z.B. auf iOS 14.5+ ohne ATT-Einwilligung. Elido bietet keine probabilistische Attribution. Wenn Ihr Growth-Team bezahlte UA betreibt und Installationen gegen Werbeausgaben auf Kohortenebene abgleichen muss, ist Branch oder ein MMP (Adjust, AppsFlyer) das richtige Werkzeug für dieses spezifische Problem.

SDK-seitiges Fingerprinting und Geräteabgleich. Branchs SDK sammelt Gerätesignale (Bildschirmauflösung, IP, Sprache, Zeitzone), um ein Gerät über die Installationslücke hinweg ohne Install-Referrer zu identifizieren. Das allein auf dem Referrer basierende Matching verschlechtert sich in Umgebungen, wo der Referrer entfernt wird - wenn Ihre Trefferquote beim Deferred Deep Linking über ~80 % liegen muss, bietet der SDK-Ansatz bessere Leistung.

Tiefe Integration mit bestimmten Werbenetzwerken. Branch hat dedizierte Integrationen mit Metas CAPI, Googles Conversion-Tracking und TikToks Events-API, die über das hinausgehen, was Elidons serverseitige Conversion-Weiterleitung abdeckt. Wenn Ihr Attributions-Stack eng an eines dieser Netzwerke gekoppelt ist, prüfen Sie Branchs spezifische Integrationsdokumentation, bevor Sie wechseln.

Der praktische Test: Wenn Sie FDL hauptsächlich genutzt haben, um Nutzer nach der Installation zum richtigen Screen zu leiten, und Ihre Attributionsanforderungen durch UTM-Parameter in Ihrem Analytics-Tool abgedeckt sind, ersetzt Elido FDL zu niedrigeren Kosten. Wenn Sie Performance-Marketing im großen Maßstab betreiben und Attributionsgenauigkeit Budget-Entscheidungen steuert, ist das Branchs tatsächliches Wertversprechen, und 199 Dollar pro Monat kaufen echte Infrastruktur dafür.

FAQ

Meine App enthält FDL-Kurzlinks in Push-Benachrichtigungs-Payloads - was passiert, wenn Nutzer darauf tippen?

Die Links zeigen auf page.link, das 404 zurückgibt. Die Linkverarbeitung des Betriebssystems reicht den 404 an den Browser oder den Universal-Link-Handler Ihrer App weiter, was fehlschlägt. Sie müssen Ihren Push-Benachrichtigungsdienst aktualisieren, um stattdessen Elido-Kurzlinks zu generieren. Wenn Sie Push-Payloads serverseitig generieren (der richtige Ansatz), ist das eine Änderung in einer einzigen Zeile, um die Elido-API statt der FDL-API aufzurufen. Wenn Payloads clientseitig aus fest codierten Vorlagen generiert werden, ist ein App-Update erforderlich.

Muss ich ein App-Update ausliefern, um die Migration abzuschließen?

Für die Deferred-Deep-Link-Abfrage (Routing über die Installationslücke) ja - Sie müssen den FDL-SDK-Aufruf durch den Elido-Endpunkt-Aufruf ersetzen, was ein App-Update erfordert. Für Universal Links und Android App Links zur bereits installierten App ist kein App-Update erforderlich, sobald DNS und die AASA-/assetlinks.json-Dateien vorhanden sind - das Betriebssystem fragt diese Dateien vom Server ab, nicht aus dem App-Binary. Die Ausnahme: Wenn Ihre Info.plist/AndroidManifest.xml Ihre neue Domain noch nicht als Associated Domain deklariert, ist dafür ein App-Update erforderlich.

Was passiert mit Klicks auf alte FDL-Links nach Abschluss der Migration?

Wenn der alte Link auf einer page.link-Domain lag: nichts - diese Domain ist tot und die Links sind nicht wiederherstellbar. Wenn Sie eine Custom Domain für FDL genutzt haben (weniger verbreitet, aber unterstützt), zeigen Sie den CNAME der Domain auf Elido und konfigurieren äquivalente Routing-Regeln; die alten URLs beginnen dann wieder aufzulösen.

Hat Elido ein SDK?

Elido benötigt kein SDK für Universal Links oder App Links - das sind betriebssystemseitige Mechanismen. Für den Deferred-Deep-Link-Abfrage-Endpunkt machen Sie einen Standard-HTTPS-Aufruf; keine SDK-Abhängigkeit nötig. Wenn Sie einen typisierten Client möchten, umschließen das Elido Go SDK, das TypeScript SDK und das Python SDK alle die Deep-Link-API, aber es gibt kein iOS/Android SDK und Sie brauchen keines. Das ist Absicht - je weniger Drittanbieter-SDKs in einer Produktions-App, desto besser.

Wie lange dauert die AASA-/assetlinks.json-Propagierung?

Sobald Ihr DNS propagiert (einige Minuten bis eine Stunde je nach TTL), sind die AASA- und assetlinks.json-Dateien sofort von Elidons Edge verfügbar. iOS aktualisiert seine zwischengespeicherte Kopie der AASA-Datei bei der App-Installation und danach regelmäßig; die Verzögerung, die Sie beim Testen bemerken werden, ist iOS's Cache-Veralterung, nicht Elidons Auslieferungslatenz. Für einen sauberen Test installieren Sie die App frisch, nachdem die DNS-Änderung propagiert ist.

---

Wenn Sie sich den breiteren Deep-Linking-Funktionsumfang ansehen, deckt die /features/deep-links-Seite die Plattform-Support-Matrix und die Routing-Regeltiefe ab. Für EU-Datenspeicherort-Spezifika, die für mobile Apps relevant sind, die EU-Nutzerdaten erfassen, enthält die Compliance-Übersicht den DPA und die Unterauftragnehmer-Liste, die Ihr Datenschutzteam anfordern wird.

Weitere Blog-Beiträge

• Deep Links ohne SDK: wie Universal Links und App Links wirklich funktionieren
• EU-Datenspeicherort für Marketing-Tools: was Ihr DPO tatsächlich fragt
• Smart Links erklärt: Geräte-, Geo-, Tageszeit- und Referrer-Routing
• Von Bitly migrieren ohne Links zu brechen: ein Failure-Modes-Playbook