Deep link на iOS и Android: практический гид

Deep link — это адрес, который открывает конкретный экран внутри установленного приложения вместо веб-страницы. В этом вся идея, и за пятнадцать лет она была реализована тремя разными способами, у каждого из которых свои характерные сбои. Маркетинговые команды продолжают заводить об этом баги ровно потому, что все три способа существуют одновременно, и один и тот же адрес может вести себя по-разному в зависимости от того, где по нему нажали: в сообщении, в браузере, в почтовом клиенте или во встроенном вебвью внутри соцсети.

Этот гид объясняет механизмы честно, включая то, чего они не умеют. Если запомнить из него одну вещь, пусть это будет вот что: доставить клик на нужный экран приложения — решённая инфраструктурная задача, а привести пользователя на нужный экран после того, как он установил приложение, — нет, по крайней мере силами одной только платформы ссылок.

Три поколения ссылок в приложения

Собственные URL-схемы

Исходный механизм. Приложение регистрирует схему вроде myapp, и адрес вида myapp://product/42 передаёт запрос ему. Схемы тривиальны в реализации и по-прежнему полезны как внутренний формат маршрутизации, но несут две структурные проблемы.

Подтверждения владения нет: зарегистрировать любую схему может любое приложение, а когда одну и ту же схему заявляют два приложения, на iOS результат не определён, а на Android появляется диалог выбора. И нет запасного варианта: на устройстве без установленного приложения адрес со схемой выдаёт страницу ошибки или вообще ничего, поэтому каждой ссылке со схемой нужна обёртка, которая распознаёт неудачу и отправляет пользователя туда, где есть смысл. Именно эта обёртка и оказалась тем хрупким местом, которое сломалось, когда браузеры ужесточили обработку таймеров навигации.

Universal Links на iOS

Замена от Apple работает на обычных HTTPS-адресах. Приложение объявляет право на связанный домен в виде applinks:yourbrand.com, а домен публикует JSON-файл по пути /.well-known/apple-app-site-association, описывающий, какие пути принадлежат приложению.

{
  "applinks": {
    "details": [
      {
        "appIDs": ["ABCDE12345.com.yourbrand.app"],
        "components": [{ "/": "/p/*", "comment": "Product pages" }]
      }
    ]
  }
}

Файл должен отдаваться по HTTPS без редиректов, в виде JSON и ровно по этому пути. iOS забирает его примерно во время установки и обновления, преимущественно через CDN Apple, а значит, изменения вступают в силу не мгновенно. Выигрыш в том, что один и тот же адрес работает везде: если приложение установлено и путь подходит, оно открывается; если нет — Safari загружает веб-страницу. Состояния ошибки не возникает.

App Links на Android

Аналог в Android использует файл Digital Asset Links по пути /.well-known/assetlinks.json, где указаны пакет приложения и отпечаток SHA-256 подписывающего сертификата.

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.yourbrand.app",
      "sha256_cert_fingerprints": ["A1:B2:C3:D4:E5:F6:..."]
    }
  }
]

На стороне приложения объявляется intent-фильтр для домена с включённой автоматической проверкой. Когда проверка проходит, ссылка открывает приложение без диалога выбора. Когда не проходит — ссылка открывает браузер, и самая частая причина с большим отрывом — несовпадение отпечатка: команда публикует отпечаток своего локального релизного ключа, тогда как Play App Signing переподписывает приложение другим. В файле должен стоять тот отпечаток, который магазин показывает для распространяемой сборки.

Как короткая ссылка выбирает адрес назначения

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

Движок редиректа видит строку User-Agent запроса, передаваемые с ним клиентские подсказки и выведенные из сети сигналы вроде страны. Ссылка, настроенная под трафик приложения, обычно держит три адреса назначения: адрес для iOS, адрес для Android и веб-адрес для всех остальных. Поверх этого правила таргетинга умеют маршрутизировать по стране, устройству, операционной системе или языку, поэтому кампания может отправлять канадский Android-трафик на один адрес, а всех прочих — на другой, не заводя отдельных ссылок.

Две детали реализации стоит знать, потому что они объясняют большую часть непонятного поведения.

Первая — краулеры соцсетей. Когда бот вроде сборщика превью Facebook или Telegram запрашивает ссылку, чтобы построить карточку, корректный движок редиректа отвечает ему метаданными превью, а не засчитывает запрос как клик и не маршрутизирует его так, будто это телефон. Если ваши счётчики кликов подскакивают в тот момент, когда ссылку опубликовали, и до того, как по ней кто-то нажал, — движок так не делает.

Вторая — граница связи домена с приложением, и это самый важный технический пункт статьи. Universal Links сверяются с доменом того адреса, по которому пользователь реально нажал. Если кто-то нажимает go.yourbrand.com/p/42, а этот домен отвечает редиректом на yourbrand.com/p/42, iOS не считает цель редиректа связанной ссылкой, и приложение не открывается. Чтобы короткая ссылка открывала приложение нативно, файл связи должен отдаваться на самом коротком домене. Там, где это невозможно, практический запасной путь — передача на собственную схему или сразу в магазин, и именно так на деле работает большинство функций deep link у сокращателей. Спрашивайте любого поставщика, какой из двух вариантов реализован у него, потому что рекламный текст в обоих случаях одинаков.

Цепочка запасных вариантов

Работающая ссылка в приложение — по сути небольшое дерево решений, и каждой ветке нужен осознанный ответ.

| Ситуация | Что должно произойти | Частая ошибка | | --- | --- | --- | | Приложение установлено, путь распознан | Приложение открывается на нужном экране | Цепочка редиректов ломает связь | | Приложение установлено, путь не распознан | Загружается веб-страница, приложение предлагается | Диалог выбора показывается при каждом нажатии | | Приложение не установлено, мобильное устройство | Страница магазина для нужной платформы | Ссылка на магазин зашита под одну платформу | | Десктоп | Полноценный веб-эквивалент экрана | Посадка на общую главную страницу | | Краулер соцсети | Метаданные превью, клик не засчитан | Запрос превью раздувает аналитику |

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

Граница установки, честно

Вот здесь маркетинг поставщиков расходится с реальностью. Допустим, новый пользователь нажимает ссылку на конкретный товар, приложения у него нет, он попадает в магазин, устанавливает его и открывает. Приложение показывает свой обычный домашний экран, потому что идентификатор товара через установку никто не пронёс. Чтобы это работало, нужен отложенный deep linking — маршрутизация, переживающая установку приложения, — и платформе ссылок в одиночку это не под силу.

Требуется SDK внутри приложения, который при первом запуске спрашивает у сервера, по чему пользователь нажал до установки. Сервер должен сопоставить два события, а набор сигналов, доступных для такого сопоставления, резко сузился. Снятие отпечатка устройства ненадёжно и всё сильнее ограничивается правилами платформ. Рекламные идентификаторы требуют согласия, которого большинство пользователей не даёт. Фреймворки атрибуции Apple сообщают рекламодателю атрибуцию на уровне установки, а не передают путь в ваше приложение. Приём с буфером обмена, который когда-то переносил токен, теперь вызывает заметное уведомление о вставке.

То, что осталось, работает, но это другой продукт с другой стоимостью интеграции: SDK партнёра по мобильной аналитике, инициализация внутри приложения и окно сопоставления, которое вероятностно, а не точно. LinkProfit маршрутизирует клики по устройству и передаёт посетителя в магазин, но маршрутизацию после установки не заявляет, потому что сделать её правильно означает поставить код внутрь вашего приложения. Если отложенная маршрутизация — жёсткое требование, планируйте такой SDK рядом с платформой ссылок, а не вместо неё.

Вебвью и другие практические ловушки

Встроенные браузеры

Большинство ссылок, нажатых внутри соцсетей, открывается во встроенном вебвью, а не в системном браузере, а вебвью обрабатывают связь домена с приложением непоследовательно: одни игнорируют Universal Links, другие блокируют собственные схемы, и поведение различается между версиями приложений. Это самая частая причина, по которой ссылка, безупречно работающая в тестах, в реальности открывает сайт: тестируют обычно нажатием ссылки в мессенджере, а он ведёт себя правильно.

Настройки, которая чинила бы это глобально, не существует. Работает другое: сделать веб-адрес назначения хорошим, добавить на него заметный элемент «открыть в приложении» и тестировать каждый канал публикации по отдельности, а не предполагать, что они ведут себя одинаково.

Ошибки в файле связи

Их четыре, и они повторяются. Отдавать файл связи через редирект — включая автоматический переход с апекс-домена на www, который его обесценивает. Отдавать его с неверным типом содержимого или по пути, который переписывает фреймворк. Публиковать не тот отпечаток подписи Android, как описано выше. И забывать, что iOS кэширует файл, поэтому исправление может добираться до устройств с уже установленным приложением сутки и дольше.

Аналитика в ветке приложения

Как только клик уходит внутрь приложения, ваша веб-аналитика перестаёт его видеть, и именно здесь отчётность тихо разваливается. Держите параметры кампании на ссылке, чтобы движок редиректа их записал, и пробрасывайте идентификатор в адрес назначения приложения, чтобы сессию внутри приложения можно было связать с кликом. Наш гид по отслеживанию кликов разбирает, что событие клика может и чего не может показать, и те же оговорки про ботов и уникальных посетителей действуют здесь.

Тестирование до публикации

curl -sSI https://yourbrand.com/.well-known/apple-app-site-association
curl -sS https://yourbrand.com/.well-known/assetlinks.json

# Android: open a URL as if it were tapped, then inspect verification state
adb shell am start -a android.intent.action.VIEW -d "https://yourbrand.com/p/42"
adb shell pm get-app-links com.yourbrand.app

# iOS simulator
xcrun simctl openurl booted "https://yourbrand.com/p/42"

Первые две команды должны вернуть 200 без редиректа. Учтите, что ввод Universal Link в адресную строку Safari намеренно не открывает приложение, поэтому тестируйте из заметки, из сообщения или командой симулятора — иначе будете гоняться за багом, которого нет.

Что на самом деле включают платформы ссылок

Поддержка deep link упакована в этой категории очень по-разному, и различия касаются того, какой тариф придётся купить, а не самих возможностей.

| Поставщик | Доступность deep link, на август 2026 года | | --- | --- | | BL.INK | Все тарифы, начальный уровень 48 USD в месяц за одного пользователя и один домен | | Short.io | С тарифа Team за 48 USD в месяц | | Rebrandly | С тарифа Growth за 99–119 USD в месяц | | Switchy | Заявленная поддержка более 130 приложений | | LinkProfit | Адреса назначения под устройство на всех тарифах |

BL.INK здесь — честный ориентир: включать поддержку deep link в каждый уровень необычно, пусть начальная цена за один домен и высока. Размещение Rebrandly на уровне Growth — тот шаблон, за которым стоит следить вообще, потому что уровень, нужный ради одной функции, обычно и определяет весь счёт.

Последовательность внедрения, которая работает

1. Определите канонический веб-адрес для каждого экрана приложения, на который хотите вести; веб-страница здесь и запасной вариант, и источник истины.
2. Опубликуйте оба файла связи на том домене, который будет появляться в ссылках, и проверьте их по HTTPS без редиректов.
3. Добавьте право на связанный домен в iOS и проверяемый intent-фильтр в Android, используя отпечаток распространяемой сборки.
4. Уточните, на каком домене будут нажимать ваши короткие ссылки и живёт ли связь там же или платформа передаёт запрос на схему либо в магазин.
5. Настройте на каждой ссылке адреса назначения под устройство плюс веб-запасной вариант, с правильной карточкой магазина для каждой платформы.
6. Протестируйте на обеих платформах: из мессенджера, из системного браузера и из каждой соцсети, в которой вы публикуетесь.
7. Убедитесь, что параметры кампании переживают редирект и записываются в аналитику.
8. Автоматизируйте создание через API, если ссылки генерируются под кампанию, под получателя или под товар.

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