Jak wdrożyć Universal Links i App Links po Firebase

Jeśli masz jeszcze stare linki do aplikacji w QR-ach, kampaniach Meta, Messengerze, Instagramie, mailach albo referralach, to nie szukasz już tylko "alternatywy dla Firebase". Chcesz utrzymać publiczne linki, nie psując otwierania aplikacji, fallbacku i pomiaru kampanii.

Dlatego warto rozdzielić cztery rzeczy, które Firebase Dynamic Links łączył w jednym produkcie:

1. publiczny link markowy
2. otwieranie zainstalowanej aplikacji
3. fallback do App Store, Google Play albo webu
4. zachowanie parametrów kampanii

Z oficjalnego Firebase Dynamic Links FAQ wynika, że usługa została wyłączona 25 sierpnia 2025 roku. Jeżeli stare linki nadal żyją w kampaniach, QR-ach albo onboardingach, sensowniejsze jest zbudowanie czystszej warstwy linków niż szukanie najbliższego zamiennika 1:1.

Co robią Universal Links i App Links

Universal Links

Apple Universal Links pozwalają otworzyć zainstalowaną aplikację iOS z normalnego linku HTTPS, jeśli:

• domena jest poprawnie powiązana z aplikacją
• capability została ustawiona poprawnie
• domena serwuje prawidłowy apple-app-site-association
• ścieżka jest zgodna z tym, co appka umie obsłużyć

Android App Links

Android App Links robią to samo po stronie Androida. Potrzebujesz do tego:

• zweryfikowanej domeny
• poprawnego manifestu
• prawidłowego assetlinks.json
• obsługi ścieżek w samej aplikacji

Czego to nie załatwia

Same Universal Links i App Links nie rozwiązują:

• fallbacku dla desktopu
• fallbacku dla użytkowników bez aplikacji
• linku markowego do kampanii
• routingu według urządzenia
• zachowania UTM
• czasowych override’ów kampanii

Do tego nadal potrzebujesz warstwy redirectów.

Najprostsza architektura po Firebase

Dla większości zespołów najzdrowszy układ wygląda tak:

go.twojamarka.com/promo
  -> wykrycie urządzenia na edge
  -> iPhone z aplikacją: Universal Link
  -> iPhone bez aplikacji: App Store
  -> Android z aplikacją: App Link
  -> Android bez aplikacji: Google Play
  -> Desktop: landing page, docs albo strona z QR

To podejście ma kilka zalet:

• domena zostaje pod twoją kontrolą
• fallback jest jawny
• marketing udostępnia jeden czysty link
• mobile i growth testują ten sam realny przepływ

Gdzie zespoły najczęściej się blokują

W praktyce problemem bywają pliki weryfikacyjne:

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

Zwłaszcza gdy główna strona stoi na Shopify, Wix, Webflow albo CMS-ie z ograniczonym dostępem do root path i .well-known.

Tutaj UrlEdge jest praktyczne. Dzięki custom response możesz serwować te pliki z edge, bez dokładania osobnego projektu tylko po to, żeby wystawić dwa pliki tekstowe.

Plan wdrożenia

1. Zrób inwentaryzację wszystkich publicznych linków

Sprawdź:

• kampanie płatne
• QR kody
• przyciski pobrania aplikacji
• maile lifecycle
• strony wsparcia
• linki z bio i social
• referral flows

2. Rozdziel otwieranie aplikacji i fallback

Dla każdego ważnego linku odpowiedz:

1. czy po zainstalowaniu aplikacji ma się ona otworzyć?
2. jeśli nie jest zainstalowana, czy użytkownik trafia do sklepu czy na web?
3. co widzi desktop?
4. czy UTM-y mają zostać zachowane?

3. Wybierz kanoniczną domenę publiczną

Najczęściej będzie to coś w stylu:

• go.twojamarka.com
• app.twojamarka.com
• links.twojamarka.com

Dzięki temu nie uzależniasz publicznej warstwy linków od domeny dostawcy zewnętrznego.

4. Zweryfikuj pliki powiązań

Opieraj się na oficjalnych źródłach:

• Apple Universal Links
• Android App Links

Jeśli ten etap jest źle ustawiony, natywne otwieranie będzie niestabilne, nawet jeśli redirect "ogólnie działa".

5. Zdefiniuj jawne fallbacki

Na przykład:

• iOS z appką -> appka
• iOS bez appki -> App Store
• Android z appką -> appka
• Android bez appki -> Google Play
• desktop -> landing page albo QR handoff

Nie zostawiaj tego na domysły.

6. Testuj w prawdziwych kontekstach

Sprawdź przynajmniej:

• iPhone Safari
• Android Chrome
• przeglądarki in-app z kampanii społecznościowych
• desktop
• QR otwierany z telefonu
• linki z UTM-ami

To właśnie tam widać różnicę między "link odpowiada" a "całe doświadczenie jest poprawne".

Najczęstsze błędy

Mylenie device routingu z Universal Links i App Links

Routing wybiera cel. Universal Links i App Links rozwiązują zaufane, natywne otwieranie na poziomie systemu.

Zapominanie o desktopie

Słaby fallback desktop psuje szybko support, dokumentację, materiały sprzedażowe i przepływy z QR.

Gubienie UTM-ów

Jeśli linki żyją w Messengerze, Instagramie, mailach, QR-ach albo paid social, parametry kampanii trzeba zachować świadomie.

Dokładanie zbyt wielu warstw

Im więcej shortenerów, pośrednich redirectów i stron przejściowych, tym trudniej później debugować cały przepływ.

Gdzie wchodzi UrlEdge

UrlEdge ma sens, gdy chcesz połączyć:

• markowy link publiczny
• routing według urządzenia
• fallback do sklepu lub webu
• zachowanie UTM
• analytics kliknięć
• publikację plików weryfikacyjnych na edge

To nie zastępuje automatycznie pełnego mobile attribution. Ale przywraca kontrolę nad najbardziej widoczną warstwą: publicznym linkiem i logiką fallbacku.

Podsumowanie

Po Firebase Dynamic Links najlepszą odpowiedzią rzadko bywa "kolejna czarna skrzynka". Częściej jest nią prostszy układ:

• domena markowa
• routing według urządzenia
• dobrze zweryfikowane Universal Links i App Links
• jawny fallback
• zachowane parametry kampanii

Mniej magii, więcej kontroli.