Міграція з Firebase Dynamic Links на Elido

Firebase Dynamic Links відключений з 2025-08-25. Кожне FDL-посилання тепер повертає 404. Якщо ваш застосунок використовував їх для атрибуції встановлень, відкладеного deep linking або пост-інсталяційної маршрутизації до конкретного екрана - ці потоки зараз зламані в production. Branch.io коштує від $199/місяць за рівень, що замінює те, що FDL робив безкоштовно. Deep-link маршрутизація Elido покриває ті самі патерни за значно меншу ціну, з вбудованим зберіганням даних в ЄС.

Це найкоротший шлях від зламаних FDL-посилань до працюючих Universal Links і Android App Links.

Коротко про головне

• Firebase Dynamic Links відключений 25 серпня 2025 року; всі URL *.page.link повертають HTTP 404 з тієї дати, згідно з FAQ щодо застарівання Firebase Dynamic Links
• Атрибуція встановлень вашого застосунку, пост-інсталяційна маршрутизація та відкладені deep links зламані, якщо ви ще не мігрували
• Міграція - це зміна DNS, два JSON-файли (один Apple, один Google) та переписування посилань, а не переписування коду
• Стартовий рівень Branch.io для цього сценарію коштує $199/місяць; Elido Pro покриває ту саму маршрутизацію за значно нижчою ціною без поклікової тарифікації
• Вам не потрібно чіпати наявний код обробки deep links на Swift або Kotlin - передача Universal Link / App Link на рівні ОС працює однаково незалежно від того, який сервіс хостить маршрутизацію

Що насправді робив Firebase Dynamic Links

FDL був відповіддю Google на три проблеми, які прості HTTPS-посилання не можуть вирішити самостійно.

Відкладений deep linking. Користувач на пристрої без вашого застосунку натискає посилання. ОС відкриває App Store або Play Store. Користувач встановлює застосунок. Застосунок відкривається на загальному головному екрані і не знає, що користувач намагався потрапити до конкретного контенту. FDL зберігав намічене призначення і передавав його через прогалину встановлення - застосунок міг запитати SDK FDL при першому запуску і направити користувача на потрібний екран.

Атрибуція встановлень. FDL-посилання несли параметри кампанії (utm_source, utm_medium, кастомні параметри через ?st= і ?si=), що виживали після встановлення. Це механізм, який дозволяв атрибутувати встановлення конкретній email-кампанії, платному соціальному креативу або посиланню інфлюенсера без стороннього MMP.

Маршрутизація з урахуванням платформи. Одне посилання - три призначення: користувачі iOS потрапляли в App Store (або глибоко в застосунок, якщо встановлений), користувачі Android - в Play Store (або в застосунок), а десктопні браузери отримували настроюваний фолбек URL. Маршрутизація відбувалася на серверній стороні на edge Google, а не в коді вашого застосунку.

Коли FDL впав - всі три можливості одночасно почали повертати 404. Якщо ви використовували FDL SDK у своєму застосунку - він викликає ендпоінт, якого більше не існує.

Еквівалент в Elido

Elido відтворює ті самі три поведінки через визначення платформи на redirect edge і стандартні механізми deep link на рівні ОС.

Визначення платформи на edge. Коротке посилання Elido перевіряє заголовок User-Agent у момент редиректу і маршрутизує до різних призначень залежно від платформи: iOS → URL App Store (або universal link застосунку), Android → URL Play Store (або intent застосунку), десктоп → ваш веб-фолбек. Це відбувається менш ніж за 5мс на рівні редиректу. Без виклику SDK, без зворотного зв'язку з окремим сервісом атрибуції.

iOS Universal Links. Коли ваш застосунок встановлений на пристрої, iOS перехоплює HTTPS-посилання до того, як браузер відкриється. Для цього потрібно обслуговувати файл Apple App Site Association (apple-app-site-association) за відомим шляхом вашого кастомного домену. Elido хостить цей файл від вашого імені, коли ви налаштовуєте кастомний домен із увімкненою deep-link маршрутизацією. Результат ідентичний тому, що давав FDL: застосунок відкривається безпосередньо на пов'язаному екрані.

Android App Links. Той самий механізм на Android, інший формат файлу. Файл assetlinks.json Google знаходиться за адресою /.well-known/assetlinks.json на вашому домені. Elido генерує і обслуговує цей файл, коли ви вказуєте назву пакету вашого застосунку та відбиток сертифіката SHA-256. Android App Links відкривають ваш застосунок безпосередньо без проміжного браузера.

Передача відкладеного deep link. Для випадку прогалини встановлення (користувач ще не має застосунку), Elido зберігає намічену ціль deep link за коротким URL і надає її через легкий ендпоінт запиту. Ваш застосунок викликає цей ендпоінт при першому запуску з коротким URL, з якого відбулося встановлення - який можна відновити з install referrer на Android (INSTALL_REFERRER) і API атрибуції App Store на iOS - і отримує оригінальний шлях deep link. Без FDL SDK, без пропрієтарного хендшейку. Посібник з deep links описує контракт ендпоінта запиту.

Повна сторінка функцій знаходиться за адресою /features/deep-links.

Покрокова міграція

Передбачається, що у вас є акаунт Elido на плані Pro або вище та кастомний домен, яким ви керуєте. Виділіть 30 хвилин для стандартної міграції; додайте буфер, якщо ваш обсяг FDL-посилань достатньо великий, щоб вимагати скрипту масового переписування.

Крок 1: Додайте кастомний домен до Elido

В дашборді Elido перейдіть до Workspace → Custom domains → Add domain. Введіть ваш брендований домен (наприклад, links.yourapp.com). Elido покаже вам CNAME-запис для створення.

У вашого DNS-реєстратора додайте CNAME:

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

Рекомендація щодо TTL: знизьте його до 300 секунд за кілька годин до цього, якщо зараз воно 3600+. Провізія TLS автоматична через автоматичний TLS на вимогу і завершується протягом кількох хвилин після поширення DNS.

Крок 2: Налаштуйте iOS Universal Links (файл AASA)

У налаштуваннях домену увімкніть Deep link routing і вкажіть:

• Ваш iOS bundle identifier (наприклад, com.yourcompany.yourapp)
• Патерни URL-шляхів, які мають відкривати застосунок (наприклад, /l/* для всіх коротких посилань або конкретні шляхи)

Elido генерує і обслуговує файл AASA за адресою https://links.yourapp.com/.well-known/apple-app-site-association. Перевірте, що він розв'язується коректно, перш ніж рухатися далі:

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

Відповідь повинна містити ваш bundle ID в масиві applinks.details. iOS CDN кешує файл AASA і оновлює його за розкладом; примусово оновіть кеш при тестуванні, скинувши кеш AASA пристрою через Developer → Reset в налаштуваннях iOS, або встановивши застосунок заново.

Ваш Info.plist застосунку повинен оголошувати associated domain. Якщо він вже робить це для вашого FDL-домену - додайте новий домен поруч у перехідний період:

<key>com.apple.developer.associated-domains</key>
<array>
  <string>applinks:links.yourapp.com</string>
  <!-- keep FDL domain during overlap if needed -->
</array>

Крок 3: Налаштуйте Android App Links (assetlinks.json)

В тій самій панелі налаштувань deep link вкажіть:

• Назву пакету вашого застосунку (наприклад, com.yourcompany.yourapp)
• Відбиток SHA-256 вашого сертифіката підпису для релізу

Отримайте відбиток, якщо у вас його немає в кеші:

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

Elido генерує і обслуговує файл за адресою https://links.yourapp.com/.well-known/assetlinks.json. Перевірте:

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

Ваш фільтр intent у AndroidManifest.xml вже має бути налаштований для App Links, якщо ви використовували FDL з функцією auto-verify Android SDK. Якщо ні - додайте атрибут android:autoVerify="true" до вашого фільтра intent для deep links і вкажіть новий домен.

Крок 4: Перепишіть існуючі FDL-посилання

FDL-посилання мають вигляд https://yourapp.page.link/SLUG або https://yourapp.page.link/?link=https%3A%2F%2F...&.... Жоден з цих патернів не буде працювати - домен page.link мертвий.

Якщо ви створили невелику кількість FDL-посилань (менше кількох сотень) - перепишіть їх вручну в дашборді Elido. Якщо ви створили тисячі - що поширено для email-кампаній або друкованих тиражів QR-кодів - скористайтеся API масового імпорту 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"
        }
      }
    ]
  }'

Для посилань, вже надрукованих на фізичних матеріалах (упаковка, плакати, візитівки), змінити сам URL неможливо - але якщо надрукований URL був FDL-посиланням на кастомний домен, що вказував на домен яким ви керуєте, ви можете перенаправити CNAME цього домену на Elido, і надруковане посилання знову почне працювати з вашою новою конфігурацією маршрутизації.

Крок 5: Оновіть відкладений запит deep link при першому запуску застосунку

FDL-застосунки викликають FirebaseDynamicLinks.dynamicLinks().handleUniversalLink(url) або еквівалентний метод SDK при першому запуску. Видаліть це. Замініть на виклик ендпоінта відкладеного deep link Elido:

// iOS - on first launch after install
let installURL = "https://links.yourapp.com/welcome" // recovered from StoreKit attribution
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()

Android-еквівалент використовує Play Install Referrer API для відновлення короткого URL, потім викликає той самий ендпоінт. Посібник з deep links містить повні зразки коду для обох платформ.

Крок 6: Протестуйте наскрізно

Перед перемиканням протестуйте три сценарії:

1. Застосунок встановлений, посилання натиснуто на пристрої - натисніть коротке посилання в Safari/Chrome, переконайтеся, що застосунок відкривається безпосередньо на потрібному екрані без проміжного браузера.
2. Застосунок не встановлений, посилання натиснуто - натисніть посилання, переконайтеся, що воно перенаправляє на правильну сторінку App Store / Play Store.
3. Застосунок встановлено з магазину після натискання посилання - встановіть застосунок заново, переконайтеся, що при першому запуску він відкривається на потрібному екрані (шлях відкладеного deep link).

Тестуйте Universal Links на реальному пристрої. Симулятори iOS ненадійно виконують хендшейк AASA.

Крайні випадки

Параметри FDL, які ви зчитували в застосунку. Якщо ваш застосунок викликав DynamicLink.dynamicLink().url для зчитування параметрів з FDL-посилання після відкриття - ці параметри тепер зникли. Потрібно закодувати ту саму інформацію в URL призначення короткого посилання Elido як query-параметри і зчитувати їх з URL deep link, який iOS або Android передає вашому застосунку. Кодування параметрів те саме - ?screen=onboarding&ref=email_april - просто перенесене з пропрієтарного обгортача link= FDL в сам URL призначення.

Втрата атрибуції. Атрибуція FDL була самодостатньою: Google зберігав параметри кампанії і повертав їх SDK. Elido зберігає дані подій кліків (часова мітка, платформа, країна, реферер) у наше аналітичне сховище і надає їх через API аналітики, але він не є MMP (мобільним партнером з вимірювань). Якщо вам потрібна ймовірнісна або детерміністична атрибуція встановлень у масштабі - когортний аналіз, LTV за джерелом залучення, сшивання SKAdNetwork - вам потрібен або MMP (Adjust, AppsFlyer), або інструментування webhook кліків Elido у ваш власний аналітичний конвеєр. Для більшості інді-застосунків і команд на ранній стадії, що використовували FDL виключно для «направлення користувача на потрібний екран», аналітики Elido достатньо. Для платних команд залучення, що запускають мультиканальну атрибуцію, - дивіться наступний розділ.

Існуючі короткі URL page.link, вбудовані у бінарний файл вашого застосунку. Якщо ви хардкодили короткі URL FDL у коді застосунку (push-payload, що генеруються на стороні клієнта, реферальні посилання, що карбуються в застосунку) - ці рядки посилаються на мертвий домен. Вам потрібне примусове оновлення застосунку або серверний ендпоінт, що генерує новий короткий URL на вимогу. Перенаправити page.link неможливо - Google повністю закрив домен.

Довгі URL FDL із закодованими параметрами. FDL підтримував довгоформатні URL на зразок https://yourapp.page.link/?link=https%3A%2F%2F...&ibi=com.yourapp&ifl=...&afl=.... Ці параметри (ibi, ifl, afl, isi) є специфічними для FDL. Зіставте їх з полями маршрутизації Elido: ifl (iOS fallback) → routing.ios, afl (Android fallback) → routing.android, ibi (iOS bundle ID) вже налаштований на рівні домену в Elido. Параметр link стає вашим URL призначення.

Зберігання даних у ЄС. Якщо ваш застосунок працює в ЄС і ви обробляєте дані користувачів ЄС - події редиректу, включаючи IP-адреси та рядки User-Agent, є персональними даними за GDPR. FDL розміщувався на глобальній інфраструктурі Google з обробкою в США. Elido розміщується у регіоні ЄС за замовчуванням; події кліків ЄС залишаються в ЄС. Сторінка довіри та огляд відповідності охоплюють договірну специфіку.

Коли насправді потрібен Branch.io

Elido - правильний вибір для більшості застосунків, які використовували FDL для маршрутизації екранів та базової атрибуції встановлень. Він не є правильним вибором, якщо ви залежите від:

Ймовірнісна атрибуція для платного залучення. Branch інтегрується з рекламними мережами (Meta, Google, TikTok, Snap) через постбеки і може ймовірнісно атрибутувати встановлення, коли детермінований відбиток недоступний - наприклад, на iOS 14.5+ без згоди ATT. Elido не виконує ймовірнісну атрибуцію. Якщо ваша команда зростання запускає платне залучення і потребує reconciliation встановлень з рекламними витратами на рівні когорти - Branch або MMP (Adjust, AppsFlyer) є правильним інструментом для цієї конкретної проблеми.

Відбитки пристроїв і зіставлення на рівні SDK. SDK Branch збирає сигнали пристрою (роздільна здатність екрана, IP, мова, часовий пояс) для відбитку пристрою через прогалину встановлення без покладання на install referrer. Зіставлення лише за реферером погіршується в середовищах, де реферер вилучено - якщо ваш відсоток влучань відкладеного deep link повинен перевищувати ~80%, підхід на рівні SDK працює краще.

Глибока інтеграція з конкретними рекламними мережами. Branch має спеціальні інтеграції з CAPI Meta, відстеженням конверсій Google та API подій TikTok, що виходять за межі того, що покриває серверне пересилання конверсій Elido. Якщо ваш стек атрибуції тісно пов'язаний з однією з цих мереж - оцініть конкретну документацію з інтеграції Branch перед переходом.

Практичний тест: якщо ви використовували FDL переважно для маршрутизації користувачів до потрібного екрана після встановлення, і ваші потреби в атрибуції покриваються параметрами UTM у вашому аналітичному інструменті - Elido замінює FDL за нижчою ціною. Якщо ви запускаєте перформанс-маркетинг у масштабі і точність атрибуції впливає на бюджетні рішення - це реальна ціннісна пропозиція Branch, і $199/місяць купує реальну інфраструктуру для цього.

Питання і відповіді

У моєму застосунку FDL короткі посилання вбудовані в push-сповіщення - що станеться, коли користувачі натиснуть на них?

Посилання вказують на page.link, який повертає 404. Обробка посилань ОС передає 404 браузеру або обробнику universal link вашого застосунку, що призведе до помилки. Вам потрібно оновити ваш сервіс push-сповіщень, щоб натомість генерувати короткі посилання Elido. Якщо push-payload генерується на стороні сервера (правильний підхід) - це одна рядкова зміна виклику API Elido замість FDL API. Якщо payload генерується на стороні клієнта з хардкодованих шаблонів - потрібне оновлення застосунку.

Чи потрібно мені оновлювати застосунок для завершення міграції?

Для відкладеного запиту deep link (маршрутизація через прогалину встановлення) - так, потрібно замінити виклик FDL SDK на виклик ендпоінта Elido, що вимагає оновлення застосунку. Для Universal Links і Android App Links до вже встановленого застосунку оновлення не потрібне після налаштування DNS і файлів AASA/assetlinks.json - ОС запитує ці файли з сервера, а не з бінарного файлу застосунку. Єдиний виняток: якщо ваш Info.plist / AndroidManifest.xml ще не оголошує новий домен як associated domain - потрібне оновлення застосунку.

Що станеться з кліками на старі FDL-посилання після завершення міграції?

Якщо старе посилання було на домені page.link - нічого, цей домен мертвий і ці посилання не відновити. Якщо ви використовували кастомний домен для FDL (менш поширено, але підтримується) - перенаправте CNAME домену на Elido і налаштуйте еквівалентні правила маршрутизації; старі URL знову почнуть розв'язуватися.

Чи є в Elido SDK?

Elido не вимагає SDK для Universal Links або App Links - це нативні механізми ОС. Для ендпоінта відкладеного запиту deep link ви робите стандартний HTTPS-виклик; залежність від SDK не потрібна. Якщо хочете типізований клієнт - Go SDK Elido, TypeScript SDK і Python SDK обгортають API deep links, але iOS/Android SDK не існує і він вам не потрібен. Це зроблено навмисно - чим менше сторонніх SDK у production-застосунку, тим краще.

Скільки часу займає поширення AASA / assetlinks.json?

Після поширення DNS (від кількох хвилин до години залежно від TTL) файли AASA і assetlinks.json одразу доступні через edge Elido. iOS оновлює свою кешовану копію файлу AASA при встановленні застосунку і periodically після; затримка при тестуванні пов'язана з застарілістю кешу iOS, а не із затримкою обслуговування Elido. Для чистого тесту встановіть застосунок заново після поширення DNS.

---

Якщо ви розглядаєте ширший набір функцій deep linking - сторінка /features/deep-links охоплює матрицю підтримки платформ і глибину правил маршрутизації. Для специфіки зберігання даних в ЄС, що стосується мобільних застосунків, які збирають дані користувачів ЄС, - огляд відповідності має DPA і список субпроцесорів, які попросить ваша команда конфіденційності.

Пов'язані матеріали в блозі

• Deep links без SDK: як насправді працюють Universal Links і App Links
• Зберігання даних в ЄС для маркетингових інструментів: що ваш DPO насправді запитує
• Smart links: маршрутизація за пристроєм, гео, часом доби і реферером
• Міграція з Bitly без зламаних посилань: посібник з режимів відмови