Попрощайтесь с Firebase, прежде чем он сделает это первым: практическое руководство по миграции

Автор: Dubi Furie

Firebase Dynamic Links (FDL) долгое время было универсальным решением для диплинкинга в мобильных приложениях. Но после того, как Google объявил о прекращении его поддержки, многим разработчикам и продуктовым командам предстоит найти ему замену. Когда вы определитесь с новым решением, важно понять, как организовать переход с FDL.

В этом руководстве мы расскажем о сложностях, с которыми вы можете столкнуться в процессе миграции, объясним ключевые моменты и стратегические шаги, а также дадим практические рекомендации, чтобы переход был плавным.

Самое важное

Как заявили в Google, в связи с закрытием сервиса разработчикам приложений необходимо завершить миграцию с Firebase Dynamic Links до 25 августа 2025 года. Для этого нужно осуществить переход на альтернативные решения, такие как App Links, Universal Links или решения сторонних провайдеров диплинкинга. Существующие ссылки будут продолжать работать до момента закрытия, при этом создать новые ссылки будет уже невозможно. Разработчикам также необходимо экспортировать метаданные своих ссылок и рассмотреть возможность обновления своих приложений для обработки изменений, связанных с диплинкингом после закрытия сервиса. Экспорт метаданных ссылок крайне важен для миграции на выбранное вами альтернативное решение.

Планирование миграции

Прежде чем начинать реализацию, стоит начать с понимания конечной цели.

Первое и главное — быть готовыми до 25 августа 2025 года, когда сервис отключат. Поэтому важно разобраться с циклами релиза приложений и тенденциям в плане обновления версий приложений. Сколько времени требуется, чтобы все пользователи обновили ваше приложение?

Во-вторых, вам нужна чёткая картина вашей текущей настройки и того, что должно поддерживать ваше новое решение.

Оцените свою текущую ситуацию:
- Посмотрите, в каких пользовательских сценариях вы сейчас используете FDL? Например: онбординг новых пользователей, реферальные программы, промо-акции, платные кампании и т. д.
- Как генерируются ссылки? Вручную, с помощью маркетинговых инструментов, API для бэкенда, обмен контентом в приложении и т. д.
- Как измеряются результаты? Какой источник даёт клики, вовлечённость и конверсии?
Определитесь со своими требованиями – это критически важный шаг, который необходим, чтобы избежать сюрпризов со стоимостью, лимитами API или эффективностью при подборе альтернатив.
- Вот список возможных требований:

кроссплатформенный диплинкинг – iOS и Android в одной ссылке;
отложенный диплинкинг: поддержка перехода после установки приложения;
брендированные ссылки с собственным доменом;
измерение и аналитика на уровне кампании;
поддержка QR-кодов;
эффективность SDK и сложность интеграции;
примерный объём и масштаб;
ежедневная/ежемесячная генерация ссылок и необходимые для этого процессы (автоматизация или вручную).

Альтернативы Firebase

1) Нишевое решение

Сторонний поставщик, предлагающий расширенные функции — например, кроссплатформенную поддержку, брендированные ссылки и базовую аналитику.

2) Собственное решение (in-house)

Вы можете создать и поддерживать собственную систему диплинкинга. Это даёт полный контроль над настройкой, но потребует времени на реализацию и поддержку.

3) Сотрудничество с партнёром по мобильным измерениям

Такие платформы объединяют диплинкинг и атрибуцию, предоставляя централизованные инструменты для отслеживания и оптимизации пользовательской вовлечённости по всем маркетинговым каналам.

Сравнение альтернатив

Альтернатива	Плюсы	Минусы
Нишевый поставщик решения	Кроссплатформенная поддержка и брендированные ссылки. Легко реализовать и интегрировать.	Базовая аналитика. Высокая стоимость, особенно для расширенных функций. Ограниченная гибкость по сравнению с пользовательскими решениями.
Собственное решение (in-house)	Полный контроль над настройкой и гибкостью. Нет зависимости от внешних платформ.	Требует больше времени и усилий для разработки и поддержки, что подразумевает высокую совокупную стоимость владения. Уровень сложности повышается по мере роста приложения. Может не хватать более продвинутых функций, таких как аналитика или атрибуция.
Партнёр по мобильным измерениям (MMP)	Централизованная платформа для диплинкинга и атрибуции приложений. Встроенные интеграции с маркетинговыми инструментами и сетями. Техническая поддержка и возможность масштабирования. Комплексная аналитика.	Более высокая стоимость из-за оплаты подписки или комиссии за использование.

Чек-лист по внедрению

1) Выберите подходящую альтернативу

Отберите и протестируйте потенциальные решения на основе своего списка требований. Начните с небольшого тестирования, чтобы оценить опыт интеграции и основные функции.

2) Настройте диплинкинг

Если вы выбираете стороннего поставщика, вам нужно будет управлять конфигурацией, включая брендированный домен, сертификаты и DNS CNAME.
Обновите манифесты приложений и права, чтобы убедиться, что вы связываете приложение с Universal Links (iOS) или App Links (Android) и разрешаете диплинкинг.
Интегрируйте SDK вашего поставщика в своё мобильное приложение(-я).

3) Продумайте, как будут работать ссылки

Сопоставьте каждый тип ссылки из FDL с его эквивалентом в новой системе. Задокументируйте логику – это поможет разработчикам, QA и поддержке..

Одним из важных факторов, который может повлиять на масштаб работ, является срок действия (TTL) ссылки в зависимости от сценария. Например, у вас могут быть ссылки, которые действительны в течение 28-дневной кампании, которую вы использовали в push-уведомлениях. Хотя кампания может ещё быть активной, тем не менее она будет завершена после окончания поддержки. Процесс анализа того, каким ссылкам потребуется миграция, будет влиять на ваш план и сроки работ.

4) Переведите ссылки из формата Firebase в новый формат

Кажется, что перевод ссылок – это простой процесс, но ему требуется тщательное планирование. После того, как вы подготовите план для своих ссылок, вы будете знать их схему данных детализацию. Теперь вам нужно понять, какие параметры в новой ссылке поддерживают ту же функциональность.

Тут возможны несколько вариантов:

Отличия только в названии. Это лёгкий вариант, потому что фактически идёт сопоставление 1:1.
Стандартного решения нет. В этом случае вам нужно будет создавать свой пользовательский параметр.
Поддержка на другом уровне детализации. В таком случае вам придётся определить необходимый уровень детализации для отчётности.

Имейте в виду, что существуют инструменты, которые помогают в процессе перевода и могут упростить весь процесс.

5) Настройте редиректы

Если есть возможность, настройте редиректы с вашего старого домена FDL на ваш новый домен ссылки. Для этого может потребоваться контроль домена, используемый в вашем проекте Firebase.

Если вы являетесь владельцем домена, вы можете настроить редирект на новый домен.

Если вы не являетесь владельцем домена, есть следующие варианты:

Переключение на пользовательский домен в Firebase для диплинкинга, если это возможно.
Создание прокси-сервера для обработки редиректа.
Взаимодействие с пользователями для обновления старых ссылок вручную в разных каналах.

6) Обновите код приложения

Интегрируйте новый SDK.
Обновите логику парсинга и маршрутизации ссылок на основе функциональности нового SDK.
Если необходимо, поддерживайте обратную совместимость с устаревшими ссылками.

7) Поэтапная миграция

Как и c любым другим обновлением продукта, снизить риск нарушения рабочих процессов может постепенное внедрение. Мы рекомендуем начать с менее приоритетных ссылок, либо ссылок с меньшим трафиком.

Когда вы начнёте процесс миграции, вы можете обнаружить, что в некоторых случаях логика работы отличается от ожидаемой. В таком случае вам придётся принять решение об изменении некоторых этапов работы, а также внедрении этих изменений и в дальнейшем.

Чем больше потоков будет стабилизировано, тем выше будет ваша уверенность, и вы можете продолжать, пока полностью не завершите процесс.

8) Тестируйте, тестируйте и ещё раз тестируйте!

Тестирование является критически важной частью реализации. Чем больше вы тестируете, тем выше уверенность.

Что же нужно тестировать?

iOS и Android, причём разные версии этих ОС
Свежие установки, обновления и повторные вовлечения.
Разные типы ссылок (веб, приложение, СМС, электронная почта, QR-коды и т. д.)
Исключения, такие как офлайн-доступ или приложения для обмена ссылками

Оптимизируйте потоки

Миграция – отличный повод пересмотреть старые сценарии: убрать устаревшее, поправить слабые места и попробовать новые идеи.

Обязательно документируйте все изменения на протяжении всего процесса. После выполнения всех рекомендаций, вы сможете начать оптимизацию – для роста LTV, улучшения удержания и других важных метрик.

Выводы

Миграция с Firebase Dynamic Links – неизбежный шаг, но он не обязательно должен быть сложным. Если вы заранее оцените текущую настройку, чётко определите требования и выберете подходящее решение – переход пройдёт без потерь.

Что бы вы ни выбрали – провайдера, собственную систему или MMP – главное: спланируйте и внедряйте поэтапно.

Тестирование и постепенное внедрение помогут выявить ошибки и отточить стратегию диплинкинга на будущее.

Миграция — это ещё и шанс улучшить пользовательские сценарии, сделать приложение эффективнее и повысить вовлечённость.

Если подойти к процессу организованно, вы сохраните стабильную и удобную работу приложения — даже после отключения Firebase Dynamic Links.

Готовы к быстрой миграции? OneLink от AppsFlyer предлагает всё необходимое, чтобы провести миграцию без потери качества — в те сроки, которые вам нужны. Подробнее.