Migracja z Firebase Dynamic Links do Elido

Firebase Dynamic Links zostały wyłączone 2025-08-25. Każdy link FDL zwraca teraz 404. Jeśli Twoja aplikacja używała ich do atrybucji instalacji, deferred deep linkowania lub routingu po instalacji do konkretnego ekranu, te przepływy są teraz zepsute w produkcji. Branch.io zaczyna od 199 USD miesięcznie za poziom, który zastępuje to, co FDL robiło za darmo. Routing deep linków Elido obsługuje te same wzorce za ułamek kosztów z wbudowaną rezydencją danych w UE.

To jest najkrótsza ścieżka od zepsutych linków FDL do działających Universal Links i Android App Links.

TL;DR

• Firebase Dynamic Links zostały wyłączone 25 sierpnia 2025; wszystkie URL-e *.page.link zwracają HTTP 404 od tej daty, zgodnie z FAQ dotyczącym wycofania Firebase Dynamic Links
• Atrybucja instalacji Twojej aplikacji, routing po instalacji i deferred deep linki są zepsute, jeśli jeszcze nie przeprowadziłeś migracji
• Migracja to zmiana DNS, dwa pliki JSON (jeden dla Apple, jeden dla Google) i przepisanie linków - nie przepisywanie kodu
• Wejściowy poziom Branch.io dla tego przypadku użycia to 199 USD miesięcznie; Elido Pro obsługuje ten sam routing za znacznie niższy koszt bez naliczania per link
• Nie musisz dotykać istniejącego kodu obsługi deep linków w Swift lub Kotlin - handoff Universal Link / App Link na poziomie systemu operacyjnego działa tak samo, niezależnie od tego, który serwis hostuje routing

Co tak naprawdę robiło Firebase Dynamic Links

FDL było odpowiedzią Google na trzy problemy, których zwykłe linki HTTPS nie mogą rozwiązać samodzielnie.

Deferred deep linkowanie. Użytkownik na urządzeniu bez Twojej aplikacji klika link. System operacyjny otwiera App Store lub Play Store. Użytkownik instaluje aplikację. Aplikacja otwiera się na ogólnym ekranie głównym i nie ma pojęcia, że użytkownik próbował dotrzeć do konkretnej treści. FDL przechowywało zamierzone miejsce docelowe i przekazywało je przez lukę instalacyjną - aplikacja mogła zapytać SDK FDL przy pierwszym uruchomieniu i przekierować użytkownika na właściwy ekran.

Atrybucja instalacji. Linki FDL nosiły parametry kampanii (utm_source, utm_medium, niestandardowe parametry przez ?st= i ?si=), które przetrwały instalację. To jest mechanizm, który pozwalał przypisać instalację do konkretnej kampanii emailowej, kreacji w płatnych mediach społecznościowych lub linku influencera bez zewnętrznego MMP.

Routing uwzględniający platformę. Jeden link, trzy miejsca docelowe: użytkownicy iOS trafiali do App Store (lub głęboko w aplikację, jeśli była zainstalowana), użytkownicy Android do Play Store (lub aplikacji), a przeglądarki desktopowe otrzymywały konfigurowalny URL zastępczy. Routing odbywał się po stronie serwera na edge Google, nie w kodzie aplikacji.

Gdy FDL przestało działać, wszystkie trzy możliwości przeszły do 404 jednocześnie. Jeśli używałeś SDK FDL w swojej aplikacji, wywołuje ona endpoint, który już nie istnieje.

Odpowiednik w Elido

Elido replikuje te same trzy zachowania przez wykrywanie platformy na edge przekierowania i standardowe mechanizmy deep linków systemu operacyjnego.

Wykrywanie platformy na edge. Krótki link Elido sprawdza nagłówek User-Agent w momencie przekierowania i kieruje do różnych miejsc docelowych w zależności od platformy: iOS na URL App Store (lub universal link aplikacji), Android na URL Play Store (lub intent aplikacji), desktop na Twój web fallback. Dzieje się to w mniej niż 5ms na poziomie przekierowania. Bez wywołania SDK, bez round-tripu do oddzielnego serwisu atrybucji.

iOS Universal Links. Gdy Twoja aplikacja jest zainstalowana na urządzeniu, iOS przechwytuje link HTTPS przed otwarciem przeglądarki. Wymaga to serwowania pliku Apple App Site Association (apple-app-site-association) ze ścieżki well-known Twojej własnej domeny. Elido hostuje ten plik w Twoim imieniu, gdy konfigurujesz własną domenę z włączonym routingiem deep linków. Wynik jest identyczny z tym, co dostarczało FDL: aplikacja otwiera się bezpośrednio na połączonym ekranie.

Android App Links. Ten sam mechanizm na Androidzie, inny format pliku. Plik assetlinks.json Google'a znajduje się pod /.well-known/assetlinks.json na Twojej domenie. Elido generuje i serwuje ten plik, gdy podasz nazwę pakietu swojej aplikacji i odcisk SHA-256 certyfikatu podpisywania. Android App Links otwierają Twoją aplikację bezpośrednio bez interstitial przeglądarki.

Przepuszczenie deferred deep linku. W przypadku instalacji (użytkownik nie ma jeszcze aplikacji), Elido przechowuje zamierzony cel deep linku pod krótkim URL i udostępnia go przez lekki endpoint zapytania. Twoja aplikacja wywołuje ten endpoint przy pierwszym uruchomieniu ze skróconym URL, z którego aplikacja była zainstalowana - odzyskiwalnym z install referrera na Androidzie (INSTALL_REFERRER) i API atrybucji App Store na iOS - i otrzymuje z powrotem oryginalną ścieżkę deep linku. Bez SDK FDL, bez własnego handshake. Przewodnik po deep linkach opisuje kontrakt endpointu zapytania.

Pełna strona funkcji jest pod adresem /features/deep-links.

Migracja krok po kroku

Zakłada to, że masz konto Elido na planie Pro lub wyższym oraz własną domenę, którą kontrolujesz. Zaplanuj 30 minut na prostą migrację; dodaj bufor, jeśli wolumen linków FDL jest wystarczająco duży, aby wymagał skryptu do masowego przepisywania.

Krok 1: Dodaj własną domenę do Elido

W dashboardzie Elido przejdź do Workspace - Własne domeny - Dodaj domenę. Wpisz zamierzoną domenę z marką (np. links.yourapp.com). Elido wyświetli rekord CNAME do utworzenia.

W swoim rejestratorze DNS dodaj CNAME:

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

Zalecenie dotyczące TTL: obniż go do 300 sekund na kilka godzin przed tym, jeśli aktualnie wynosi 3600+. Provisionowanie TLS jest automatyczne przez TLS na żądanie i kończy się w ciągu kilku minut od propagacji DNS.

Krok 2: Skonfiguruj iOS Universal Links (plik AASA)

W ustawieniach domeny włącz Routing deep linków i podaj:

• Identyfikator bundle iOS (np. com.yourcompany.yourapp)
• Wzorce ścieżek URL, które powinny otwierać aplikację (np. /l/* dla wszystkich krótkich linków lub konkretne ścieżki)

Elido generuje i serwuje plik AASA pod adresem https://links.yourapp.com/.well-known/apple-app-site-association. Zweryfikuj, że rozwiązuje poprawnie przed przejściem dalej:

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

Odpowiedź powinna zawierać Twój bundle ID w tablicy applinks.details. CDN iOS buforuje plik AASA i odświeża go zgodnie z harmonogramem; wymuś odświeżenie podczas testowania, resetując pamięć podręczną AASA urządzenia przez Developer - Reset w ustawieniach iOS lub instalując aplikację od nowa.

Twój Info.plist aplikacji musi deklarować powiązaną domenę. Jeśli deklaruje już domenę FDL, dodaj nową domenę obok niej w okresie nakładania się:

<key>com.apple.developer.associated-domains</key>
<array>
  <string>applinks:links.yourapp.com</string>
  <!-- zachowaj domenę FDL w okresie nakładania się, jeśli potrzebne -->
</array>

Krok 3: Skonfiguruj Android App Links (assetlinks.json)

W tym samym panelu ustawień deep linków podaj:

• Nazwę pakietu Twojej aplikacji (np. com.yourcompany.yourapp)
• Odcisk SHA-256 certyfikatu podpisywania wersji produkcyjnej

Pobierz odcisk, jeśli nie masz go w pamięci podręcznej:

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

Elido generuje i serwuje plik pod adresem https://links.yourapp.com/.well-known/assetlinks.json. Zweryfikuj:

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

Filtr intencji w Twoim AndroidManifest.xml powinien być już skonfigurowany dla App Links, jeśli używałeś FDL z funkcją auto-verify SDK Android. Jeśli nie, dodaj atrybut android:autoVerify="true" do filtra intencji deep linków i wskaż go na nową domenę.

Krok 4: Przepisz istniejące linki FDL

Linki FDL mają format https://yourapp.page.link/SLUG lub https://yourapp.page.link/?link=https%3A%2F%2F...&.... Żaden z tych wzorców nie będzie dalej działał - domena page.link nie działa.

Jeśli wygenerowałeś niewielką liczbę linków FDL (poniżej kilkuset), przepisz je ręcznie w dashboardzie Elido. Jeśli wygenerowałeś tysiące - co jest powszechne w kampaniach emailowych lub drukach kodów QR - użyj API masowego importu Elido:

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

W przypadku linków już wydrukowanych na materiałach fizycznych (opakowania, plakaty, wizytówki), nie możesz zaktualizować samego URL - ale jeśli wydrukowany URL był linkiem FDL z własną domeną wskazującą na domenę, którą kontrolujesz, możesz przekierować CNAME tej domeny na Elido i wydrukowany link zacznie ponownie działać z nową konfiguracją routingu.

Krok 5: Zaktualizuj zapytanie deferred deep link przy pierwszym uruchomieniu aplikacji

Aplikacje FDL wywołują FirebaseDynamicLinks.dynamicLinks().handleUniversalLink(url) lub równoważną metodę SDK przy pierwszym uruchomieniu. Usuń to. Zastąp wywołaniem do endpointu deferred deep link Elido:

// iOS - przy pierwszym uruchomieniu po instalacji
let installURL = "https://links.yourapp.com/welcome" // odzyskane z atrybucji StoreKit
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()

Odpowiednik na Androidzie używa Play Install Referrer API do odzyskania krótkiego URL, a następnie wywołuje ten sam endpoint. Przewodnik po deep linkach zawiera pełne przykłady kodu dla obu platform.

Krok 6: Przetestuj end-to-end

Przed przełączeniem przetestuj trzy przypadki:

1. Aplikacja zainstalowana, link kliknięty na urządzeniu - kliknij krótki link w Safari/Chrome, potwierdź, że aplikacja otwiera się bezpośrednio na właściwym ekranie bez interstitial przeglądarki.
2. Aplikacja nie zainstalowana, link kliknięty - kliknij link, potwierdź, że kieruje na właściwą stronę App Store / Play Store.
3. Aplikacja zainstalowana ze sklepu po kliknięciu linku - zainstaluj aplikację od nowa, potwierdź, że otwiera się na zamierzonym ekranie przy pierwszym uruchomieniu (ścieżka deferred deep linku).

Testuj na fizycznym urządzeniu w przypadku Universal Links. Symulatory iOS nie wykonują niezawodnie handoff AASA.

Edge case'y

Parametry FDL odczytywane w aplikacji. Jeśli Twoja aplikacja wywoływała DynamicLink.dynamicLink().url do odczytu parametrów z linku FDL po otwarciu, te parametry są teraz utracone. Musisz zakodować te same informacje w URL docelowym krótkiego linku Elido jako parametry zapytania i odczytać je z URL deep linku dostarczanego przez iOS lub Android do Twojej aplikacji. Kodowanie parametrów jest takie samo - ?screen=onboarding&ref=email_april - po prostu przeniesione z własnego wrappera link= FDL do samego URL docelowego.

Utrata atrybucji. Atrybucja FDL była samodzielna: Google przechowywało parametry kampanii i zwracało je do SDK. Elido przechowuje dane zdarzeń kliknięć (timestamp, platforma, kraj, referrer) w naszym magazynie analitycznym i udostępnia je przez API analityczne, ale nie jest MMP (mobile measurement partner). Jeśli potrzebujesz probabilistycznej lub deterministycznej atrybucji instalacji na dużą skalę - analiza kohort, LTV według źródła akwizycji, łączenie SKAdNetwork - potrzebujesz albo MMP (Adjust, AppsFlyer) albo zinstrumentowania webhooka kliknięć Elido we własny pipeline analityczny. Dla większości aplikacji indie i wczesnych zespołów, które używały FDL czysto do "kierowania użytkownika na właściwy ekran", analityka Elido jest wystarczająca. Dla zespołów płatnej akwizycji prowadzących atrybucję wielokanałową, zobacz następną sekcję.

Istniejące krótkie URL page.link osadzone w binariach aplikacji. Jeśli zakodowałeś na stałe krótkie URL FDL w kodzie aplikacji (payloady powiadomień push generowane po stronie klienta, linki polecające generowane z aplikacji), te ciągi odwołują się do martwej domeny. Potrzebujesz wymuszonej aktualizacji aplikacji lub endpointu po stronie serwera, który generuje nowy krótki URL na żądanie. Nie ma możliwości przekierowania page.link - Google wyłączył tę domenę całkowicie.

Długie URL FDL z zakodowanymi parametrami. FDL obsługiwało długie URL, takie jak https://yourapp.page.link/?link=https%3A%2F%2F...&ibi=com.yourapp&ifl=...&afl=.... Te parametry (ibi, ifl, afl, isi) są specyficzne dla FDL. Zmapuj je na pola routingu Elido: ifl (iOS fallback) na routing.ios, afl (Android fallback) na routing.android, ibi (iOS bundle ID) jest już skonfigurowane na poziomie domeny w Elido. Parametr link staje się Twoim URL docelowym.

Rezydencja danych w UE. Jeśli Twoja aplikacja działa w UE i przetwarzasz dane użytkowników z UE, zdarzenia przekierowania - w tym adresy IP i ciągi User-Agent - są danymi osobowymi zgodnie z RODO. FDL była hostowana na globalnej infrastrukturze Google z przetwarzaniem w USA. Elido jest domyślnie hostowane we Frankfurcie; zdarzenia kliknięć z UE pozostają w UE. Strona zaufania i przegląd zgodności opisują szczegóły kontraktowe.

Kiedy naprawdę potrzebujesz Branch.io

Elido jest właściwym wyborem dla większości aplikacji, które używały FDL do routingu ekranów i podstawowej atrybucji instalacji. Nie jest właściwym wyborem, jeśli zależysz od:

Atrybucja probabilistyczna dla płatnego UA. Branch integruje się z sieciami reklamowymi (Meta, Google, TikTok, Snap) przez postbacki i może przypisywać instalacje probabilistycznie, gdy deterministyczny fingerprint nie jest dostępny - np. na iOS 14.5+ bez zgody ATT. Elido nie obsługuje atrybucji probabilistycznej. Jeśli Twój zespół wzrostu prowadzi płatne UA i potrzebuje pogodzenia instalacji z wydatkami reklamowymi na poziomie kohorty, Branch lub MMP (Adjust, AppsFlyer) jest właściwym narzędziem dla tego konkretnego problemu.

Fingerprinting na poziomie SDK i dopasowywanie urządzeń. SDK Branch zbiera sygnały urządzenia (rozdzielczość ekranu, IP, język, strefa czasowa) do fingerprintowania urządzenia przez lukę instalacyjną bez polegania na install referrerze. Dopasowywanie tylko przez referrera pogarsza się w środowiskach, gdzie referrer jest usuwany - jeśli wskaźnik trafień deferred deep linku musi przekraczać ~80%, podejście na poziomie SDK działa lepiej.

Głęboka integracja z konkretnymi sieciami reklamowymi. Branch ma dedykowane integracje z CAPI Meta, śledzeniem konwersji Google i API zdarzeń TikToka, które wykraczają poza to, co obejmuje przekazywanie konwersji po stronie serwera Elido. Jeśli Twój stos atrybucji jest ściśle powiązany z jedną z tych sieci, przed przełączeniem oceń konkretną dokumentację integracji Branch.

Praktyczny test: jeśli używałeś FDL głównie do kierowania użytkowników na właściwy ekran po instalacji, a Twoje potrzeby atrybucji są pokryte przez parametry UTM w narzędziu analitycznym, Elido zastępuje FDL za niższe koszty. Jeśli prowadzisz performance marketing na dużą skalę i dokładność atrybucji wpływa na decyzje budżetowe, to jest rzeczywista propozycja wartości Branch i 199 USD miesięcznie kupuje realną infrastrukturę.

FAQ

Moja aplikacja ma krótkie linki FDL w payloadach powiadomień push - co się stanie, gdy użytkownicy je klikną?

Linki wskazują na page.link, który zwraca 404. Obsługa linków przez system operacyjny przekazuje błąd 404 z powrotem do przeglądarki lub do handlera universal linków Twojej aplikacji, który zawiedzie. Musisz zaktualizować serwis powiadomień push, aby generował krótkie linki Elido. Jeśli generujesz payloady push po stronie serwera (właściwe podejście), to jest zmiana jednej linii - wywołanie API Elido zamiast API FDL. Jeśli payloady są generowane po stronie klienta z zakodowanych na stałe szablonów, wymagana jest aktualizacja aplikacji.

Czy muszę wydać aktualizację aplikacji, aby ukończyć migrację?

W przypadku zapytania o deferred deep link (routing przez lukę instalacyjną), tak - musisz zastąpić wywołanie SDK FDL wywołaniem endpointu Elido, co wymaga aktualizacji aplikacji. W przypadku Universal Links i Android App Links do już zainstalowanej aplikacji aktualizacja nie jest potrzebna po skonfigurowaniu DNS i plików AASA/assetlinks.json - system operacyjny pobiera te pliki z serwera, nie z binarki aplikacji. Wyjątek: jeśli Twój Info.plist / AndroidManifest.xml nie deklaruje jeszcze nowej domeny jako powiązanej domeny, to wymaga aktualizacji aplikacji.

Co stanie się z kliknięciami starych linków FDL po ukończeniu migracji?

Jeśli stary link był w domenie page.link: nic - ta domena nie działa i tych linków nie można odzyskać. Jeśli używałeś własnej domeny dla FDL (mniej powszechne, ale obsługiwane), przekieruj CNAME domeny na Elido i skonfiguruj równoważne reguły routingu; stare URL-e zaczną ponownie działać.

Czy Elido ma SDK?

Elido nie wymaga SDK dla Universal Links ani App Links - to są mechanizmy natywne systemu operacyjnego. W przypadku endpointu zapytania o deferred deep link wykonujesz standardowe wywołanie HTTPS; żadna zależność od SDK nie jest potrzebna. Jeśli chcesz klienta z typowaniem, Elido Go SDK, TypeScript SDK i Python SDK wszystkie owijają API deep linków, ale nie ma iOS/Android SDK i nie potrzebujesz go. To jest zamierzone - im mniej zewnętrznych SDK w produkcyjnej aplikacji, tym lepiej.

Jak długo trwa propagacja AASA / assetlinks.json?

Po propagacji DNS (od kilku minut do godziny w zależności od TTL), pliki AASA i assetlinks.json są natychmiast dostępne z edge Elido. iOS odświeża swoją pamięć podręczną pliku AASA przy instalacji aplikacji i okresowo po tym; opóźnienie zauważalne podczas testów wynika ze starzenia się pamięci podręcznej iOS, a nie z opóźnienia serwowania przez Elido. Dla czystego testu zainstaluj aplikację od nowa po propagacji zmiany DNS.

---

Jeśli chcesz zapoznać się z szerszym zestawem funkcji deep linkowania, strona /features/deep-links opisuje macierz obsługi platform i głębokość reguł routingu. Dla szczegółów rezydencji danych w UE istotnych dla aplikacji mobilnych zbierających dane użytkowników z UE, przegląd zgodności zawiera DPA i listę podprzetwarzających danych, o które poprosi Twój zespół ds. prywatności.

Powiązane na blogu

• Deep linki bez SDK: jak naprawdę działają Universal Links i App Links
• Rezydencja danych w UE dla narzędzi marketingowych: o co naprawdę pyta Twój DPO
• Smart linki wyjaśnione: routing urządzeń, geo, pory dnia i referrera
• Migracja z Bitly bez zrywania linków: poradnik na temat trybów awarii