Deep link в приложении: как довести человека до действия

Deep link в мобильном приложении: вход, права, установка и запасной веб-путь. Как проверить маршруты, полезное действие и ошибки перехода.

Автор: Александр Поркулевич, CEO и основатель, 404gen.

Вы оплатили дорогу. Клиент приехал в прихожую

Условный покупатель получает уведомление: заказ готов к выдаче. Нажимает, ожидая адрес и код. Приложение открывается на главной. Там акция, персональные рекомендации, ещё одна акция и предложение включить уведомления, которые уже включены. Заказ где-то существует. Покупателю предлагают поискать. Компания потратила деньги на сообщение, а полезный путь закончился у коврика «Добро пожаловать».

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

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

Обычная ссылка, схема и подтверждённый домен

Обычная HTTPS-ссылка открывает веб-ресурс. Пользовательская схема вроде условного myservice:// может направлять в приложение, но её поведение и конкуренцию обработчиков надо учитывать отдельно. Подтверждённые ссылки связывают ваш домен с вашим приложением средствами операционной системы. Это позволяет использовать один понятный адрес для веба и приложения, когда конфигурация и состояние устройства допускают такой переход.

Документация Android о deep links различает типы ссылок и механизм App Links. На стороне Apple associated domains связывают приложение и домен для поддерживаемых сценариев. Эти механизмы не означают, что любой URL автоматически откроет любой нужный экран. Продукт всё равно должен распознать маршрут, проверить контекст и показать подходящее состояние.

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

Сначала проектируют адреса, потом красивое открытие

Маршрут должен иметь устойчивый смысл. Например, /orders/123 ведёт к заказу с конкретным идентификатором, а /products/456 — к товару. Это условные адреса. Не стоит строить ссылку на порядковый номер элемента в текущем списке: после сортировки она может вести к другому объекту. Идентификатор и право доступа проверяются сервером. Красивый экран не спасёт ситуацию, когда пользователь попал в соседнюю карточку.

Параметры отделяют от бизнес-действий. Источник перехода, вкладка и язык могут влиять на показ, но сама ссылка не должна без дополнительной проверки оплачивать, отменять или подтверждать операцию. Человек мог переслать URL, браузер мог предварительно загрузить страницу, робот мог проверить адрес. Переход и значимое действие — разные события. Кнопка подтверждения существует не для красоты интерфейса, а для ясного выражения намерения.

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

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

Авторизация не должна съедать намерение

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

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

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

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

Приложения нет: куда ведёт ссылка

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

Deferred deep linking — отдельная задача: восстановить направление после установки приложения. Она зависит от платформы, выбранной реализации и доступных механизмов передачи контекста. Обычная подтверждённая ссылка сама по себе не делает этот путь готовым. В коммерческом описании следует различать «открыть объект в установленном приложении» и «пройти установку и продолжить». Иначе важная функция будет существовать только в предложении подрядчика.

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

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

Ссылка на объект — ещё не право увидеть объект

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

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

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

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

Товар исчез, запись перенесена, документ удалён

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

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

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

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

Подтверждение домена: проверять нужно реальную сборку

Связь сайта и приложения включает конфигурацию на обеих сторонах. На Android важны настройки обработки ссылок и подтверждение домена; для iOS — связанные домены и соответствующее представление на сервере. Документы платформ задают конкретные требования, которые меняются, поэтому техническая команда сверяется с актуальной документацией. Бизнес-приёмка должна включать результат на устройстве, а не только наличие файлов в репозитории.

Android описывает проверку App Links и способы диагностики. Практический вывод: адрес может открываться в браузере из-за состояния подтверждения, а не из-за ошибки экрана приложения. Нужны тесты домена, пути и установленной сборки. Подпись и окружение разработки не всегда совпадают с опубликованной версией, поэтому успешный локальный запуск не завершает проверку.

Учтите дополнительные домены, поддомены и перенаправления. Маркетинг может использовать короткую ссылку, рассылочный сервис — свой адрес отслеживания, а приложение — только основной домен. В результате прямой URL работает, но ссылка из реального письма ведёт иначе. Проверяйте именно тот адрес, который получит пользователь, включая промежуточные переходы. Тест по внутренней кнопке разработчика не заменяет сценарий из мессенджера или камеры.

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

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

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

Учебный пример: 1 000 человек получили сообщение, 200 нажали ссылку, 150 увидели нужный экран, 90 выполнили целевое действие. Это условные числа. По ним видно, что между нажатием и экраном потерялось 50 переходов. Причину ещё нужно установить: установка, вход, ошибка маршрута или неактуальный объект. Нельзя сразу обвинять текст сообщения или объявлять проблему решённой новой кнопкой.

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

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

Матрица приёмки: один телефон не считается вселенной

В тестах нужны разные состояния: приложение установлено и отсутствует, сессия активна и истекла, объект доступен и запрещён, сеть работает и пропала. Проверяют холодный запуск и приложение в фоне, старую поддерживаемую версию и новую сборку. Дополнительно — входящие источники: браузер, письмо, мессенджер, push, QR-код. Полный декартов набор не всегда нужен, но критические сочетания должны быть определены по реальным сценариям аудитории.

Каждый тест завершается проверяемым результатом. Не «приложение открылось», а «после входа виден заказ 123 текущего пользователя; чужие данные недоступны; кнопка показывает актуальное состояние». Для неустановленного приложения — полезная веб-страница или ясно объяснённый обязательный шаг. Для исчезнувшего объекта — корректное сообщение и допустимый выход. Чем конкретнее ожидание, тем меньше пространства для торжественного отчёта о наполовину рабочей функции.

Автоматические проверки маршрутов дополняют устройства, но не заменяют их полностью. Можно проверить серверные ответы, отсутствие открытого перенаправления и доступ к объектам. Реальное поведение системы обработки ссылок зависит также от платформы и установленной версии. Поэтому перед публикацией критических рассылок полезен короткий прогон настоящего сообщения на выбранных устройствах. Цена такого теста обычно понятнее цены кампании, ведущей в никуда.

Поддержка должна понимать, где сломался путь

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

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

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

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

Когда глубокие ссылки оправданы и что входит в работу

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

В оценку разработки входят маршруты, подтверждение доменов, серверные проверки, восстановление после входа, запасные состояния, измерение и приёмка. Подключение SDK — лишь часть возможной реализации. Для конкретного проекта разработка мобильного приложения должна учитывать эти пути вместе с остальной навигацией. Изолированная задача «добавить deep links» без списка объектов часто рождает готовый механизм без законченного пользовательского сценария.

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

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

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

Deep link и App Link — одно и то же?

Deep link обозначает переход к конкретному месту приложения. App Links — механизм Android для подтверждённых связей с веб-доменом. У iOS есть Universal Links. Выбор механизма не заменяет проектирование маршрута, прав и запасных состояний.

Ссылка сама вернёт пользователя после установки?

Не обязательно. Возврат после установки — отдельный сценарий deferred deep linking, зависящий от платформы и реализации. Его нужно проверить отдельно; обычная ссылка в установленное приложение не подтверждает готовность такого пути.

Что измерять кроме нажатий?

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