Всем привет!
Хочу поделиться своим опытом понимания такой сущности, как deep links. Во-первых, чтобы аккумулировать знания, полученные на проекте, а во-вторых — чтобы обменяться ими для более эффективного решения задач и развития общей технической культуры. Надеюсь, материал окажется полезным.

Если коллеги заметят какие-то неточности или важные дополнения — буду благодарен за комментарии.

Что такое Deep Link?

Deep Link — это URL, который переводит пользователя не просто на стартовую страницу приложения, а сразу в нужный экран или на конкретный контент внутри него. Проще говоря, диплинк позволяет пропустить «лишние клики» и доставить пользователя прямо к действию: например, к форме регистрации, экрану с товаром или вводу промокода.

Диплинки улучшают UX, позволяют точно отслеживать переходы и упрощают рекламные кампании. Диплинки актуальны для мобильных приложений и сайтов: пользователь кликает в рассылке или рекламе — и сразу попадает внутрь приложения в нужное место или он не попадает в нужное вместо, а дойдя до него через какие‑то шаги, предопределенные бизнес‑логикой получает страницу с предустановленными параметрами для юзера, которые были зашиты в диплинке.

? Пример:
URL диплинка может выглядеть так: https://app.test‑app.com/deep‑link/?promocode=START, где параметр promocode передаёт код, который должен автоматически примениться в приложении. В данном примере при переходе в приложение на странице paywall автоматически применится промокод, который подтолкнёт юзера к покупке, тем самым увеличив конверсию.

Что такое Deferred Deep Link?

Deferred Deep Link (отложенный диплинк) — это разновидность диплинка, рассчитанная на ситуацию, когда приложение ещё не установлено на устройстве пользователя. Сценарий работы следующий:

• Пользователь кликает по диплинку (например, из письма или рекламы).

• Ссылка сначала ведёт через ваш сервер или CDN (смотри ниже) на страницу с объяснением (некими инструкциями для юзера) или сразу в магазин приложений (App Store/Google Play).

• Пользователь устанавливает и запускает приложение.

• Приложение «вспоминает» диплинк, по которому пришёл пользователь, и автоматически передаёт соответствующие данные (например, промокод или реферала) на нужный экран.

Этим мы «не теряем» пользователя даже если приложение установлено после клика.

? Как приложение понимает, что это тот самый пользователь?

При клике на диплинк бекенд сохраняет уникальный идентификатор диплинка — deep link токен (например, 123e0000-e89b-12d3-a456-426614174123) и связанные параметры (промокод, реферал и т. д.) в базе данных. Когда приложение запускается впервые, оно запрашивает у сервера данные диплинка по этому токену и получает все нужные параметры, после чего подставляет их в интерфейс (например, промокод на экран оплаты). Таким образом даже после установки мы узнаём, что пользователь пришёл по конкретному диплинку — это и есть deferred linking.

? Компоненты системы диплинков

Основные части системы, участвующие в работе диплинков:

• CDN (Content Delivery Network, сеть доставки контента, например, CloudFront). Принимает входящие запросы по диплинк‑URL и перенаправляет их на ваш бэкенд. На практике у вас будет домен вида *.cloudfront.net (для теста) или собственный (prod), например app.test‑app.com, на который указывает запись CDN.

• Backend API. Приложение вашего сервера с эндпоинтами для создания, отслеживания и применения диплинков. Например, при клике по ссылке приходит POST /api/deep-links с параметрами, и генерируется уникальный токен диплинка, сохраняющийся в базе.

• База данных. Хранит записи диплинков: токен, связанные данные (промокод, referrer), статусы и метки времени. По ним можно понять, к какому диплинку относится конкретный запрос и какие параметры нужно выдать приложению.

• Мобильное приложение. Обрабатывает переходы по диплинкам. Когда приложение запускается (или уже открыто), оно может принимать в себе специальный URL‑схем или App Link, запрашивать данные с сервера и автоматически подставлять параметры (промокоды, реферал и т. д.) в интерфейс.

• Устройство пользователя. Взаимодействует с диплинком: переходит по ссылке, получает нужный контент. Если приложение не установлено, устройство загружает страницу и перенаправляется в магазин приложений. После установки приложение на устройстве связывается с бэкендом (например, по сохранённому токену диплинка) и получает данные.

Статусы диплинков

В реализации обычно отслеживаются статусы перехода по диплинку. Примеры статусов:

• opened — диплинк открыт (клик прошёл успешно, несмотря на то, установлено приложение или нет).

• installed — приложение установлено после перехода по диплинку (статус зафиксирован при первом запуске после установки).

• already_installed — приложение было установлено до клика, диплинк открылось сразу в приложении в штатном режиме (фоновый или явный переход).

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

Сценарии работы диплинков

1. Пользователь кликает на диплинк без установленного приложения (Deferred Deep Link).

• Клик по диплинку: Пользователь нажимает на ссылку, например https://app.test‑app.com/deep‑link/?id=123&promocode=START.
  CDN передаёт запрос вашему бэкенду.

• Логирование клика: Бэкенд принимает POST /api/deep-links с телом запроса, где в параметре url указано, по какому диплинку перешёл пользователь. На основе, к примеру, promocode формируется запись в БД с новым уникальным токеном диплинка (например, 123e0000-e89b-12d3-a456-426614174123) и статусом opened. Пользователь пока неизвестен (user_id = null), но параметры (промокод) сохранены.

  Тело запроса:
  {
  "url": "/deep-link?promocode=START"
  }

• Переход в магазин приложений: Далее CDN или бэкенд перенаправляют пользователя в App Store/Google Play, где он видит приложение и устанавливает его.

• Первый запуск приложения: После установки при первом запуске приложение шлёт на сервер запрос типа PATCH /api/deep-links/{deeplink-token}, уведомляя, что оно установлено.

  {
    "status": "installed"
  }

• При этом пользователь уже может быть зарегистрирован, и в запись диплинка добавляется его user_id, меняется статус на installed. Этот шаг даёт понять, что пользователь именно после клика установил приложение.

• Получение параметров диплинка: Затем приложение выполняет GET /api/deep-links/{deeplink-token} по сохранённому токену и получает JSON с данными:

  {
    "id": "123e0000-e89b-12d3-a456-426614174123",
    "data": {
      "referral": "My friend"
    },
    "paywall": {
      "promocode": "string"
    }
  }

  После этого приложение самостоятельно подставляет промокод на нужном экране (например, экране оплаты).

Таким образом, даже если приложение изначально не было на устройстве, после установки и первого запуска мы «узнаём», с каким диплинком он связан. На Android это обычно делается с помощью Play Install Referrer API, а на iOS — через кастомную реализацию (см. ниже).

2. Пользователь кликает на диплинк при уже установленном приложении.

• Если приложение уже установлено (already_installed), то при клике система сразу открывает приложение. Здесь на сервер может идти тот же запрос на логирование диплинка (opened), но уже со статусом already_installed. Приложение получает из URI все параметры (например, promocode=…) и сразу переходит к нужному экрану или применяет код. В этом случае нет шага установки, приложение просто обрабатывает диплинк «на лету».

❓ Как приложение понимает источник установки

Android (Play Install Referrer): Google предоставляет Install Referrer API, который позволяет приложению при первом запуске получить строку referrer — то есть параметры ссылки, по которой велась установка. Пример: если пользователь переходит по адресу https://play.google.com/store/apps/details?id=com.app&referrer=id%3В123e0000-e890-12d3-a456-426614174123, то после установки приложение при первом запуске запросит Install Referrer API и получит строку id=123e0000-e890-12d3-a456-426614174123. Её парсят и понимают, что это токен диплинка. Затем можно сделать GET к серверу по этому deeplink-token, чтобы получить все параметры (промокод, реферала, экран) и применить их. Google обрабатывает это безопасно и гарантирует, что referrer действительно тот, что был у ссылки, ведущей в Play Store.

iOS (Clipboard): Официального аналога Play Install Referrer в iOS нет, поэтому часто используют обходные пути. Одним из распространённых приёмов является копирование идентификатора диплинка в буфер обмена. Алгоритм может быть таким: когда пользователь кликает диплинк (например, в письме или браузере), сервер сохраняет deep_link_id и при этом копирует его в буфер обмена устройства. После установки и первого запуска приложение проверяет буфер: если там есть ожидаемый идентификатор, оно предлагает вставить код или автоматически привязывает установку к диплинку. Таким образом с помощью clipboard пользователю предлагают «вставить» промокод, после чего приложение получает все данные диплинка.

? Тестирование диплинков

Тестировщику важно проверить обе ситуации: когда приложение уже есть и когда оно устанавливается «после клика». Рекомендуется тестировать на реальных устройствах, так как только в реальных условиях (с Google Play, App Store и т. д.) мы получим точный результат.

При тестировании следует прогонять следующие проверки:

• Общее: тестируйте разные состояния приложения — когда оно закрыто, работает в фоне, когда пользователь залогинен и нет. Убедитесь, что во всех случаях диплинк обрабатывается корректно: на экране появляется нужный контент, активируется промокод или реферальный код и т. п.

• База данных: проверяйте, что данные по диплинкам сохраняются в базе данных корректно (токен, user_id, url диплинка и т. д.)

• Статусы и аналитика: смотрите в бэкенде, что для каждого перехода выставляются правильные статусы (opened, installed, already_installed).

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

✅ Выводы

Диплинки — мощный инструмент для улучшения конверсии и удобства пользователей, но они усложняют логику приложения. Тестировщику важно понимать обе стороны процесса: как сервер генерирует и хранит диплинки, и как приложение их обрабатывает. Следует особенно внимательно протестировать deferred deep links — убедиться, что даже при установке «после клика» пользователь попадёт на нужный экран с нужными параметрами. При этом стоит помнить различия между Android и iOS: Google Play предоставляет стандартные средства (Install Referrer), а в iOS часто обходятся своими приёмами (буфер обмена, Universal Links). Применяя структурированный подход к тестированию (варианты «приложение уже установлено» и «установлено после клика», разные состояния приложения, разные устройства), можно гарантировать, что диплинки реально ускоряют путь пользователя к цели, а не создают новых багов.