Deep link vs universal link и app link: различия и настройки без потери кликов

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

Главное отличие deep link vs universal link простое: deep link является общим понятием для ссылок на конкретный экран приложения. Universal Link реализует этот принцип в iOS через домен и файл apple-app-site-association, а App Link в Android через assetlinks.json. Для digital-агентства эта разница не теоретическая. От нее зависит, откроется ли TikTok, маркетплейс или клиентский продукт сразу на нужном экране.

Когда ссылка ломается, маркетолог часто видит только симптом: клик был, приложение не открылось, конверсия снизилась. Техническая причина может быть в AASA-файле, Digital Asset Links, manifest, настройках пользователя, редиректе или сессии конкретного аккаунта. Поэтому проверка должна проводиться не только со стороны разработчика, но и со стороны человека, который запускает кампании на разных платформах.

Для мобильного маркетинга также важно тестирование. Если один менеджер проверяет рекламу для нескольких брендов в одном браузере, cookies, авторизация, гео и предыдущие переходы смешиваются. Во время тестирования мобильных кампаний это особенно проблематично: один и тот же URL может открыть разный экран для нового пользователя, авторизованного пользователя, тестового аккаунта или аккаунта Apple Developer с другой конфигурацией.

Что такое deep link, universal link и app link и в чем принципиальная разница

Deep link является общим термином для ссылки, которая ведет не просто в приложение, а в конкретное место внутри него. Universal link и app link являются проверенными веб-ссылками для iOS и Android, которые связывают домен с конкретным приложением.

Классический deep link часто использует пользовательскую URL-схему (custom scheme) наподобие myapp://product/123. Он может быстро открыть приложение, но у него есть слабое место: если приложение не установлено, система не всегда знает, куда корректно направить пользователя. Universal Links и Android App Links работают иначе. Это обычные HTTPS-ссылки с резервным веб-маршрутом: если приложения нет или домен не подтвержден, пользователь видит веб-страницу.

Ссылка https://example.com/product/123 может одновременно быть страницей сайта, Universal Link для iOS и App Link для Android. ОС проверяет домен и либо открывает экран товара в приложении, либо оставляет пользователя в браузере.

Как настроить Universal Links на iOS через apple-app-site-association

Universal Links на iOS работают через двустороннее доверие между доменом и приложением. На сайте должен быть файл apple-app-site-association, а в приложении должен быть entitlement Associated Domains с доменом в формате applinks:example.com.

Файл AASA размещают в корне домена или в /.well-known/apple-app-site-association. К нему не добавляют расширение .json. Для продакшена нужны HTTPS, корректный JSON и совпадение домена с тем, который прописан в приложении. Если рекламная кампания ведет на go.example.com, а entitlement указывает только example.com, Universal Link для этого субдомена не сработает.

Базовый порядок настройки такой:

1. подготовьте список доменов и субдоменов, которые реально используются в рекламе, email и ссылках в био
2. создайте файл apple-app-site-association с Team ID, Bundle ID и правилами путей
3. разместите файл в /.well-known/ или в корне каждого домена без расширения
4. включите Associated Domains для App ID в Apple Developer
5. добавьте в Xcode capability Associated Domains и значение applinks:домен
6. проверьте открытие на физическом iPhone после установки или обновления приложения

В техническом чеклисте проверяйте HTTP-статус, отсутствие редиректов, тип контента, валидность JSON, точный идентификатор приложения и список путей. Если CDN или WAF отдает краулеру Apple HTML-страницу ошибки вместо JSON, Universal Link не сработает, даже когда файл открывается в Вашем браузере.

На схеме показаны два файла привязки домена и идентификаторы приложения, которые проверяет каждая платформа.

Как настроить App Links на Android через assetlinks.json

Android App Links работают через Digital Asset Links. Домен публикует assetlinks.json, а приложение в манифесте заявляет intent filter с android:autoVerify="true" для HTTPS-ссылок.

Файл должен находиться по адресу https://домен/.well-known/assetlinks.json. Для каждого хоста и субдомена нужна собственная доступная конфигурация. В JSON указывают relation delegate_permission/common.handle_all_urls, название пакета приложения и SHA-256-отпечаток сертификата. Если в кампании есть www.example.com и m.example.com, Android проверяет их как разные хосты.

Порядок настройки App Links:

1. добавьте intent filter для VIEW, BROWSABLE, DEFAULT, https и нужного хоста
2. включите android:autoVerify="true" в фильтре, который должен проходить проверку
3. сгенерируйте SHA-256-отпечаток для релизного сертификата, а не только debug-сборки
4. создайте assetlinks.json с названием пакета и отпечатком сертификата
5. разместите файл в /.well-known/assetlinks.json на каждом хосте
6. установите или обновите приложение на тестовом устройстве
7. проверьте статус через adb shell pm get-app-links PACKAGE_NAME

Обычный Android deep link может открыть приложение, но система иногда показывает диалог выбора. App Link после подтверждения домена определяет для Android, какое приложение должно обрабатывать URL.

Почему ссылки в соцсетях открываются в браузере вместо приложения

Ссылка открывается в браузере, когда ОС не смогла подтвердить связь между доменом и приложением или когда in-app browser соцсети перехватил маршрут. Это не одна ошибка, а несколько уровней проверки.

Начнем с домена. Universal Links и App Links привязаны именно к host. Если рекламный трекер добавляет redirect через другой домен, а верификация есть только на финальном домене, часть кликов пойдет через браузер.

Второй уровень проверки касается файлов верификации. Для iOS проверяйте apple-app-site-association, для Android assetlinks.json. Ошибки банальные: 404, 403 для краулера, HTML вместо JSON, неправильный отпечаток сертификата, устаревший Bundle ID, другое название пакета или ситуация, когда вместо verification-файла сервер или CDN возвращает HTML-страницу, например из-за cookie banner.

Третий уровень проверки касается среды открытия. Instagram, TikTok, Facebook, LinkedIn и мессенджеры часто открывают URL в собственном встроенном браузере. Там поведение может отличаться от Safari, Chrome или системного открытия из Notes. Для TikTok Business Center это особенно заметно: креатив может вести на один и тот же URL, но тест из приложения TikTok и тест из чистого Chrome дадут разные результаты.

Отдельно проверяйте состояние пользователя. Если приложение уже установлено, но человек вручную отключил "Open supported links" на Android, система может вести в браузер.

Что выбрать для iOS и Android: deep link, universal link или app link

Для современных мобильных кампаний базовым выбором являются Universal Links для iOS и App Links для Android. Custom scheme можно оставить как вспомогательный маршрут, но не как основную инфраструктуру платного трафика.

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

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

Как самостоятельно диагностировать проблему со ссылкой

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

Для iOS откройте https://домен/.well-known/apple-app-site-association и https://домен/apple-app-site-association. Проверьте, что ответ не содержит HTML, редиректов и ошибки доступа. Затем сверьте Team ID, Bundle ID и пути.

Для Android работайте через adb. Перед тестом желательно иметь физическое устройство или эмулятор с установленной релизной или близкой к релизной сборкой.

1. откройте https://домен/.well-known/assetlinks.json в браузере
2. проверьте package_name и sha256_cert_fingerprints
3. сбросьте состояние app links командой adb shell pm set-app-links --package PACKAGE_NAME 0 all
4. запустите повторную верификацию adb shell pm verify-app-links --re-verify PACKAGE_NAME
5. подождите несколько минут, чтобы агент проверки завершил запросы
6. проверьте статус adb shell pm get-app-links PACKAGE_NAME
7. запустите тестовый URL через adb shell am start -a android.intent.action.VIEW -c android.intent.category.BROWSABLE -d "https://домен/path"

На Android 15 и более новых версиях изменения в assetlinks.json могут распространяться не мгновенно из-за кеша и фоновой проверки доменов. Отдельно тестируйте рекламный URL с UTM, click ID и коротким доменом, потому что "чистая" финальная страница не всегда повторяет реальный путь клика.

Экран диагностики показывает этапы проверки, которые помогают найти сбой маршрутизации Android App Links.

Как тестировать ссылки на нескольких аккаунтах и гео без смешивания сессий

Тестирование deep link на одном устройстве или в одном браузере быстро смешивает сессии. Для SMM и growth-команд это проблема, потому что разные аккаунты, страны, cookies, язык системы и IP могут менять маршрут после клика.

Типичный сценарий: агентство ведет три бренда с разными кабинетами TikTok Ads или Meta Ads. В одной браузерной среде быстро накапливаются cookies, предыдущие логины, локаль и кеш редиректов.

Рабочий подход такой:

1. выделите отдельный тестовый профиль под каждый бренд, аккаунт или гео
2. закрепите за профилем стабильный IP через резидентный прокси, если проверяете региональное поведение
3. храните отдельные cookies и логины для каждой платформы
4. фиксируйте полный URL клика, финальный URL и результат открытия
5. повторяйте тест в системном браузере, встроенном браузере соцсети и на устройстве с чистым состоянием приложения
6. разделяйте проверку сценария установки, первого запуска и повторного открытия для авторизованного пользователя

Afina уместно использовать именно на этом этапе: каждый тестовый аккаунт или гео может работать в отдельном изолированном профиле с отдельными cookies, browser fingerprint и настройками прокси. Это помогает не смешивать сессии, когда команда проверяет ссылки для нескольких клиентов, рекламных кабинетов или регионов. Для связки браузерного профиля с реальным мобильным тестом полезен подход с разделением браузера и телефона: в браузере проверяется веб-часть, а на телефоне системное открытие приложения.

Afina не заменяет AASA, assetlinks.json или mobile SDK. Она закрывает другой слой проблемы: чистоту среды, стабильность сессий и контроль гео во время проверки. В результате у команды есть URL, аккаунт, гео, время теста и воспроизводимый результат.

Скачать