Відкриття в застосунку
App Routing віддає відвідувача нативному застосунку замість вебверсії. Каталог платформи, три стани click id і чому на Android покриття ширше, ніж на iOS.
Коли призначення веде у мобільний застосунок — бот у Telegram, профіль в Instagram, трек у Spotify — відвідувача можна віддати самому застосунку, а не його вебсторінці. Це найбільше важить для трафіку з in-app браузерів Meta: там вебверсія відкривається всередині чужого WebView, де немає ні пушів, ні встановлення.
Функція вимкнена, поки її явно не увімкнути на конкретному спліті. Нічого не змінюється для трафіку, якого ви не чіпали.
App Routing не замінює ні клоакінг, ні фільтри, ні трек-посилання. Він змінює рівно одне — куди веде останній крок.
Де це вмикається
Контрол зʼявляється в редакторі спліту тільки тоді, коли URL призначення розпізнано за доменом. Нерозпізнаний URL не показує нічого — не порожню форму «оберіть застосунок», а саме нічого.
- Відкрийте потік → Трек-посилання → спліт із URL призначення.
- Якщо домен розпізнано, зʼявиться тумблер Відкрити в <застосунок>.
- Оберіть, що робити, коли застосунку немає: вебсторінка або сторінка стору.
Що показує редактор
Увімкнувши, ви бачите чотири рядки. Кожен береться з каталогу, жоден не вгаданий.
| Рядок | Про що |
|---|---|
| Охоплення платформ | чи відкриється застосунок на Android, на iOS, чи лише на одній із них |
| Доля click id | доходить / не доходить / невідомо |
| Сертифікація | на яких парах «застосунок-джерело × ОС» це перевірено на живому пристрої |
| Фолбек | що станеться, якщо застосунок не встановлено |
Три стани click id
Це не «так або ні». Станів три, і два з них не «ні».
| Стан | Що означає |
|---|---|
| Доходить | вендор задокументував механізм, яким payload потрапляє на бекенд призначення |
| Не доходить | вендор або прямо це каже, або його повний опублікований перелік API такого шляху не містить |
| Невідомо | ми не знайшли ні механізму, ні доказу його відсутності |
«Не доходить» — це відповідь, а не прогалина. Плутати її з «невідомо» не можна: перше означає, що конверсії з цього переходу не звʼяжуться автоматично, і рішення ваше з відкритими очима.
Форми посилань, які несуть click id
https://t.me/<бот>?start=<payload> payload у /start, до 64 символів
https://m.me/<сторінка>?ref=<payload> доходить у вебхук сторінки
https://ig.me/m/<юзер>?ref=<payload> те саме для InstagramОбидві форми Meta умовні, і умови різні. m.me вимагає, щоб відвідувач натиснув кнопку в чаті, і сама Meta не гарантує доставку. ig.me додатково вимагає налаштованих Icebreakers і опублікованого акаунта.
Коли каталог знає, що форма посилання вміє нести click id, редактор пропонує вставити його одним тапом. Пропозиція звужена до правильної родини посилань: ?ref= пропонується на ig.me/m/<юзер> і не пропонується на instagram.com/<юзер>, бо там цей параметр не робить нічого.
Чому на Android покриття ширше
Android потребує лише назви пакета: збережений https-URL віддається застосунку як є. Тому Android-шлях покриває весь каталог одразу.
iOS потребує власної схеми і правила перетворення URL під конкретний тип посилання. Таких правил існує небагато — і часто не через брак наших зусиль: багато вендорів свідомо прибрали кастомні схеми на користь Universal Links. LINE депрекейтнув line:// власною документацією заради захисту від takeover-атак. Pinterest у хелпі пише, що шаблонів третім сторонам не публікує. X офіційно схем не підтримує.
Для таких застосунків правильна відповідь — відсутність правила, а iOS-шлях чесно вироджується у вебсторінку. Рядок охоплення в редакторі каже про це прямо.
Оголошена iOS-схема сама по собі маршруту не дає. Потрібне правило перетворення URL для конкретної форми посилання — без нього кожен відвідувач з iOS піде на вебсторінку.
Налаштування на Direct Link
В основних налаштуваннях Direct Link є вибір: пробувати відкрити застосунок або завжди вести в браузер. Другий варіант вирішується на сервері — рантайм не отримує конфігурацію маршруту взагалі.
Вибору довільного застосунку тут немає навмисно. Застосунок виводиться з URL призначення, який живе на спліті, а один Direct Link дістається кільком потокам із різними призначеннями — єдиної правильної відповіді там не існує.
Каталог застосунків
Список застосунків — платформний, редагується тільки суперадміном. Назви пакетів і URL-схеми це факти про платформу, а не налаштування воркспейсу; довільний ввід тут був би діркою прямо крізь перевірку призначень.
Одиниця каталогу — пара застосунок × тип посилання, не застосунок. https://t.me/<бот>?start=<id> і https://t.me/<канал> — той самий застосунок і протилежні відповіді на кожне питання, яке система задає.
Межі, про які варто знати
- Застосунок може віддати відвідувача назад. Перехід спрацьовує, застосунок отримує посилання — і сам вирішує повернути людину у веб. Розлогінений застосунок робить це регулярно. Це поза нашим контролем.
- Каталог не дорівнює покриттю. Запис у каталозі означає, що факти про пакет і схему правдоподібні, а не що перехід перевірений на пристрої. Колонка сертифікації — єдине, що це доводить.
- Фолбек «стор» доступний не всюди. Якщо для застосунку не налаштована сторінка стору на потрібній платформі, використовується вебсторінка. Редактор показує це до збереження.