Alternatywa dla Firebase Dynamic Links po wyłączeniu usługi

Jeśli w 2026 roku szukasz alternatywy dla Firebase Dynamic Links, zacznij od oddzielenia tego, czego naprawdę potrzebujesz, od tego, co stary produkt kiedyś pakował do jednego worka. Większość zespołów potrzebuje dziś trzech rzeczy: markowego linku HTTPS, pewnego routingu zależnego od urządzenia i sensownej ścieżki zapasowej dla desktopu oraz mobilnego webu. Znacznie mniej zespołów faktycznie potrzebuje pełnego odroczonego deep linkingu albo rozbudowanej atrybucji mobilnej. Ta różnica ma znaczenie, bo wpływa i na koszt migracji, i na wybór docelowej architektury linków.

Zgodnie z oficjalnym Firebase Dynamic Links FAQ, Firebase Dynamic Links zostało wyłączone 25 sierpnia 2025. Jeśli kampanie, QR kody, onboarding w aplikacji albo flow pobrania nadal były oparte o te linki, najbezpieczniejszy kierunek to odbudowanie warstwy linków na stabilnych prymitywach: własna domena, przekierowania HTTP, natywne pliki powiązań aplikacji i jawne fallbacki.

Jeśli taka wymiana dzieje się równolegle z migracją domeny albo redesignem serwisu, trzymaj pod ręką także checklistę przekierowań przy migracji strony. W praktyce migracje po Firebase wykładają się z tych samych powodów co zwykłe migracje stron: niepełna inwentaryzacja linków i mgliste zasady fallbacku.

Do czego zespoły faktycznie używały Firebase Dynamic Links

Gdy ktoś mówi, że potrzebuje zamiennika Firebase Dynamic Links, zwykle ma na myśli jeden z tych scenariuszy:

1. kierowanie użytkowników iPhone’a do App Store, a Androida do Google Play
2. kierowanie desktopu do landing page albo strony z kodem QR
3. zachowanie krótkiego, markowego URL-a zamiast długiego linku do sklepu z aplikacją
4. utrzymanie parametrów kampanii i trackingu
5. otwieranie zainstalowanej aplikacji, kiedy to możliwe

To nie są identyczne problemy.

Przykładowo:

• routing do sklepu i fallback urządzeń to głównie problem przekierowań HTTP
• otwieranie zainstalowanej aplikacji to w praktyce temat Android App Links i Apple Universal Links
• deferred deep linking po instalacji często wymaga dodatkowej logiki po stronie aplikacji albo osobnego zestawu narzędzi do atrybucji
• zachowanie parametrów kampanii jest problemem jakości przekierowania. Jeśli zależy Ci głównie na tym, wróć też do przekierowania domeny bez utraty ścieżki i UTM-ów

[!TIP] Najszybsza migracja zwykle nie polega na „odtworzeniu Firebase funkcja po funkcji”. Najszybsza migracja polega na zastąpieniu tylko tych zachowań, których naprawdę potrzebuje produkt i marketing.

Najprostsze drzewo decyzyjne

Potrzebujesz tylko smart routingu

Jeśli Twój cel to:

• iOS -> App Store
• Android -> Google Play
• desktop -> strona web albo landing z QR

to często wystarczy dobrze zrobiona warstwa przekierowań. To najprostszy scenariusz dla rozwiązania typu Device Targeting w UrlEdge.

Potrzebujesz otwierania zainstalowanej aplikacji

Jeśli chcesz:

• otwierać zainstalowaną aplikację na iOS,
• otwierać zainstalowaną aplikację na Androidzie,
• kierować użytkownika bez aplikacji do sklepu albo na stronę zapasową w przeglądarce,

to potrzebujesz jednocześnie:

1. warstwy routingu linków
2. poprawnie ustawionych natywnych app links

To oznacza wdrożenie odpowiednich plików AASA i assetlinks.json, a także upewnienie się, że aplikacja potrafi obsłużyć konkretne ścieżki.

Potrzebujesz deferred deep linkingu albo atrybucji

Jeśli growth team polega na:

• atrybucji instalacji,
• przekierowaniu użytkownika po instalacji do konkretnego ekranu,
• spinaniu kampanii z instalacją,

to nie zakładaj, że sama warstwa przekierowań wystarczy. W takim wypadku lepiej połączyć markową warstwę linków z zaufanym rozwiązaniem do app links albo atrybucji, którego zespół już używa.

Praktyczna architektura zastępcza

Dla wielu zespołów docelowy układ wygląda tak:

go.twojamarka.example/promo
  -> wykrycie urządzenia na edge
  -> iOS: App Store albo Universal Link
  -> Android: Google Play albo App Link
  -> Desktop: landing page, strona docs albo strona z kodem QR

Taki układ daje kilka przewag:

• domena należy do Ciebie
• ścieżka zapasowa jest jawna i testowalna
• marketingowe linki nie są związane z jednym dostawcą mobilnym
• później możesz dołożyć analitykę, reguły geo albo czasowe override’y

Dla zespołów, które potrzebują głównie routingu i fallbacku, takie podejście jest zwykle prostsze w utrzymaniu niż próba odbudowy monolitycznej platformy do deep linków.

Plan migracji krok po kroku

Krok 1: zinwentaryzuj wszystkie aktywne linki

Nie migruj w ciemno. Wyeksportuj aktywne URL-e z:

• kampanii płatnych
• lifecycle e-maili
• bio w social mediach
• kodów QR
• dokumentacji partnerów
• onboardingu aplikacji
• flow referral w aplikacji

Stwórz arkusz z co najmniej takimi kolumnami:

old_dynamic_link,owner,use_case,ios_destination,android_destination,desktop_destination,notes
https://xyz.page.link/sale,growth,app download,https://apps.apple.com/app/...,https://play.google.com/store/apps/...,https://twojamarka.example/sale,sezonowa kampania

Ten arkusz zapobiega klasycznej sytuacji, w której engineering migruje oczywiste linki, a dwa tygodnie później marketing odkrywa brakujące QR flow albo stare linki z e-maili.

Krok 2: grupuj linki według zachowania, a nie kanału

Przypisz każdy link do jednej z kategorii:

1. fallback tylko do sklepu
2. fallback tylko do webu
3. native app link z fallbackiem
4. specjalna logika kampanii, geo albo urządzeń

To od razu pokaże, gdzie wystarczy warstwa redirectów, a gdzie potrzebujesz też natywnej obsługi po stronie aplikacji.

Krok 3: przenieś smart linki na domenę, którą kontrolujesz

Migracja to dobry moment, żeby przestać zależeć od domen linkowych należących do produktu zewnętrznego. Własna domena daje:

• kontrolę nad SSL i DNS,
• długoterminową własność linków,
• lepszą spójność marki,
• mniejsze uzależnienie od jednego dostawcy.

Dla większości zespołów adres typu go.twojamarka.example albo links.twojamarka.example jest łatwiejszy do zarządzania niż mieszanie smart linków z główną domeną marketingową.

Krok 4: jawnie ustaw cele dla każdej platformy

Nie zostawiaj „fallbacku” jako abstrakcji. Zapisz go wprost.

Przykład:

• iPhone -> App Store
• Android -> Google Play
• desktop -> landing page z kodem QR
• tablet -> desktop web albo sklep z aplikacją, zależnie od produktu

Jeśli wiesz z góry, że zachowanie ma zależeć od platformy, użyj device-based routing, zamiast przepychać wszystko przez jeden ogólny redirect.

Krok 5: ustaw natywne app links tam, gdzie to naprawdę potrzebne

Jeśli zainstalowana aplikacja ma otwierać się bezpośrednio, trzeba dowieźć też warstwę natywną:

• skonfiguruj Android App Links
• skonfiguruj Apple Universal Links
• przetestuj dopasowanie ścieżek w aplikacji
• upewnij się, że app obsługuje zarówno świeżą instalację, jak i powracającego użytkownika

To jest fragment, który bardzo wiele zespołów niedoszacowuje. Warstwa redirectów może dobrze pokierować ruch, ale nie doda za Ciebie logiki obsługi linków w aplikacji.

Krok 6: testuj na prawdziwych urządzeniach i przeglądarkach

Minimum testowe powinno objąć:

• iPhone Safari
• iPhone in-app browsers
• Android Chrome
• Android in-app browsers
• desktop Chrome
• desktop Safari

Testuj również warianty:

• aplikacja zainstalowana
• aplikacja niezainstalowana
• parametry kampanii obecne
• QR skanowany ze strony desktopowej

Do samej ścieżki przekierowania przydaje się Redirect Checker, bo pokazuje rzeczywiste zachowanie zamiast zgadywania z poziomu dashboardu kampanii.

Najczęstsze błędy migracji po Firebase

Traktowanie wszystkich zachowań linku jako jednego wymagania

Przekierowanie do sklepu, otwieranie aplikacji i deferred deep linking to różne problemy. Jeśli wrzucisz je do jednego worka, albo przepłacisz, albo czegoś ważnego zabraknie.

Ignorowanie desktopu

Bardzo wiele projektów smart linków łamie się na desktopie, bo cały nacisk idzie na iOS i Androida. Tymczasem zapasowa ścieżka desktopowa też jest częścią doświadczenia produktu.

Gubienie parametrów kampanii

Jeśli stare linki niosły utm_ albo inne identyfikatory kampanii, zachowaj je świadomie. Nie zakładaj, że każdy nowy przepływ robi to automatycznie.

Odkładanie monitoringu do czasu po premierze

Migracja bez obserwowalności to zgadywanie. Już od startu powinieneś widzieć, jak działa ruch, które cele zawodzą i gdzie trzeba poprawić ścieżkę zapasową.

Gdzie UrlEdge pasuje najlepiej

UrlEdge jest najmocniejszy tam, gdzie potrzebujesz kontroli nad routingiem:

• markowe własne domeny,
• przekierowanie do App Store i Google Play,
• zapasową ścieżkę desktopową do webu,
• reguły zależne od urządzenia,
• reguły zależne od kraju,
• walidacja przekierowań,
• analityka po stronie edge.

Jeśli Twoje potrzeby dotyczą głównie sterowania ruchem i ścieżką zapasową, taka warstwa zwykle wystarczy. Jeśli kluczowe są deferred deep links i pełna atrybucja instalacji, potraktuj redirect layer jako jeden element większego zestawu narzędzi, a nie jedyne rozwiązanie.

FAQ

Czy Firebase Dynamic Links zostało naprawdę wyłączone?

Tak. Oficjalne Firebase Dynamic Links FAQ wskazuje datę zamknięcia na 25 sierpnia 2025.

Czy smart redirect to pełny zamiennik deferred deep linking?

Nie zawsze. Smart redirect dobrze rozwiązuje routing i ścieżkę zapasową, ale deferred deep linking po instalacji może wymagać dodatkowej logiki po stronie aplikacji albo osobnego rozwiązania do atrybucji.

Czy jedna domena może obsłużyć i web, i app fallback?

Tak. To jeden z najbardziej praktycznych modeli migracji. Jeden markowy URL może kierować ruch zależnie od urządzenia i utrzymywać spójny branding.

Co testować najpierw, jeśli czasu jest mało?

Najpierw sprawdź ruch z płatnych kampanii, QR, onboardingu aplikacji, lifecycle e-maili i linków z bio. To zwykle najbardziej kosztowne miejsca awarii.