Ссылка на товар открыла приложение: проверьте экран, точку и запасной путь
Менеджер отправил карточку товара, а телефон показал главную приложения. Другой покупатель остался в браузере. Эти результаты требуют разных проверок. Разберём, как согласовать один клиентский маршрут и доказать, что ссылка ведёт к нужному товару в нужной точке.
Сначала запишите обещание ссылки
Перед печатью QR-кода или отправкой ссылки менеджером зафиксируйте конечный результат. Покупатель должен увидеть определённый товар, вариант и точку получения. Вход через приложение или сайт может различаться, но смысл предложения должен оставаться проверяемым. Один адрес без описанного назначения ещё не является готовым клиентским маршрутом.
Для проверки возьмём вымышленный магазин с двумя точками. Ссылка относится к синей термокружке T-480 в точке «Вокзал». На телефоне проверяющего ранее выбрана точка «Центр». Именно это несовпадение делает тест полезным: на устройстве с уже совпадающими настройками потеря филиала может остаться незаметной.
Согласуйте, что победит при конфликте: контекст ссылки или сохранённый выбор клиента. Допустим и явный вопрос о точке. Недопустим для этой приёмки молчаливый результат, который команда не может объяснить. Открытие адреса в учебном сценарии ничего не покупает и не резервирует.
Проверьте два разных перехода
Синий вариант
Точка «Вокзал»
Учебная модель приёмки. Способ открытия и конечное назначение фиксируются раздельно.
Android App Links проверяет связь домена с приложением через файл Digital Asset Links на сайте. Документация различает подтверждённую связь и выбор обработчика самим пользователем. Поэтому запись «домен проверен» и поведение конкретного телефона требуют отдельных наблюдений. Android: проверка App Links.
Apple требует обработать полученный URL в приложении и показать соответствующее содержимое. Например, адрес товара должен привести к его карточке. Apple: переход к нужному содержимому.
В протоколе разделите открытую программу и конечный экран. Главная вместо карточки означает: запуск состоялся, но наша цель не достигнута.
Ожидание зависит от места нажатия
Для Universal Links Apple предусматривает обычный веб-адрес, который может вести в приложение; без установленного приложения адрес открывается в браузере по умолчанию. Это позволяет сохранить веб-путь к содержимому. Наличие такого пути ещё нужно проверить на конкретном сайте. Apple: связь приложения и сайта.
Apple также объясняет два важных случая: переход внутри того же домена в Safari остаётся в браузере; ввод URL прямо в адресную строку не запускает приложение. Поддержка Universal Links у сторонних браузеров может отличаться. Эти действия нельзя смешивать с нажатием ссылки из другого приложения. Apple TN3155: проверка Universal Links.
Опишите вход до запуска теста: например, «сообщение в согласованном приложении», «переход внутри каталога» или «сканирование конкретным средством камеры». Проверка только копированием адреса в строку браузера не воспроизводит обещанный рекламный путь. Если результат для данного способа входа ещё не согласован, отметьте его как неопределённый, а не как успешный.
Учебная матрица: один товар, разные условия
Используйте одну и ту же карточку T-480 и заранее записанный конфликт точек. Ниже — проект тестов, а не результаты проверки действующего приложения. Для каждой строки сохраните время, версии системы, приложения и браузера, точный способ открытия и снимок конечного экрана без данных покупателей.
| Условие | Что проверяем | Что считается расхождением |
|---|---|---|
| Текущая версия приложения; внешний вход | Согласованный обработчик и карточка T-480 | Главная вместо карточки |
| На устройстве выбрана точка «Центр» | Согласованное разрешение конфликта с «Вокзалом» | Молчаливая подмена точки |
| Пользователь вышел из аккаунта | После входа назначение сохранено либо предложено явно | Контекст потерян без объяснения |
| Вариант товара недоступен | Понятное ограничение и следующий выбор | Другой вариант выдан за исходный |
Отдельные строки для iPhone: без приложения проверьте веб-страницу; при переходе по тому же домену в Safari допустим браузерный результат. В обоих случаях сверяйте конечную карточку, а не только название открытой программы.
Не пытайтесь охватить все телефоны одним словом «мобильный». Сначала выберите поддерживаемые сочетания и важные входы бизнеса. Если QR-код пойдёт на упаковку, проверка его фактическим считывателем важнее ещё одного одинакового нажатия менеджером в тестовом чате.
Сохраните назначение при входе и изменении доступности
Проверка авторизации нужна там, где действие действительно требует входа. Не добавляйте обязательную регистрацию только ради теста. Сначала откройте публичный товар, затем выполните разрешённый тестовый переход к закрытому действию и убедитесь, что команда может объяснить возвращение к выбранному назначению.
Если предлагается установить приложение, не предполагайте автоматическое продолжение после установки. Запишите это как отдельный сценарий и попросите показать его на чистом тестовом устройстве. До подтверждения не обещайте покупателю, что установка сама восстановит выбранный товар или предложение.
Изменившаяся доступность не должна скрываться сохранённым адресом. В нашем примере синяя кружка может закончиться только на «Вокзале». Хороший согласованный результат сообщает об ограничении и предлагает новый выбор. Переключение на другую точку, цвет или способ получения требует понятного решения клиента.
Не проверяйте обновление только свежей установкой
По текущей документации Android изменения файла связи домена на Android 15 и новее могут распространяться до семи дней через повторные фоновые проверки. На Android 14 и старше обновление обычно подхватывается при установке или обновлении приложения. Это разные условия проверки изменения. Android: проверка App Links.
Поэтому в приёмочном наборе полезны два состояния: чистая установка и поддерживаемое приложение, которым пользовались до изменения ссылки. Запишите дату изменения, версию сборки и наблюдаемый результат каждого состояния. Успех первого не переносите на второй без теста.
Если старая версия не поддерживает новое назначение, согласуйте понятный доступный путь и срок поддержки. Текст для клиента должен соответствовать показанному поведению. Сотрудник поддержки должен различать неподдерживаемую версию, потерянный контекст и ошибку доступности товара: у этих случаев разные следующие действия.
Примите маршрут по результатам, которые можно повторить
Назначьте владельца самой ссылки и владельца её обработки. Первый отвечает за правильный адрес в каталоге, сообщении и печатном материале; второй подтверждает проверенные сочетания устройств и версий. Сохраните контрольный адрес, ожидаемый экран и ограничения вместе с материалом кампании.
- Для каждого входа определён ожидаемый результат.
- Товар, вариант и точка сверены отдельно от факта открытия.
- Конфликт с прежним выбором клиента воспроизведён.
- Вход в аккаунт и недоступный товар проверены на искусственных данных.
- Неизвестные и неподдерживаемые сочетания обозначены явно.
- После изменения адреса или обработки повторяется затронутая часть матрицы.
При обсуждении клиентского приложения SABSUS используйте эту матрицу как вопрос к конкретной конфигурации: «Покажите выбранный вход и конечный экран на поддерживаемом устройстве». Материал не подтверждает наличие определённой реализации App Links или Universal Links в вашем проекте. Согласованный протокол важнее общего ответа «ссылки работают».
Источники и продолжение
Первоисточники проверены 17 октября 2026 года. Магазин, товар и матрица являются учебным редакционным примером. Рабочее приложение клиента не тестировалось.