Deep Link: как открыть приложение на нужном экране по ссылке

Скажем, твой Telegram-бот присылает пользователю сообщение «Ваша оплата прошла, вот чек» со ссылкой. Человек нажимает — и вместо чека видит главный экран приложения, из которого до чека ещё нужно добраться через три меню. Половина пользователей на этом пути просто потеряется. Решает эту проблему deep link — специальная ссылка, которая открывает приложение сразу на нужном экране. Ниже — что это такое, какие виды бывают, чем deep link отличается от обычного запуска приложения и от PWA-установки, и как всё это применить к своему проекту, не будучи программистом.

Что такое deep link простыми словами

Deep link (в переводе — «глубокая ссылка») — это специальная ссылка, которая при клике не просто открывает приложение с главного экрана, а сразу переносит пользователя на конкретный экран внутри него. Страницу конкретного товара, урок курса, результат теста или экран с результатом оплаты — любое место, до которого иначе пришлось бы добираться вручную через меню и переходы.

Ты сталкиваешься с этим каждый день, просто не замечаешь. Нажимаешь ссылку на видео в мессенджере — открывается не «YouTube вообще», а именно тот ролик, на который ты кликнул. Получаешь письмо с подтверждением заказа — ссылка ведёт не на главную страницу магазина, а на страницу именно твоего заказа. Это и есть deep link в действии.

Самое простое объяснение — через обычные веб-ссылки. Когда ты делишься ссылкой на сайт, ты же не отправляешь человека на главную страницу со словами «дальше сам найдёшь». Ты даёшь ссылку вида moysayt.ru/catalog/krossovki-42 — и она ведёт ровно на страницу этих кроссовок. Deep link — это ровно та же идея, только для экранов внутри приложения. «Глубокая» она потому, что ведёт глубоко внутрь, мимо входной двери.

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

• moyapp://statya/123 — открыть статью с номером 123;
• moyapp://test/result/789 — показать результат теста 789;
• moyapp://payment/success?order=456 — показать экран успешной оплаты заказа 456.

Приложение получает эту ссылку, читает адрес и параметры из неё и показывает нужный экран. Всё, что остаётся пользователю, — один клик.

Зачем это вайбкодеру на курсе

Самый частый сценарий, где deep link нужен тебе лично, — связка приложения с Telegram-ботом. Боты мы уже подробно разбирали в статьях про обновление Telegram 2026 года и про перенос Telegram-бота в MAX. Представь типовую цепочку: бот присылает пользователю уведомление «Ваша статья готова» или «Вы прошли тест, посмотрите результат». Если ссылка в этом сообщении просто открывает приложение на главном экране, человеку придётся самому искать, где же его статья или результат. Каждый лишний шаг — это потерянные пользователи: часть не найдёт нужный раздел, часть просто закроет приложение.

С deep link та же кнопка в боте ведёт сразу туда, куда нужно: на конкретную статью, на экран результата теста, на страницу с чеком после успешной оплаты (приём платежей через ЮKassa мы разбирали в статье как подключить ЮKassa — как раз там сценарий «вернуть пользователя на экран успеха после оплаты» напрашивается сам собой).

То же самое с push-уведомлениями. Пуш «Новый урок курса уже доступен» должен открывать не приложение вообще, а именно этот урок. Иначе уведомление выполняет только половину работы: внимание привлекло, а куда идти дальше — не сказало.

Вот где deep link реально пригождается в типичном приложении, которое собирают на курсе:

• Telegram-бот. Кнопка или ссылка в сообщении открывает конкретный раздел: статью, результат теста, личный кабинет.
• Push-уведомления. Тап по пушу ведёт на экран, про который этот пуш, а не на главную.
• Письма. Ссылка «подтвердить почту», «посмотреть заказ», «продолжить урок» — из письма прямо на нужный экран.
• Реклама и соцсети. Пост про конкретный товар или акцию ведёт на экран этого товара, а не на главную.
• QR-коды. Напечатанный QR открывает не «приложение вообще», а конкретную страницу: меню ресторана, карточку товара, страницу мероприятия.

Обрати внимание: во всех этих сценариях deep link — это про возврат человека в конкретное место. Пользователь уже где-то снаружи (в боте, в письме, в рекламе), и твоя задача — перенести его внутрь приложения с минимальными потерями.

Как это выглядит в учебном проекте

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

Сценарий «Результат теста». В приложении есть раздел с тестами по темам курса. Пользователь проходит тест, а Telegram-бот через день присылает: «Ты прошёл тест на 8 из 10. Хочешь посмотреть разбор ошибок?» Ссылка в кнопке ведёт не на главную, а сразу на экран разбора именно этого теста: moysayt.ru/test/result/789. Человек кликает — и сразу видит свои ошибки, а не ищет их в меню.

Сценарий «Таблица рекордов». Друг побил твой рекорд в игре. Бот присылает: «Тебя обогнали! Теперь ты на 3-м месте». Deep link ведёт прямо на таблицу рекордов, причём можно даже передать параметр, чтобы подсветить твою строку: moysayt.ru/records?highlight=me. Клик — и ты смотришь на таблицу, а не на заставку игры.

Сценарий «Магазин и оплата». Пользователь купил новый скин через ЮKassa. После успешной оплаты платёжная система возвращает его по специальной ссылке — это тоже deep link: moysayt.ru/payment/success?order=456. Приложение читает номер заказа, проверяет статус и показывает экран «Оплата прошла, скин добавлен». Без этой ссылки человек после оплаты попал бы на главную и не понял, прошли ли его деньги.

Сценарий «Статья из бота». Бот каждую неделю присылает подборку новых материалов. Каждая кнопка — deep link на конкретную статью: moysayt.ru/statya/123. Конверсия таких кнопок заметно выше, чем у общей кнопки «Открыть приложение», потому что человеку не нужно ничего искать.

Заметь общий паттерн: везде ссылка состоит из двух частей — адреса раздела (/statya, /test/result, /records) и параметра (123, 789, order=456). Придумать эти адреса и описать, что должен показывать каждый, — это и есть проектирование deep link в твоём приложении. Кодом займётся ИИ, а карта адресов — твоя задача как постановщика.

Чем deep link отличается от запуска приложения по иконке

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

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

Разница видна даже в том, как выглядит «маршрут» пользователя:

Параметры в ссылке — важная часть картины. В ссылке moyapp://order/456 часть 456 — это параметр: номер заказа. Приложение видит его, запрашивает у сервера данные именно этого заказа и показывает экран с ними. Ссылка moyapp://order/457 откроет уже другой заказ, хотя код приложения тот же самый. Один и тот же механизм обслуживает любые страницы — разница только в параметре.

Чем deep link отличается от PWA-установки

Эти две темы часто путают, потому что обе связаны со словом «приложение» и обе про удобство пользователя. Но они решают разные задачи.

PWA (прогрессивное веб-приложение) — это про то, КАК установить веб-сайт как приложение на экран телефона: чтобы у него была своя иконка, оно открывалось в отдельном окне без адресной строки браузера и могло работать офлайн. Мы подробно разбирали это в статье GitHub Pages и PWA для новичка. PWA отвечает на вопрос: «Как моему проекту жить на телефоне пользователя рядом с обычными приложениями?»

Deep link — это про то, КУДА именно внутри уже установленного приложения ведёт конкретная ссылка. Он отвечает на вопрос: «Пользователь кликнул ссылку — на какой экран его посадить?»

Проще всего увидеть разницу так:

• PWA = как приложение попадает на телефон и как выглядит его запуск (иконка, отдельное окно, офлайн).
• Deep link = как ссылка извне попадает в конкретное место внутри приложения.

Они не конкурируют, а дополняют друг друга. У тебя может быть PWA без deep link — приложение ставится на телефон, но все ссылки ведут на главную. Может быть deep link без PWA — нативное приложение из магазина с умными ссылками. А может быть и то, и другое: веб-приложение, установленное на телефон, куда ссылки из бота ведут сразу на нужные страницы. Если твоё приложение вообще веб-приложение, живущее в браузере, то хорошая новость в том, что для него обычные https-ссылки вида moysayt.ru/statya/123 уже работают как deep link «из коробки» — браузер сам открывает нужный адрес.

Виды deep link: обычные, universal links и deferred

Всего есть три основных вида deep link, и отличаются они главным образом тем, что происходит, если приложение не установлено на устройстве.

Обычные deep link (custom scheme)

Это самый простой и старый вид. Приложение регистрирует в системе собственную схему ссылок — уникальный префикс вроде moyapp://. Любая ссылка с этим префиксом говорит операционной системе: «открой меня в приложении, которое зарегистрировало схему moyapp».

Плюсы: просто настроить, работает везде. Минус один, но серьёзный: если приложение не установлено, ссылка ведёт в никуда. Пользователь кликает — и видит ошибку «не удаётся открыть страницу» или вообще ничего не происходит. Поэтому обычные deep link хороши для сценариев, где ты уверен, что приложение уже стоит: кнопки внутри самого приложения, пуши, которые может получить только установивший.

Universal Links (iOS) и App Links (Android)

Это более умная версия. Ссылка выглядит как обычный веб-адрес: https://moysayt.ru/statya/123. Система сначала проверяет: установлено ли приложение, связанное с этим доменом? Если да — открывает ссылку прямо в приложении, минуя браузер. Если нет — открывает сайт в браузере, и пользователь всё равно видит контент, пусть и в веб-версии.

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

Цена вопроса — дополнительная настройка. Чтобы система поверила, что домен moysayt.ru действительно связан с твоим приложением, на сайт нужно положить специальный файл-подтверждение (для iOS это файл apple-app-site-association, для Android — assetlinks.json). Он доказывает, что ты владеешь и сайтом, и приложением. Без этого шага любой мог бы перехватывать чужие ссылки.

Deferred deep link (отложенные)

Самый хитрый вид. Сценарий такой: пользователь кликает ссылку, приложения у него нет, он устанавливает его из магазина — и после первого запуска приложение само открывает тот экран, на который вела исходная ссылка. То есть система «запомнила», куда человек хотел попасть, и довела его туда уже после установки.

Пример: реклама показывает конкретные кроссовки со скидкой. Человек кликает, попадает в магазин приложений, ставит приложение, открывает — и видит не главную, а карточку именно тех кроссовок из рекламы. Для маркетинга это золото: цепочка «реклама → установка → нужный экран» не разрывается.

Deferred deep link «из коробки» не делается — сам по себе механизм ссылок такого не умеет, потому что между кликом и первым запуском приложения стоит магазин приложений, который разрывает цепочку. Нужны сторонние сервисы-атрибуторы (например, AppsFlyer, Adjust, Branch), которые сопоставляют клик и установку. Это уже инструменты для этапа роста и рекламы, а не для первого приложения.

Краткая сводка:

Как это работает на практике

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

Шаг 1. Регистрация схемы ссылок

Сначала приложение заявляет операционной системе: «ссылки такого вида — мои». Есть два пути:

• Своя схема: moyapp://stranica/123. Регистрируется в настройках приложения, работает только при установленном приложении.
• Обычный домен (для universal links): https://moysayt.ru/stranica/123. Потребуется тот самый файл-подтверждение на сайте.

Для веб-приложения или PWA второй путь вообще не требует телодвижений: адреса вида https://moysayt.ru/statya/123 уже и есть твои ссылки, их понимает любой браузер.

Шаг 2. Роутер внутри приложения

Роутер — это часть кода, которая читает адрес из ссылки и решает, какой экран показать. Логика простая: взяли ссылку moyapp://statya/123, разобрали её на части — раздел statya, параметр 123, — и показали экран статьи, подгрузив статью номер 123.

Если приложение написано на веб-технологиях (как проекты на курсе), роль роутера обычно играет сам URL: /statya/123 в адресной строке и есть адрес экрана. В нативных приложениях роутер пишут отдельно, но идея та же.

Шаг 3. Ссылка наружу

Дальше ты просто вставляешь такую ссылку туда, откуда приходят люди: в кнопку Telegram-бота, в письмо, в пост, в QR-код. Бот вместо «установите наше приложение» присылает «Ваш результат готов: [смотреть]» — и кнопка ведёт сразу на экран результата.

Вот как выглядит весь путь целиком:

flowchart TB
    A["Пользователь нажимает ссылку в Telegram"] --> B["ОС проверяет схему ссылки"]
    B --> C["Приложение открывается"]
    C --> D["Роутер читает адрес и параметры"]
    D --> E["Показан нужный экран"]

Как поставить задачу ИИ

Поскольку код пишет ИИ-ассистент, твоя работа — грамотно описать желаемое поведение. Хорошая постановка звучит примерно так:

«Сделай так, чтобы ссылка вида /statya/{id} открывала в приложении экран статьи с этим id. Если статьи с таким id нет, покажи экран "статья не найдена" с кнопкой на главную. В Telegram-боте замени кнопку "Открыть приложение" на кнопку со ссылкой на конкретную статью».

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

• Что делать, если адрес неверный. Пользователь может кликнуть старую ссылку на удалённую статью. Приложение не должно падать или показывать пустоту — нужен вежливый экран «не найдено».
• Что делать, если пользователь не вошёл в аккаунт. Если экран доступен только после входа, deep link должен сначала отправить на вход, а потом — на нужный экран. Это тоже описывается в задаче.

Метки в ссылках: откуда пришёл пользователь

Полезный бонус: в deep link можно добавлять служебные параметры, которые не влияют на экран, но говорят приложению, откуда пришёл человек. Например: moysayt.ru/statya/123?from=bot-weekly — ссылка из еженедельной рассылки бота, а moysayt.ru/statya/123?from=push — та же статья, но из пуша. Приложение открывает в обоих случаях один и тот же экран, но в аналитику записывает источник. Через пару недель ты увидишь, какие каналы реально приводят людей внутрь приложения, а какие только рассылают ссылки в пустоту. В вебе эту же роль играют UTM-метки — идея полностью та же.

Как проверить, что deep link работает

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

Проверка 1. Прямой переход. Отправь себе ссылку на конкретный экран — например, через «Избранное» в Telegram или в письме самому себе. Кликни. Должен открыться именно тот экран, на который ведёт ссылка, а не главная.

Проверка 2. Разные параметры. Кликни ссылки с двумя разными id: .../statya/123 и .../statya/124. Должны открыться две разные статьи. Если открывается одно и то же — роутер игнорирует параметр, это баг.

Проверка 3. Несуществующий адрес. Кликни ссылку с заведомо неверным id: .../statya/999999. Должен показаться вежливый экран «не найдено» с возможностью уйти на главную — не белый экран и не зависание.

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

Проверка 5. Ссылка без приложения. Если у тебя universal links — попроси кого-нибудь, у кого приложение не установлено (или удали его с тестового устройства), кликнуть ссылку. Должна открыться веб-версия страницы, а не ошибка.

Проверка 6. Старые ссылки. Если ты менял структуру адресов, кликни ссылку старого формата. В идеале она должна либо перенаправлять на новый адрес, либо показывать экран «не найдено» — но не падать.

Ограничения и подводные камни

Deep link — не магия, и у механизма есть честные ограничения, о которых лучше знать заранее.

Обычная схема не работает без приложения. Ссылка moyapp://... для человека без установленного приложения — это ошибка. Если аудитория ещё не установила приложение, нужны universal links или веб-версия.

Universal links требуют домена и файла-подтверждения. Чтобы связать приложение с доменом, нужно разместить специальный файл на своём сайте — так iOS и Android проверяют, что ты действительно владелец и сайта, и приложения. Без домена и доступа к хостингу этот вид ссылок не настроить. Актуальные требования к этим файлам смотри в официальной документации Apple и Android — детали иногда меняются.

На старых версиях ОС поведение может отличаться. Старые Android и iOS не всегда обрабатывают universal links так же гладко, как свежие. Где-то ссылка откроется в браузере вместо приложения, где-то система спросит, чем открыть. Это не поломка твоего приложения — это особенность платформы.

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

Deferred-ссылки требуют стороннего сервиса. Запоминание адреса через установку из магазина не работает само по себе — нужен сервис атрибуции. Для первого приложения это обычно рано.

Частые ошибки при внедрении

Собрал типичные грабли, на которые наступают новички, когда добавляют deep link в первый раз.

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

Ошибка 2. Забыть экран «не найдено». Ссылки живут долго: их пересылают, сохраняют, публикуют в соцсетях. Статью удалят, заказ архивируют, а ссылка останется. Без экрана «не найдено» каждый такой клик — испорченное впечатление.

Ошибка 3. Потерять адрес после входа. Пользователь кликнул ссылку на личный раздел, приложение отправило его на экран входа, он вошёл — и оказался на главной. Адрес, за которым он пришёл, потерялся по дороге. Правильное поведение: запомнить адрес, провести через вход и вернуть туда, куда он шёл. Это надо явно проговаривать в задаче для ИИ.

Ошибка 4. Непонятные адреса. Ссылки вида moyapp://p2/x?e=7 работают, но через месяц ты сам не вспомнишь, что это. Делай адреса читаемыми: /statya/123, /test/result/789, /payment/success?order=456. Это помогает и тебе, и ИИ, которому ты потом ставишь задачи.

Ошибка 5. Тянуть deferred-ссылки слишком рано. Пока нет платной рекламы на установки, сервис атрибуции — лишняя сложность и лишние расходы. Начни с простых https-ссылок, а deferred подключишь, когда они реально понадобятся.

Честный вывод: когда это нужно, а когда рано

Deep link — обязательная вещь, как только приложение вырастает больше одного экрана и ты начинаешь делиться конкретными страницами: через Telegram-бота, почту, пуши, рекламу или QR-коды. Без него каждая внешняя ссылка сбрасывает человека на главную, и часть пользователей теряется по дороге. Особенно это критично в цепочках с деньгами: «оплатил → вернулся на экран успеха» и в сценариях «бот прислал уведомление → пользователь попал ровно в нужный раздел».

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

Хорошая новость для вайбкодера: если твоё приложение — веб-приложение или PWA, то базовый deep link у тебя уже есть бесплатно. Адреса вида https://moysayt.ru/statya/123 — это и есть deep link: браузер и установленное PWA откроют именно эту страницу. Останется только научить бота и письма присылать ссылки на конкретные страницы вместо главной — а это уже вопрос одной хорошо поставленной задачи для ИИ.

Частые вопросы

Deep link — это только для мобильных приложений?

Нет. Сама идея — «ссылка на конкретное место внутри» — работает и для веб-приложений: адрес moysayt.ru/statya/123 ведёт не на главную, а на конкретную страницу. Просто в вебе это настолько естественно, что отдельного названия долго не требовалось. Термин «deep link» закрепился за мобильными приложениями, где открыть нужный экран по ссылке — отдельная техническая задача.

Что будет, если человек кликнет deep link, а приложение не установлено?

Зависит от вида ссылки. Обычная схема (moyapp://...) покажет ошибку или ничего не сделает. Universal link / App Link (https://...) откроет сайт в браузере — пользователь всё равно увидит контент. Deferred deep link отправит в магазин за установкой и после неё откроет нужный экран, но это требует стороннего сервиса.

Чем deep link отличается от обычной ссылки на сайт?

По идее — ничем: и та, и другая ведёт на конкретное место. Разница в том, что открывает ссылку. Обычная веб-ссылка открывается в браузере. Deep link дополнительно умеет открываться внутри установленного приложения и передавать туда параметры, например id заказа или номер статьи.

Нужен ли deep link для PWA?

Не обязательно, но полезно. PWA само по себе решает вопрос «как установить сайт на телефон как приложение», а deep link — «куда вести пользователя внутри». Для PWA обычные https-адреса уже работают как deep link: ссылка на конкретную страницу откроет именно её. Специальная настройка нужна, только если хочешь, чтобы ссылки перехватывались установленным приложением вместо браузера.

Это сложно сделать, если я не программист?

Базовый сценарий — несложно: код за тебя пишет ИИ, а твоя задача — описать поведение словами: «ссылка /test/result/789 должна открывать экран результата теста 789, а если результата нет — показывать экран "не найдено"». Сложнее с universal links: там понадобится свой домен и файл-подтверждение на нём, но и это делается один раз по документации.

Что такое deferred deep link и нужен ли он мне?

Это ссылка, которая «запоминает» нужный экран, даже если пользователь сначала устанавливает приложение из магазина: кликнул по рекламе конкретного товара → установил приложение → открылся экран того товара. Для этого нужен сторонний сервис атрибуции (AppsFlyer, Adjust, Branch и подобные). На этапе первого приложения это обычно избыточно — deferred-ссылки имеет смысл подключать, когда запускаешь платную рекламу на установки.