In-App в Unity Ads 2026: как выбрать приложение, настроить интеграцию и довести трафик до первых депозитов

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

Этот материал — практическая карта по In-App трафику в Unity Ads образца 2026 года: как устроен источник, как выбрать и проверить приложение, что передавать в событиях, как пройти техническую настройку и как довести трафик от первой установки до стабильных депозитов.

Приложение то же — подход другой

Само приложение технически мало зависит от того, откуда идёт трафик. А вот связка с Unity строится принципиально иначе, чем в классических источниках.

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

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

Что пугает байеров при переходе на In-App — и почему это решаемо

Переход на In-App редко пугает «сложностью рекламы». Пугает непривычность:

Другая структура кабинета и кампаний. Логика Unity отличается от соцсетей и поисковых сетей, и первые дни приходится переучиваться.
Приложение становится частью связки. В обычных источниках вы льёте на лендинг, который легко поменять. Здесь приложение — это актив, от которого напрямую зависит результат, и выбрать его «на глаз» нельзя.
Настройка интеграции и событий. Без корректной передачи событий невозможно понять, где именно рвётся воронка: на установке, регистрации или депозите.
Тесты требуют объёма. Одна кампания на минимальном спенде ничего не докажет. Чтобы делать выводы, нужны данные, а данные стоят бюджета и времени.

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

Как выбрать приложение

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

Платформа. Работать можно с приложениями и из Google Play (Android), и из App Store (iOS). Для первого захода почти всегда проще Android: атрибуция прозрачнее, события приходят быстрее и в полном виде. На iOS данные идут через механику Apple (SKAdNetwork / AdAttributionKit), приходят обезличенными, агрегированными и с задержкой — это отдельный навык, в который лучше заходить, уже имея опыт на Android.

Атрибуция. От того, как и когда приходят данные, зависит скорость обучения алгоритма. На Android вы видите события практически в реальном времени и по каждому пользователю. На iOS картина агрегированная и отложенная, поэтому и ожидания от скорости оптимизации должны быть другими.

События. Минимально рабочий набор — три события: install, reg и dep. Если приложение умеет передавать только установку, алгоритм так и застрянет на оптимизации под CPI и никогда не доберётся до оптимизации под качество.

Чек-лист приложения перед запуском

Прежде чем ставить приложение в связку, пройдитесь по пяти пунктам:

Интеграция и шеринг. Приложение интегрировано с Unity, рекламный кабинет расшарен на него.
Иконка под тематику. Иконка соответствует креативу и офферу — визуальный «обрыв» между рекламой и иконкой убивает конверсию.
Первый экран продолжает креатив. То, что человек увидел в рекламе, должно логично продолжаться на первом экране после установки.
Тестовые события доходят. Пробные install, reg и dep реально доезжают и до трекера, и до Unity.
Приложение лёгкое и стабильное. Значительная часть In-App трафика идёт со слабых устройств и медленных сетей — тяжёлое или нестабильное приложение теряет пользователей ещё до регистрации.

Хорошая практика — держать на тесте не одно приложение, а несколько. Это позволяет сравнивать результаты на одинаковых креативах и перераспределять бюджет в пользу того, что реально приносит депозиты, а не просто дешёвые установки.

Техническая настройка: пошагово

Большую часть интеграции обычно берёт на себя техническая сторона (мобильный разработчик приложения): именно она делает шеринг кабинета и настраивает передачу событий. От байера нужны два входа — выбранное приложение и доступ к кабинету Unity. Общая логика настройки выглядит так:

Создать рекламный кабинет в Unity Ads (Unity Grow / Unity Ads).
Выбрать приложение, которое станет частью связки.
Добавить приложение в Unity, указав ссылку на его страницу в сторе.
Получить Game ID — идентификатор приложения в системе Unity.
Передать Game ID технической стороне для настройки интеграции.
Получить трекинговые ссылки — Click и Impression.
Добавить эти ссылки в раздел Attribution links в настройках приложения в Unity.
Проверить, что тестовые события корректно проходят по всей цепочке: приложение → трекер → Unity.

Последний шаг критичен: именно сквозной тест показывает, что система собрана правильно. Game ID должен совпадать в кабинете и в интеграции, Click и Impression ссылки — стоять в нужных полях, а таймзона в Unity и в трекере — быть одинаковой, иначе события «разъедутся» по времени и отчёты перестанут сходиться.

Какие события передаются и зачем

Передача событий — это язык, на котором приложение разговаривает с алгоритмом. Чем богаче и честнее этот язык, тем точнее оптимизация.

Install — базовое событие. На нём строится оптимизация под CPI. Это старт, но останавливаться на нём нельзя: оптимизация под установки собирает много дешёвого, но часто пустого трафика.
Reg — регистрация. По соотношению install → reg вы оцениваете качество трафика уже после установки и понимаете, доходит ли человек до продукта вообще.
Dep — депозит. Передаётся как покупка, обязательно с суммой и валютой. Без суммы невозможна оптимизация под ROAS — алгоритму просто нечего взвешивать.

Для запуска ROAS-кампании Unity требует минимального объёма платящих пользователей (ориентир — порядка 10 платящих за 7 дней). Пока этот порог не набран, кампания работает на более простых целях, и это нормальная стадия разгона, а не поломка.

Атрибуция в 2026: что изменилось

За последние пару лет ландшафт атрибуции заметно сместился, и в 2026 году это нужно учитывать с самого старта.

iOS: от SKAdNetwork к AdAttributionKit. Apple продолжает двигать экосистему в сторону приватной, агрегированной атрибуции. SKAN 4.0 остаётся рабочим стандартом, но Apple активно развивает AdAttributionKit как следующий слой, в том числе для альтернативных магазинов приложений в ряде регионов. Для байера практический смысл один: данные с iOS приходят обезличенными, с задержкой и в агрегированном виде, поэтому короткие окна и реакция «по горячим следам» здесь не работают. Нужно закладывать более длинные циклы оценки и не паниковать из-за «пустых» первых часов.

Android: Privacy Sandbox. Google продолжает выкатывать Privacy Sandbox на Android, постепенно ограничивая доступ к идентификаторам и сдвигая часть атрибуции в сторону агрегированных сигналов. Пока Android остаётся прозрачнее iOS, но тренд тот же — меньше сырых данных, больше моделируемых. Это ещё один аргумент заранее настраивать полноценную передачу событий reg и dep, а не надеяться на разметку по устройствам.

MMP как страховка. Чем мутнее становится атрибуция на уровне платформ, тем важнее надёжный мобильный трекер (MMP). На практике связки стабильнее работают с устоявшимися решениями уровня Adjust, AppsFlyer и Singular — они корректнее прокидывают revenue по всей цепочке и дают предсказуемую стыковку с Unity. Какой именно MMP использовать — вопрос доступа и привычки, но сам факт его наличия в 2026 году уже не опция, а база.

Финальный чек-лист перед первым спендом

Перед тем как включить открут, пройдитесь по списку:

кабинет расшарен, приложение видно в Unity;
Game ID передан и совпадает в кабинете и в интеграции;
Click и Impression ссылки добавлены в Unity;
таймзона одинаковая в Unity и в трекере;
тестовые install, reg, dep прошли по всей цепочке;
иконка и название приложения соответствуют креативам;
настроены алерты (например, в Telegram) на первую регистрацию и первый депозит, чтобы ловить разрывы воронки в первые часы.

Как устроен запуск трафика

Запуск — это не «нажать старт», а выстроенная последовательность.

Сборка базы. Перед первым откругом должно быть собрано всё: приложение, события, бюджет, выбранные типы оптимизации и креативы. Чем полнее база, тем меньше правок придётся вносить на ходу.

Креативы. Алгоритму нужно давать выбор. Рабочая практика — запускать несколько креативов в разных связках форматов, прежде всего Video + Endcard и Video + Playable, и постепенно обновлять их, не выжигая одну удачную находку до нуля. Playable-форматы в In-App дают более «прогретого» пользователя, потому что он уже взаимодействовал с механикой до установки. В 2026 году производство креативов заметно ускорили ИИ-инструменты: генерация вариаций видео, озвучка и локализация делаются быстрее, и это стоит использовать для более частой ротации — но тестировать всё равно нужно по данным, а не по «нравится/не нравится».

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

Оценка. Смотрите на связку метрик: CPI, CPA Reg и CPA Dep — это деньги, а CTR и CVR помогают понять причину просадки. Если проседает CPI — вопрос к креативу и приложению; если установки есть, а регистраций мало — к связке «креатив ↔ продукт»; если регистрации есть, а депозитов нет — к офферу и дальней части воронки.

Масштабирование и блэклисты

Когда связка вышла в плюс и стабилизировалась, начинается рост. Масштабировать стоит по нескольким осям сразу, но аккуратно:

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

Отдельная работа — блэклисты площадок. Их нельзя собирать «на глаз» в первые дни. Правильный путь — накопить данные по source/площадкам, увидеть, где систематически нет регистраций и депозитов при нормальном объёме установок, и только затем отключать. Ранний блэклист по эмоциям так же вреден, как ранняя смена ставок.

Гео и локализация

Универсального «лучшего гео» не существует — есть гео, которое подходит вашей связке. При выборе учитывайте:

Тематику. То, что отлично заходит в одном регионе, может быть мёртвым в другом.
Долю Android и iOS в стране. Если в гео доминирует iOS, а вы зашли с Android-приложения, вы отрезаете часть рынка (и наоборот).
Локализацию. Приложение, креатив и оффер должны говорить на языке пользователя — включая местную валюту в депозитах и привычные способы оплаты.
Иконку. Она должна быть узнаваемой и уместной именно в этом гео, а не универсальной «для всех».

Частые проблемы и диагностика по воронке

Большинство проблем на старте сводится к нескольким типовым сценариям.

Техническая часть. Ошибки в Game ID, незавершённый статус интеграции, события, которые не доезжают (особенно на iOS). Статус в кабинете может обновляться с задержкой, поэтому «ничего не работает» в первые часы — не всегда поломка.

Задержка данных. Регистрации и депозиты могут появляться в Unity с ощутимым лагом (на iOS — вплоть до пары суток). Чтобы не терять связь между креативом и результатом, стоит передавать параметры вроде creative_pack / creative_pack_name — иначе вы не поймёте, какой именно креатив принёс депозит.

Revenue для ROAS. Значение дохода должно корректно прокидываться по всей цепочке приложение → трекер → Unity. Если сумма теряется или приходит нулевой, ROAS-оптимизация работать не будет, сколько бы платящих вы ни привели.

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

Ранняя оптимизация. Частые правки ставок и бюджета в первые дни мешают алгоритму обучиться и чаще вредят, чем помогают.

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

Коротко о главном

In-App в Unity Ads — это источник, где результат закладывается до первого открута: в выборе приложения, чистоте интеграции и полноте передаваемых событий. Байеру в 2026 году важно держать в голове три вещи: заходить проще с Android и расти на iOS уже с опытом; строить оптимизацию на связке install → reg → dep, а не застревать на установках; и учитывать новую реальность атрибуции (SKAN 4.0, AdAttributionKit, Android Privacy Sandbox), закладывая более длинные окна оценки и надёжный MMP. Всё остальное — тесты, креативы, масштаб и блэклисты — работает только тогда, когда этот фундамент собран правильно.