Deep link, 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, акаунт, гео, час тесту і відтворюваний результат.

Скачати