Диплинк (Deep link)

3 июня 2026 · ~13 мин чтения

концепция веб mobile маркетинг атрибуция telegram

Диплинк (Deep link)

Диплинк (deep link, «глубокая ссылка») — это URL, который ведёт не на главную страницу сайта или приложения, а на конкретный экран, объект или действие внутри, и часто несёт с собой полезную нагрузку (slug, параметр, идентификатор кампании). В вебе это привычная ссылка вида site.com/products/42, в мобильных и мессенджерах — отдельная техника, потому что приложение надо ещё уметь открыть из браузера и передать ему параметр.

История

Сама идея «глубокой ссылки» родилась вместе с вебом. В 1989–1991 годах Тим Бернерс-Ли описал URL как универсальный способ адресовать любой ресурс — не только сайт, но и конкретный документ. Когда в середине 1990-х начался коммерческий веб, выяснилось, что владельцы сайтов хотят, чтобы посетители приходили на главную (увидеть рекламу, баннер, фирменный стиль), а не сразу на внутреннюю страницу. Так появился сам термин deep linking — как противопоставление «нормальным» ссылкам на homepage.

Вехи развития:

Что это такое

Диплинк — это адресная ссылка с навигационным намерением. В отличие от «зайди на главную и сам найди», диплинк говорит: «открой именно вот этот товар / именно этот чат / именно эту настройку и передай в него вот эти данные».

Технически диплинк может быть трёх типов:

  1. Веб-диплинк — обычный URL: shop.com/product/42?ref=email-promo. Открывается в браузере, всё стандартно.
  2. Кастомная URL-схема (custom scheme): instagram://user?username=durov, tg://resolve?domain=durov. Это «псевдо-протокол», который умеют ловить только установленные приложения. Если приложения нет, браузер просто ругается «не могу открыть».
  3. Универсальный диплинк (Universal Link / App Link / https-deeplink): https://t.me/durov, https://instagram.com/durov. Выглядит как обычная веб-ссылка, но операционная система при клике распознаёт «о, это домен, привязанный к установленному приложению» и открывает приложение, не браузер. Если приложения нет — открывается веб-страница по тому же URL и работает как fallback.

Отдельная подкатегория — диплинк внутри мессенджера. t.me/<bot>?start=<payload> открывает чат с ботом и передаёт ему payload (бот видит его в первом сообщении /start <payload>). t.me/<bot>?startapp=<payload> открывает Mini App и передаёт ему payload в Telegram.WebApp.initDataUnsafe.start_param. Это маркетинговый интерфейс «дай ботам понять, откуда пришёл пользователь и с какой кампании».

Диплинк vs обычная ссылка. Любой URL — это формально диплинк, если он указывает не на корень. Но в обиходе «диплинк» — это ссылка, которая дополнительно умеет: (а) открывать мобильное приложение или мини-апп, (б) нести в себе бизнес-payload (slug, кампанию, реферала, отложенный action), (в) работать в условиях «приложения нет — открой веб-альтернативу».

Диплинк vs deeplink-короткая-ссылка. Сервисы типа Branch, AppsFlyer, bit.ly выдают «короткие диплинки» — app.link/abc123. Это редирект, который на сервере сначала смотрит user-agent (iOS, Android, desktop), решает куда вести, и только потом отправляет реальный диплинк. Это удобно для аналитики и кросс-платформенной логики, но кликать всё равно надо на короткую ссылку.

Аналогии из жизни

Аналогия 1: адрес квартиры vs адрес подъезда. Обычная ссылка на главную — это «дом 15». Чтобы найти конкретного человека, ты звонишь в домофон и спрашиваешь. Диплинк — это полный адрес «дом 15, подъезд 3, квартира 47, спроси Машу». Доставщик еды сразу едет туда, куда нужно, не теряя время в подъездах.

Где ломается: если у дома 15 нет третьего подъезда (страницы по slug не существует — 404), доставщик упирается в стену и не может «сообразить, что имелось в виду». Поэтому грамотный диплинк-роутер на сервере должен фолбэчить на главную с понятным сообщением, а не падать молча. Ещё: если адрес ввёл недоброжелатель (кто-то прислал ссылку на чужой кабинет), нужны проверки прав доступа на стороне сервера — диплинк сам по себе ничего не авторизует.

Аналогия 2: пригласительный билет на закрытый концерт. На билете напечатано «концерт такого-то, 20 ноября, ряд 5 место 7, держатель — Иван». Это один объект, который и приводит в нужное место, и подтверждает контекст («ты — Иван», «у тебя место 5/7»). Диплинк с payload работает так же: ссылка ведёт на нужный экран и одновременно несёт информацию «ты пришёл по такой-то рекламе, по такому-то приглашению».

Где ломается: билет можно сфотографировать и переслать другу. Если охрана не сверяет паспорт, на концерт пройдёт кто угодно. Точно так же диплинк с реферальным payload — это всего лишь подсказка, не доказательство. Никогда не доверяй параметру из URL для авторизации: пользователь может отредактировать ссылку в один клик. Диплинк указывает «куда идти», но «кто ты» должна сказать сессия и токен, а не сам URL.

Аналогия 3: радиосигнал «найти такси» с координатами. Когда вызываешь такси через приложение, оно отправляет водителю не «приезжай в город», а пакет «адрес посадки X, координаты Y, имя клиента Z, тариф T». Водитель за один взмах оказывается у нужного подъезда. Диплинк — такой же пакет «куда+с-чем», только для приложений и сайтов.

Где ломается: координаты могут устареть (клиент перешёл в другое место), пакет может потеряться (плохая связь), таксист может не уметь читать твой формат (старая версия приложения, не понимающая новый параметр). Поэтому в диплинках важна версионируемость: если ввёл новый параметр в payload — старые версии клиента должны его проигнорировать, а не упасть.

Как это работает

Жизненный цикл диплинка можно разложить на четыре этапа: сборка → распространение → обработка платформой → парсинг приложением.

Этап 1. Сборка.

Маркетолог или система генерирует URL вида:

https://t.me/newbuildmimo_bot?startapp=b_72651e87--s_yandex_tg--m_cpc--c_brandbot-search--y_{yclid}

Здесь:
- t.me/newbuildmimo_bot — адрес мессенджера и идентификатор бота;
- startapp= — параметр, который Telegram передаст внутрь Mini App;
- b_72651e87 — slug проекта (идентификатор «куда вести»);
- --s_yandex_tg, --m_cpc, --c_brandbot-search — UTM-хвост в собственном формате с разделителем -- (вместо классических &utm_source=);
- {yclid} — макрос Яндекс.Директа, который сам подставит ID клика.

Формат -- — это договорённость команды: в Telegram бот-startapp нельзя передать символ &, иначе ссылка обрежется. Поэтому всю атрибуцию упаковывают в один параметр через свой разделитель и парсят на стороне приложения.

Этап 2. Распространение.

Ссылку расклеивают по каналам: рекламные креативы в Яндекс.Директе, посты в каналах, push-уведомления, баннеры на сайтах-партнёрах, QR-коды в офлайн-материалах. У каждого канала — свой источник в UTM-хвосте.

Этап 3. Обработка платформой.

Пользователь кликает. Дальше — самое интересное место, где всё может сломаться.

Этап 4. Парсинг приложением.

Приложение получило URL целиком. Дальше — его задача распарсить и сделать правильное действие. В мини-аппе на JS это выглядит примерно так:

const tg = window.Telegram.WebApp;
const raw = tg.initDataUnsafe.start_param || '';
const segments = raw.split('--');
const slug = segments[0];           // b_72651e87
const attribution = {};
for (const seg of segments.slice(1)) {
  const [key, ...rest] = seg.split('_');
  attribution[key] = rest.join('_');
}
// дальше — открыть экран проекта slug и записать визит с attribution

Полезные практики:

  1. Slug всегда первый сегмент. Тогда если кто-то добавит сегмент --preview или новый макрос, парсер старого приложения всё равно правильно поймёт основной идентификатор.
  2. Игнорировать неизвестные сегменты. Это та самая «версионируемость» из аналогии с такси.
  3. Никогда не доверять payload для авторизации. Slug проекта — нормально, токен сессии — никогда.
  4. Логировать отсутствие параметра. Если кто-то открыл мини-апп напрямую (без диплинка), это валидный сценарий, но в маркетинговой воронке такой визит часто помечают «без UTM» и отделяют от рекламного трафика.

Не парси UTM из URL после редиректа

Если твой сервер делает редирект 301 my-deeplink → app://product/42, в финальный URL может не попасть весь хвост. Сохраняй UTM на стороне редиректа в куку или серверный лог, не надейся, что они «доедут» сами.

Где встречается в обычной жизни

Где встречается в IT и бизнесе

Кто пользуется

Альтернативы и конкуренты

Когда НЕ стоит использовать

Связанные понятия

Литература и источники

Где встретилось у меня

Вчера разбирался с диплинками для брендботов: ссылки https://t.me/<bot>?startapp=<slug>--s_yandex_tg--m_cpc--... идут из Яндекс.Директа в Mini App, парсер на JS вытаскивает slug и UTM-хвост, мини-апп шлёт визит с атрибуцией в сервер, оттуда — в колл-центр. Отдельная история — превью-режим: добавили хвост-сегмент --preview, чтобы технические заходы не падали в «без UTM» и не засчитывались как реальный визит.

Краткое резюме