Диплинки в Google Ads 2026: Web to App Connect без потерь

Пользователь кликает по вашему поисковому объявлению с телефона. У него уже установлено ваше приложение — он там залогинен, у него сохранена карта и адрес доставки. Но попадает он на мобильный сайт, где нужно заново вводить всё с нуля. Этот разрыв стоит вам конверсий каждый день, и он чинится настройкой, а не бюджетом: диплинки в Google Ads закрывают этот разрыв на уровне операционной системы.

Разбираем, как работают диплинки в Google Ads и механика Web to App Connect: что требуется от разработчика, какие типы ссылок поддерживаются, почему редиректы третьих сторон не принимаются, где ломается измерение и как оценить потенциал до того, как ставить задачу в спринт.

Что такое Web to App Connect и зачем это считать

Web to App Connect — набор возможностей Google Ads, который направляет трафик веб-кампаний (поиск, шоппинг, PMax, медийка) в установленное приложение вместо мобильного сайта. Google приводит ориентир: до 2,8 раза выше коэффициент конверсии по сравнению с переходом на мобильный сайт (данные Google, апрель 2025 — воспринимайте как ориентир, а не как обещание для вашей вертикали).

Логика роста понятна без веры в цифры. У пользователя в приложении уже есть сессия, сохранённые платёжные данные и адрес, нет экрана логина и нет капчи. Вы не улучшаете оффер — вы убираете три шага из воронки. Поэтому эффект сильнее всего там, где высокая доля установленных приложений и длинная форма оформления: ритейл, доставка, трэвел, финансы, подписочные сервисы.

Диплинки не привлекают новых пользователей. Они перестают терять тех, кого вы уже привлекли и за кого второй раз платите в аукционе.

Какие диплинки в Google Ads поддерживаются, а какие нет

Платформа	Что нужно	Что не поддерживается
Android	App Links — отраслевой стандарт, проверяемая привязка домена к приложению	Кастомные схемы вида myapp://
iOS	Universal Links — отраслевой стандарт с файлом привязки на домене	Кастомные схемы, URL-редиректы
Любая	Прямые HTTPS-ссылки на ваш домен	Сторонние редирект-решения и ссылки-посредники

Ограничение по редиректам — не каприз: URL-редиректы не поддерживаются из-за рисков безопасности и приватности, включая фишинг и распространение вредоносного ПО. Для команд, которые годами жили на ссылках-посредниках мобильных атрибуционных платформ, это означает переделку: ссылка в объявлении должна вести на ваш собственный домен, а диплинк — срабатывать на уровне ОС.

Сначала посчитайте, потом внедряйте

В Google Ads есть два инструмента, которые экономят неделю споров с разработкой.

Deep Link Impact Calculator. Оценивает потенциальный прирост по конкретным URL: показывает, на какие адреса идёт платный трафик у пользователей с установленным приложением и сколько конверсий можно отыграть. Это и есть ваше обоснование задачи в спринте — в цифрах, а не в лозунгах.
Deep Link Validator. Проверяет, что ссылка действительно открывает нужный экран приложения. Обязательный шаг после внедрения: расхождение между «разработчик сказал, что сделал» и «ОС реально открывает приложение» встречается чаще, чем хотелось бы.

Оба инструмента живут в разделе App advertising hub в меню инструментов Google Ads. Порядок работы: посчитать потенциал → отдать список URL в разработку → проверить валидатором → включить.

Техническая часть: что нужно от разработчиков

Android

Intent-фильтры в манифесте приложения с атрибутом android:autoVerify="true".
Файл Digital Asset Links в формате JSON, размещённый на домене по HTTPS.
Начиная с Android 12 проверка выполняется строже и отдельно по каждому intent-фильтру — одна ошибка в одном фильтре ломает именно его, а не всё приложение, и диагностируется это неочевидно.

iOS

Entitlement associated domains в приложении.
Файл apple-app-site-association на домене по HTTPS.

Общее для обеих платформ

Файлы привязки отдаются по HTTPS, без редиректов, с корректным типом контента.
robots.txt не должен блокировать краулеры Google, включая AdsBot. Это тот же класс проблем, что ломает проверку посадочных страниц: разбор — в материале про AdsBot и краулинг посадочных страниц.
Контент веб-страницы и экрана приложения должны соответствовать друг другу: ссылка на карточку товара открывает карточку этого товара, а не каталог.

Карта покрытия: главная ошибка внедрения

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

Поэтому первым артефактом внедрения должна быть таблица соответствий, а не тикет «сделать диплинки».

Тип страницы сайта	Экран приложения	Приоритет
Карточка товара / услуги	Та же карточка по идентификатору	Высокий — сюда идёт основной платный трафик
Категория / подборка	Та же категория с применёнными фильтрами	Высокий
Корзина / оформление	Корзина с сохранённым составом	Высокий
Поисковая выдача по запросу	Поиск в приложении с тем же запросом	Средний
Промо-страница акции	Экран акции или категория с промо	Средний
Статьи, справка, блог	Часто не нужно — оставляем веб	Низкий

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

Пять мест, где ломается пользовательский опыт

Логин-флоу. Если приложение требует авторизацию, после входа пользователь должен попасть на тот экран, за которым шёл, а не на главную. Это самый частый баг внедрения и самый дорогой: пользователь уже в приложении, но уже не там, куда кликал.
Устаревшие данные. Товар есть на сайте, но его нет в приложении — пользователь видит пустой экран или ошибку.
Разные цены и промокоды. Акция действует на сайте и не действует в приложении: пользователь приходит за одной ценой, видит другую.
Гео и язык. Веб-страница региональная, приложение открывается в дефолтной локали.
Первый запуск после установки. Отложенный диплинк должен довести пользователя до нужного экрана после установки, иначе переход теряется ровно в тот момент, когда он вам дороже всего.

Измерение: куда записывается конверсия

Самая болезненная часть внедрения — не сама ссылка, а учёт. Три вопроса, которые нужно закрыть до запуска.

1. Считаются ли конверсии в приложении для веб-кампаний

Если пользователь ушёл из поисковой кампании в приложение и купил там, покупка должна вернуться в тот же аккаунт и к той же кампании. Иначе картина получается издевательская: поисковая кампания теряет конверсии, доля приложения в отчётах растёт, и команда «оптимизирует» бюджет ровно в обратную сторону.

2. Нет ли задвоения

Классика: одно и то же событие приходит и через веб-разметку, и через SDK приложения. CPA в отчёте красивый, в кассе — нет. Механику проверки мы разбирали в материале про дубли конверсий в Google Ads.

3. Учтён ли лаг

Переход в приложение часто удлиняет путь: пользователь открыл, отложил, вернулся вечером. Если вы оцениваете эффект через сутки после запуска, вы смотрите на половину данных. Как правильно читать окно конверсии — в статье про окно конверсии и лаг.

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

Пример расчёта потенциала

Цифры ниже — учебный пример, а не бенчмарк вашей ниши; подставьте свои. Задача — показать, как считать до внедрения, а не после.

Допустим, у интернет-магазина за месяц 120 000 кликов с мобильных устройств по веб-кампаниям. Доля пользователей с установленным приложением — 18%, значит потенциально «перехватываемых» кликов около 21 600. Текущий коэффициент конверсии мобильного сайта — 1,6%, то есть примерно 346 конверсий с этого сегмента.

Если конверсия в приложении для того же сегмента хотя бы в 1,8 раза выше (а не в 2,8, как в верхней оценке Google), получается около 622 конверсий — прирост примерно 276 конверсий в месяц без единого дополнительного клика. При среднем чеке и марже вашей ниши это и есть цифра, которую вы несёте в спринт-планирование.

Параметр	Значение в примере	Где брать у себя
Мобильные клики по веб-кампаниям	120 000 / мес	Отчёт по устройствам в Google Ads
Доля аудитории с приложением	18%	Аналитика приложения или оценка в калькуляторе
Конверсия мобильного сайта	1,6%	Отчёт по конверсиям с сегментом по устройству
Множитель конверсии в приложении	1,8×	Консервативная оценка; верхний ориентир Google — 2,8×
Прирост конверсий	≈ 276 / мес	Результат расчёта

Главная ценность такого расчёта — не точность, а приоритизация. Если прирост получается в пределах десятков конверсий, задача не стоит спринта разработки; если в сотнях — её стоит ставить выше половины бэклога по рекламе.

Как это видно в отчётах

После запуска вам понадобятся три среза, чтобы отличить реальный эффект от перераспределения.

Сегмент по устройствам. Эффект диплинков проявляется только на мобильных; если «выросло всё», вы смотрите на сезон или на другое изменение.
Сравнение по типам страниц. Сравнивайте конверсию URL, которые уже получили диплинк, с теми, что пока без него, — это ближайшая замена нормальному эксперименту.
Доля конверсий, пришедших из приложения. Она должна расти при неизменном общем расходе. Если растёт доля приложения, а общее число конверсий стоит на месте, вы просто переложили учёт из кармана в карман.

Если инфраструктура отчётности собрана нормально, все три среза уже есть и не требуют новых инструментов — как собрать такой «один экран правды», разбирали в материале про дашборды и отчётность медиабайера.

Чек-лист запуска

Посчитайте потенциал в Deep Link Impact Calculator и зафиксируйте ожидаемый эффект в цифрах.
Составьте карту соответствий «URL сайта → экран приложения» и отсортируйте по доле платного трафика.
Убедитесь, что на обеих платформах используются стандарты: App Links и Universal Links, без кастомных схем.
Уберите из цепочки сторонние редирект-ссылки.
Разместите файлы привязки по HTTPS и проверьте их доступность без редиректов.
Проверьте robots.txt: краулеры Google, включая AdsBot, не должны блокироваться.
Для Android проверьте autoVerify по каждому intent-фильтру отдельно.
Проверьте сценарий с логином: после авторизации пользователь попадает на целевой экран.
Проверьте отложенный диплинк — сценарий «установил и открыл впервые».
Прогоните Deep Link Validator по списку приоритетных URL.
Сверьте атрибуцию: конверсия из приложения возвращается в веб-кампанию, дублей нет.
Запускайте поэтапно: сначала категория URL с наибольшим трафиком, через две недели — остальные.

Как поставить задачу разработке

Большая часть провалов внедрения — не про код, а про постановку. Тикет «сделать диплинки» гарантированно вернётся с диплинком на главный экран. Рабочий шаблон задачи выглядит так.

Цель в цифрах. Сколько мобильных кликов в месяц идёт на эти URL, какая доля аудитории с приложением, какой ожидаемый прирост конверсий.
Список URL с приоритетом. Конкретные адреса или шаблоны адресов, отсортированные по доле платного трафика.
Соответствие экранов. Для каждого шаблона URL — какой экран приложения и по какому идентификатору открывается.
Требование к стандартам. App Links на Android, Universal Links на iOS; кастомные схемы и сторонние редиректы запрещены.
Требование к хостингу файлов привязки. HTTPS, без редиректов, корректный тип контента, доступность для краулеров.
Сценарии приёмки. Пользователь залогинен; пользователь не залогинен; приложение установлено, но сессии нет; приложение устанавливается после клика.
Критерий готовности. Deep Link Validator проходит по всему приоритетному списку, ручной тест на обеих платформах пройден.

Отдельно пропишите регламент поддержки: при каждом релизе приложения, который меняет навигацию или структуру экранов, карта соответствий проверяется заново. Без этого через полгода половина ссылок будет вести не туда, и обнаружится это по тихому росту CPA, а не по алерту.

Кто за что отвечает

Роль	Зона ответственности
Медиабайер / PPC-специалист	Расчёт потенциала, приоритизация URL, проверка эффекта в отчётах
Мобильная разработка	Intent-фильтры, entitlements, обработка диплинка и логин-флоу
Веб-разработка / DevOps	Файлы привязки на домене, HTTPS, robots.txt
Аналитика	Атрибуция, дедупликация, сверка конверсий между вебом и приложением

Когда диплинки не нужны

Низкое проникновение приложения. Если приложение установлено у единиц процентов аудитории, эффект будет в пределах статистической погрешности — сначала стоит вложиться в конверсию лендинга под платный трафик.
Приложение хуже сайта. Если в приложении меньше ассортимента, медленнее поиск или нет нужного способа оплаты, диплинк ухудшит результат.
Одноразовые сценарии. Для разовой покупки без повторных визитов преимущество приложения минимально.
Нет ресурса на поддержку. Карта соответствий требует обновления при каждом релизе приложения: мёртвый диплинк хуже его отсутствия.

И обратная сторона: если приложение у вас сильное, но установок мало, задача другая — не диплинки, а привлечение установок. Как это делается в условиях, когда алгоритм забрал почти все ручки, разобрано в материале про app-кампании в 2026.

Что это даёт в деньгах

Диплинки — редкий случай, когда улучшение не требует роста бюджета. Вы не покупаете больше кликов: вы повышаете отдачу с тех, за которые уже заплатили. На счёте это отражается как снижение CPA при том же расходе, поэтому эффект виден не в объёме трафика, а в юнит-экономике.

Отдельный бонус — скорость. Нативный экран приложения обычно открывается быстрее мобильной страницы, а скорость напрямую влияет на долю отвалов: механика та же, что в материале про скорость лендинга и Core Web Vitals. Проще говоря, диплинк — это ещё и самый радикальный способ ускорить посадочную: заменить её на то, что уже установлено на устройстве.

Если вы масштабируете платный трафик на нескольких рынках и вам нужна инфраструктура под это — от стабильных кабинетов до процессов — смотрите аренду агентских аккаунтов Google Ads, а разложить по полочкам структуру кампаний и измерение помогает обучение Google Ads от PPC Rebels.

Что проверить на стороне приложения до старта

Перед тем как направлять платный трафик в приложение, стоит честно оценить, выдержит ли оно этот трафик. Пять проверок, которые занимают час и экономят месяц.

Холодный старт. Сколько секунд проходит от нажатия на ссылку до отрисовки целевого экрана на среднем, а не флагманском устройстве. Если больше нескольких секунд, часть выигрыша съедается на старте.
Поведение без сети. Что видит пользователь при слабом соединении — заглушку с понятным текстом или пустой экран.
Ошибка несуществующего экрана. Если товара нет, приложение должно показать внятное состояние и путь дальше, а не выкинуть на главную.
Согласия и трекинг. Экран запроса разрешений не должен перекрывать целевое действие сразу после перехода; порядок показа влияет и на конверсию, и на корректность измерения.
Паритет оплаты. Все способы оплаты, доступные на сайте, доступны и в приложении — иначе пользователь дойдёт до последнего шага и уйдёт.

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

FAQ

Чем диплинк отличается от обычной ссылки на приложение?

Обычная ссылка ведёт в магазин приложений или на главный экран. Диплинк открывает конкретный экран — ту же карточку товара, корзину или категорию, которую пользователь видел бы на сайте.

Почему не поддерживаются кастомные схемы вида myapp://?

Они не подтверждают связь приложения с доменом, поэтому их можно подделать. Поддерживаются только отраслевые стандарты: App Links на Android и Universal Links на iOS.

Можно ли использовать ссылки мобильных атрибуционных платформ?

Сторонние редирект-решения не поддерживаются из-за рисков безопасности и приватности. Ссылка в объявлении должна вести на ваш домен, а открытие приложения обеспечивает механизм ОС.

Нужны ли app-кампании, чтобы использовать диплинки?

Нет. Web to App Connect работает именно для веб-кампаний — поиска, шоппинга, медийки и PMax. App-кампании решают другую задачу: привлечение установок.

Что будет, если приложение не установлено?

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

Нужно ли менять финальные URL в кампаниях?

В базовом сценарии нет: вы ведёте на свои веб-URL, а открытие приложения обеспечивается привязкой домена. Именно поэтому цепочка редиректов в URL так мешает — она ломает эту привязку.

Как проверить, что диплинк работает?

Используйте Deep Link Validator в разделе App advertising hub и дополнительно прогоните ручной сценарий на реальном устройстве с установленным приложением и активной сессией.

Что такое отложенный диплинк?

Сценарий, когда пользователь кликнул, приложения не было, он его установил — и после первого запуска должен попасть на целевой экран, а не на главную. Без этого теряется самый дорогой переход.

Диплинки влияют на показатель качества?

Напрямую нет. Косвенно — да: лучший пользовательский опыт и выше конверсия обычно улучшают экономику кампании, но оценка релевантности считается по веб-странице, указанной в объявлении.

Нужно ли что-то менять в robots.txt?

Нужно убедиться, что краулеры Google, включая AdsBot, не заблокированы и файлы привязки доступны. Это частая причина, по которой верификация домена не проходит.

Сколько времени занимает внедрение?

Техническая часть на стороне приложения обычно укладывается в один спринт, если карта соответствий готова заранее. Дольше всего занимает не код, а согласование, какие экраны приложения соответствуют каким URL.

Как понять, что внедрение окупилось?

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