Universal Links und App Links nach Firebase richtig aufsetzen

Wenn noch alte page.link-URLs in QR-Codes, Anzeigen, E-Mails, Download-Seiten oder Referral-Flows stecken, suchen Sie nicht nur "einen Firebase-Ersatz". Sie versuchen, öffentliche Links stabil zu halten, ohne App-Öffnung, Fallback oder Kampagnenmessung zu beschädigen.

Genau deshalb hilft es, die Aufgaben zu trennen, die Firebase Dynamic Links früher in einem Produkt gebündelt hat:

1. die gebrandete öffentliche URL
2. das Öffnen installierter Apps
3. das Fallback zu App Store, Google Play oder Web
4. die Erhaltung von Kampagnenparametern

Die offizielle Firebase Dynamic Links FAQ nennt den 25. August 2025 als Abschaltdatum. Wenn diese Links noch in Kampagnen oder Produktflows leben, sollten Sie heute keinen möglichst ähnlichen Klon suchen, sondern Ihre Link-Schicht sauber neu aufbauen.

Was Universal Links und App Links wirklich abdecken

Apple Universal Links

Apple Universal Links öffnen eine installierte iOS-App aus einem normalen HTTPS-Link, wenn:

• die Domain korrekt mit der App verknüpft ist
• die Capability sauber gesetzt ist
• die Domain eine gültige apple-app-site-association ausliefert
• die App den empfangenen Pfad versteht

Android App Links

Android App Links leisten das gleiche auf Android. Dafür brauchen Sie:

• eine verifizierte Domain
• eine korrekte Manifest-Konfiguration
• eine gültige assetlinks.json
• Pfad-Handling in der App selbst

Was beides nicht ersetzt

Universal Links und App Links lösen nicht automatisch:

• Desktop-Fallbacks
• Store-Ziele für Nutzer ohne installierte App
• gebrandete Kampagnen-URLs
• Device Routing
• das Beibehalten von UTM-Parametern
• temporäre Kampagnen-Overrides

Hier bleibt eine Redirect-Schicht nötig.

Die sinnvollste Architektur nach Firebase

Für viele Teams ist dieses Modell am besten wartbar:

go.ihre-marke.de/promo
  -> Device Detection am Edge
  -> iPhone mit App: Universal Link
  -> iPhone ohne App: App Store
  -> Android mit App: App Link
  -> Android ohne App: Google Play
  -> Desktop: Landingpage, Doku oder QR-Handoff-Seite

Das funktioniert gut, weil:

• die Domain unter Ihrer Kontrolle bleibt
• Fallbacks explizit definiert sind
• Marketing nur eine saubere URL teilen muss
• Mobile-, Produkt- und Growth-Teams denselben echten Flow testen

Der praktische Engpass: die Verifikationsdateien

In der Praxis scheitert es oft nicht am Konzept, sondern an diesen Dateien:

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

Wenn die Hauptseite auf Shopify, Webflow, Wix oder einem restriktiven CMS läuft, wird das Ausliefern auf Root- oder .well-known-Pfaden schnell umständlich.

An dieser Stelle ist UrlEdge praktisch. Mit Custom Response können Sie solche Dateien am Edge bereitstellen, ohne dafür ein separates Hosting- oder Deployment-Konstrukt aufzubauen.

Ein sinnvoller Migrationsablauf

1. Öffentliche Links vollständig inventarisieren

Sammeln Sie Links aus:

• Paid Campaigns
• QR-Codes
• Download-Buttons
• Lifecycle-E-Mails
• Support-Seiten
• Social-Bios
• Referral-Flows

2. App-Öffnung und Fallback getrennt definieren

Für jede wichtige URL beantworten Sie:

1. Soll eine installierte App direkt geöffnet werden?
2. Geht ein Nutzer ohne App in den Store oder auf eine Web-Seite?
3. Was passiert auf Desktop?
4. Müssen UTM-Parameter erhalten bleiben?

3. Die kanonische öffentliche Domain festlegen

Typische Varianten sind:

• go.ihre-marke.de
• app.ihre-marke.de
• links.ihre-marke.de

So machen Sie Ihre öffentliche Link-Ebene unabhängiger von Anbieter-Domains.

4. Die Association-Files sauber validieren

Arbeiten Sie gegen die offiziellen Quellen:

• Apple Universal Links
• Android App Links

Wenn dieser Teil nicht sauber sitzt, bleibt native App-Öffnung instabil, auch wenn der Redirect oberflächlich funktioniert.

5. Explizite Fallback-Regeln festlegen

Zum Beispiel:

• iOS mit App -> App
• iOS ohne App -> App Store
• Android mit App -> App
• Android ohne App -> Google Play
• Desktop -> Landingpage oder QR-Handoff

Nichts davon sollte implizit bleiben.

6. In realen Kontexten testen

Mindestens prüfen:

• iPhone Safari
• Android Chrome
• In-App-Browser aus Social-Apps
• Desktop
• QR-Scans vom Handy
• Links mit UTM-Parametern

Erst dort sehen Sie den Unterschied zwischen "der Link antwortet" und "der Nutzerfluss ist wirklich korrekt".

Häufige Fehler

Device Routing mit Universal Links/App Links verwechseln

Routing wählt das Ziel. Universal Links und App Links sorgen für die verlässliche native Öffnung auf Betriebssystemebene.

Desktop vernachlässigen

Ein schwaches Desktop-Fallback beschädigt schnell Support-Strecken, Doku, Sales Enablement und QR-Use-Cases.

UTM-Parameter verlieren

Wenn Ihre Links über E-Mail, QR, Paid Social oder Partner-Kampagnen kommen, müssen Parameter bewusst erhalten werden.

Zu viele Ebenen stapeln

Je mehr Shortener, Zwischen-Redirects und Übergangsseiten Sie hinzufügen, desto schwieriger wird die Fehlersuche.

Wo UrlEdge hineinpasst

UrlEdge ist stark, wenn Sie kombinieren wollen:

• gebrandete öffentliche URLs
• Device Routing
• Store- oder Web-Fallbacks
• UTM-Erhalt
• Klick-Analytics
• Auslieferung der Verifikationsdateien am Edge

Das ersetzt nicht automatisch einen kompletten Mobile-Attribution-Stack. Aber es gibt Ihnen Kontrolle über die sichtbarste Ebene zurück: die öffentliche URL und das Fallback-Verhalten.

Fazit

Nach Firebase Dynamic Links ist die beste Antwort selten "die nächste Black Box". Meist ist es eine klarere Architektur:

• gebrandete Domain
• Device Routing
• sauber verifizierte Universal Links und App Links
• explizite Fallbacks
• erhaltene Kampagnenparameter

Weniger Magie, mehr Kontrolle.