Диплинки в приложении: как открывать нужный экран и не терять пользователя

Пригласили на урок, а открылась главная

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

Приложение вроде бы работает. Ссылка тоже что-то открывает. Но человек получил лишнюю задачу вместо обещанной записи. И особенно обидно, что он уже сделал всё, о чём его попросили: перешёл и подтвердил свой аккаунт.

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

Сначала решите, куда должна вести ссылка

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

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

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

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

Что означают Universal Links и App Links

В разговоре с разработчиками вы встретите названия Apple Universal Links и Android App Links. В общих чертах это способы связать обычные веб-адреса с приложением. Связь подтверждается настройками приложения и сайта. Подробности описаны в руководстве Apple и проверке App Links для Android.

Есть и адреса специального вида, например exampleapp://lesson/123. Однако без соответствующего приложения такой адрес не превращается в полезную веб-страницу. Для приглашений, которыми люди делятся между собой, обычно удобнее начинать с HTTPS-ссылки на собственном домене.

Здесь важно не смешивать три разные задачи. Телефон должен понять, какому приложению передать ссылку. Приложение должно найти нужный экран. Сервер должен проверить, имеет ли человек право видеть его содержимое. Если решена только первая задача, может открыться главная страница или чужая закрытая информация.

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

После входа человек должен продолжить, а не начать заново

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

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

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

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

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

Если приложение ещё не установлено

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

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

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

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

Предусмотрите и простой запасной путь. Например, после установки предложите снова открыть исходное приглашение. Или дайте ввести код, если ваша система действительно поддерживает такой способ. Это лишний шаг, но он честнее бесконечного поиска нужного курса на главной. Не стоит восстанавливать переход за счёт скрытого сбора данных, о котором пользователь ничего не знает.

Что показывать вместо тупика

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

Если запись на занятие закончилась, так и напишите. Можно предложить другие даты или перейти к расписанию, но нельзя молча заменить одно занятие другим. Иначе человек решит, что записывается туда, куда его пригласили, хотя приложение уже поменяло смысл действия.

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

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

Небольшая проверка, которую стоит провести вместе с командой

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

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

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

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

Старые ссылки и статистика требуют отдельного внимания

Firebase Dynamic Links прекратил работу 25 августа 2025 года. Если раньше вы использовали этот сервис, проверьте старые письма, автоматические сообщения и QR-коды. Обновление приложения само по себе не заменяет адреса в уже настроенных рассылках. При этом прекращение работы Dynamic Links не означает закрытие всего Firebase.

Полезно вести перечень важных ссылок и владельцев доменов. Адрес на вашем домене обычно оставляет больше возможностей для переноса, чем чужой короткий домен. Но и здесь нельзя обещать восстановление всех старых функций или потерянных данных. Сначала выясните, чем вы действительно управляете.

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

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

Обсуждая задачу с Appfyl, покажите реальные письма и сообщения, которые собираетесь отправлять. По ним проще понять необходимый объём работы. В итоге человеку не нужно знать слово «диплинк»: он должен открыть приглашение и оказаться там, куда его позвали.

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