Universal Links en App Links instellen na Firebase

Als je nog oude app-links hebt in QR-codes, e-mails, social campagnes, downloadknoppen of referral flows, dan zoek je niet alleen "een alternatief voor Firebase". Je probeert publieke links overeind te houden zonder app-opening, fallback of campagnemeting stuk te maken.

Daarom helpt het om het oude Firebase-pakket op te delen in vier losse taken:

1. de branded publieke URL
2. het openen van een geïnstalleerde app
3. fallback naar App Store, Google Play of web
4. het behouden van campagneparameters

Volgens de officiële Firebase Dynamic Links FAQ stopte de dienst op 25 augustus 2025. Als oude links nog in campagnes of onboarding zitten, is dit het moment om een schonere linklaag te bouwen in plaats van een bijna-kopie te zoeken.

Wat Universal Links en App Links wel en niet doen

Universal Links

Apple Universal Links openen een geïnstalleerde iOS-app via een gewone HTTPS-link als:

• het domein aan de app is gekoppeld
• de capability correct is ingesteld
• het domein een geldige apple-app-site-association serveert
• het pad overeenkomt met wat de app kan afhandelen

Android App Links

Android App Links doen hetzelfde op Android. Daarvoor heb je nodig:

• een geverifieerd domein
• correcte manifest-configuratie
• een geldige assetlinks.json
• route-handling in de app zelf

Wat je daarnaast nog nodig hebt

Geen van beide regelt automatisch:

• een desktop fallback
• fallback voor gebruikers zonder app
• de branded link die marketing deelt
• device-routing
• UTM-behoud
• tijdelijke campaign overrides

Daarvoor blijft een redirectlaag nodig.

De meest onderhoudbare opzet

Voor de meeste teams ziet een werkbare stack er zo uit:

go.jemerk.com/promo
  -> device detectie aan de edge
  -> iPhone met app: Universal Link
  -> iPhone zonder app: App Store
  -> Android met app: App Link
  -> Android zonder app: Google Play
  -> Desktop: landingpage, docs of QR-pagina

Dat model werkt goed omdat:

• je domein van jou blijft
• fallback expliciet wordt
• marketing één nette URL kan delen
• mobile en growth hetzelfde echte pad testen

Waar teams vaak vastlopen

In de praktijk gaat het vaak mis bij de verificatiebestanden:

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

Zeker als de hoofdsite op Shopify, Webflow, Wix of een beperkt CMS draait, zijn root-bestanden of .well-known niet altijd prettig te beheren.

Dat is precies een plek waar UrlEdge helpt. Met custom response kun je deze bestanden vanaf de edge serveren zonder er een apart infra-traject van te maken.

Praktisch migratieplan

1. Maak een inventaris van alle publieke links

Controleer:

• paid campaigns
• QR-codes
• downloadknoppen
• lifecycle e-mails
• supportpagina’s
• social bios
• referral flows

2. Scheid app-opening en fallback

Beantwoord per belangrijke link:

1. moet de app openen als die geïnstalleerd is?
2. zo niet, gaat de gebruiker naar de store of naar web?
3. wat ziet desktop?
4. moeten UTM’s behouden blijven?

3. Kies je canonieke publieke domein

Bijvoorbeeld:

• go.jemerk.com
• app.jemerk.com
• links.jemerk.com

Zo maak je je minder afhankelijk van een third-party hostname.

4. Valideer de associatiebestanden

Gebruik altijd de officiële documentatie:

• Apple Universal Links
• Android App Links

Als dit deel fout zit, blijft native app-opening onbetrouwbaar, ook als de redirect zelf lijkt te werken.

5. Leg fallbackregels expliciet vast

Bijvoorbeeld:

• iOS met app -> app
• iOS zonder app -> App Store
• Android met app -> app
• Android zonder app -> Google Play
• desktop -> landing of QR handoff

Laat dit niet impliciet.

6. Test in echte context

Controleer minimaal:

• iPhone Safari
• Android Chrome
• in-app browsers van social apps
• desktop
• QR vanaf mobiel
• links met UTM’s

Daar merk je het verschil tussen "de link geeft een response" en "de hele ervaring klopt".

Veelgemaakte fouten

Denken dat device-routing Universal Links of App Links vervangt

Nee. Device-routing kiest de bestemming. Universal Links en App Links regelen betrouwbare native opening op OS-niveau.

Desktop vergeten

Een zwakke desktop fallback breekt al snel supportflows, docs, salesmateriaal en QR-trajecten.

UTM’s verliezen

Als links uit e-mail, LinkedIn, WhatsApp, QR of paid social komen, moeten parameters bewust behouden blijven.

Te veel lagen stapelen

Hoe meer shorteners, tussenredirects en tussenpagina’s je toevoegt, hoe trager troubleshooting wordt.

Waar UrlEdge waarde toevoegt

UrlEdge is sterk als je één laag nodig hebt voor:

• branded publieke links
• device-routing
• store- of webfallback
• UTM-behoud
• click analytics
• publicatie van verificatiebestanden aan de edge

Dat vervangt niet automatisch alle advanced mobile attribution. Maar het geeft wel controle terug over het publieke linkoppervlak en de fallbacklogica.

Samengevat

Na Firebase Dynamic Links is de beste oplossing meestal niet "een nieuwe black box". Vaker is het een helderdere stack:

• branded domein
• device-routing
• goed geverifieerde Universal Links en App Links
• expliciete fallbacks
• behouden campagneparameters

Minder magie, meer grip.