Home

Автор: Павлович Евгений

Всем привет!
Хочу поделиться своим опытом понимания такой сущности, как 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). Применяя структурированный подход к тестированию (варианты «приложение уже установлено» и «установлено после клика», разные состояния приложения, разные устройства), можно гарантировать, что диплинки реально ускоряют путь пользователя к цели, а не создают новых багов.

Обсудить в форуме