MobiAds × Суточно.ру: как выйти в KPI за три недели и масштабировать мобильный трафик к высокому тревел-сезону

Главное о кейсе

В декабре 2025 года сервис онлайн-бронирования жилья «Суточно.ру» пришел в MobiAds, чтобы подготовить мобильный медиасплит к высокому тревел-сезону. Ключевой KPI — удерживать ДРР (долю рекламных расходов) и выполнять растущий план по бронированиям. Кампании вышли в эфир 16 февраля. Результаты не заставили себя ждать: через три недели ДРР снизился. Параллельно с этим выполнение плана по бронированиям взлетело с 33% до 108%.

Главный вызов проекта заключался не в том, чтобы один раз выполнить KPI. Эффективность была лишь базовым условием, а не финальной целью. Настоящая сложность была в другом: клиент ежемесячно повышал план по бронированиям, и к пику сезона медиасплит должен был выйти на полную мощность без потери маржинальности и роста ДРР. Чтобы решить эту задачу, мы оценивали новые источники трафика одновременно по качеству и потенциалу масштабирования, полностью перестроили ретаргетинг, систематизировали работу с креативами и автоматизировали мониторинг трекеров.

Саммари кейса

- Период закупки трафика: с февраля по июль 2026 года.
- Целевые показатели: удержание низкого ДРР при выполнении ежемесячного плана по бронированиям.
- Протестированные каналы: 16 источников, 9 из которых переведены в рабочую закупку.
- Тестирование креативов и подходов: проверено 78 гипотез (47 продолжили работу, 31 остановлена по результатам пролива).
- Финальные результаты (июль): снижение ДРР, закрыто более 13 000 бронирований (108% от плана).
- Retention: лучший источник показал низкий ДРР и 163% выполнения плана в июле.

Как проект изменил жизнь пользователей

Реклама помогала пользователям находить жилье для поездок через приложение Суточно.ру, а ретаргетинг возвращал к выбору и бронированию тех, кто уже проявил интерес к сервису. Вместо широких баз команда перешла к более точным динамическим сегментам. Пользователей, совершивших бронирование менее 30 дней назад, исключали из ретаргетинга, чтобы не направлять на них повторные рекламные обращения сразу после покупки.
В июле через рекламный сплит получено более 13 000 бронирований. Это подтвержденный результат целевых действий пользователей; изменение удовлетворенности, времени поиска жилья и качества поездок в проекте отдельно не измерялось.

Бизнес-задача и ее решение

О названиях площадок, напрямую не упомянутых в кейсе

Мы намеренно не раскрываем названия части площадок в этом кейсе. Источник, который не масштабировался на тревел-оффере в высокий сезон, может показать отличные результаты на другом оффере и в другое время. Ценность нашей работы — не в самом списке каналов, а в механиках, которые мы обнаружили внутри, и в процедуре, по которой мы принимали решения по каждому источнику.

Подготовка сплита к высокому сезону

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

У проекта было несколько серьезных ограничений. Во-первых, команде требовалось удерживать низкий ДРР, параллельно выполняя постоянно растущий план по бронированиям. Во-вторых, часть крупнейших каналов трафика изначально находилась в in-house-контуре клиента, поэтому новый сплит нужно было выстраивать с учетом уже работающей закупки.

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

С чего начинали работу

- Подготовили креативы до запуска

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

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

- Собрали карту событий и зафиксировали органику как бенчмарк

В трекере клиента уже была настроена подробная система событий. Мы запросили карту воронки с точными названиями событий вплоть до бронирования. Это позволяло видеть не только итоговое число покупок, но и этап, на котором конкретный источник теряет пользователя.

Одновременно мы зафиксировали бенчмарки органического трафика — как контрольную группу для оценки качества привлеченных пользователей. На еженедельных статусах сравнивали retention и другие поведенческие метрики платных каналов с органическими показателями. Это позволяло быстрее замечать существенные отклонения в качестве аудитории и проверять гипотезы до того, как они отражались на экономике кампаний.

- Считали медиаплан сразу под рост

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

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

Этот подход пригодился еще до официального запуска: когда стало понятно, что китайский Новый год может затормозить модерацию на одном из OEM-источников, мы оперативно перенаправили его бюджет в self-service каналы. Их можно масштабировать гораздо быстрее, чем full-service DSP, благодаря чему первая неделя открутки не была потеряна.

В KPI — за три недели

16 февраля мы запустили кампании. К закрытию февраля, после 12 дней открутки, ДРР составил нужный процент. На статусе 10 марта — через три недели после старта — показатель снизился еще. После этого на закрытии ни одного месяца ДРР не выходил за KPI.

ДРР внутри KPI с первого месяца, объем набирается пять месяцев.

К марту задача по эффективности была решена. Дальше фокус сместился на объем: выполнение плана по бронированиям росло с 33% в феврале до 108% в июле, при этом ДРР улучшился.

Важная деталь: в первые месяцы план по количеству бронирований был выше фактического результата, но это не означало недовыполнение по экономике. Бронирование стоило дешевле заложенного, поэтому по обороту клиент все это время шел выше 100% плана.

Почему эффективный источник не всегда полезен для сплита

В апреле одна SSP показывала CPA 631 ₽ при плане 675 ₽. По эффективности это был один из лучших источников проекта. Мы его отключили.

На тест было заложено около 350 тыс. ₽ в месяц. За два месяца мы провели шесть итераций:

- Перезапустили кампании.
- Разделили плейсменты.
- Получили whitelist паблишеров.
- Проверили гипотезу с новым рекламным кабинетом.
- Оставили наиболее конверсионные видеоформаты.
- Провели оптимизацию по сырым выгрузкам.

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

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

При первой остановке в марте источник показывал отличный ДРР, но не масштабировался по объему. Спустя два месяца мы предприняли вторую попытку и изменили стратегию: переключили алгоритм с оптимизации по глубокому событию воронки на оптимизацию по установкам. Тогда поддержка площадки уточнила важную особенность: DSP обучается на событиях, совершенных в первые два дня после установки, тогда как в travel бронирование часто происходит значительно позже. В результате алгоритму не хватало конверсионных сигналов для полноценного обучения.

Правда, оптимизация по установкам тоже себя не оправдала: ДРР взлетел до критических значений. Команда площадки подтвердила, что перейти на оптимизацию по бронированиям теперь невозможно, и предложила вернуться к закупке по установкам.

Третьего захода не было.

Третьей закрытой площадкой стала full-service DSP — единственный канал, который мы отключили именно по причине неэффективности. Его ДРР стабильно превышал KPI даже после завершения стадии обучения алгоритмов, и первая оптимизация по SSP и site_id не принесла результата, поэтому решение о деактивации было быстрым.

В итоге из трех остановленных UA-источников два были отключены при отличных показателях ДРР из-за объемов трафика.

Матрица отбора источников: качество × емкость

Все решения по источникам укладываются в две оси: качество трафика и емкость источника.

Самый неочевидный сегмент — высокое качество при низкой емкости. Источник может укладываться в KPI, но не помогать выполнить сезонный план. В таком случае его место в сплите занимает площадка, которую можно масштабировать.

- Высокое качество и высокая емкость — ядро сплита. Пять источников, масштабируем, они держат пик.
- Высокое качество и низкая емкость — отключаем. Два источника с низким ДРР. Самое контринтуитивное решение проекта.
- Низкое качество и высокая емкость — оптимизируем. Три источника на ручном контроле: объем дают, экономику вытягиваем вручную.
- Низкое качество и низкая емкость — закрываем сразу. Один источник, решение за 2–4 недели.

«На этом проекте несколько раз приходилось принимать неочевидное решение: источник укладывается в KPI, но мы все равно его отключаем. В высокий сезон недостаточно быть дешевым — нужно еще уметь принять объем. Поэтому мы смотрели не только на ДРР, но и на емкость. В итоге два источника с низким ДРР не вошли в сезонный сплит, и для общей экономики это было правильнее, чем держаться за красивую цифру».

Максим Кочетов, MediaBuying Lead MobiAds

16 источников за пять месяцев: что осталось в сплите

Всего через тестирование прошло 16 источников. Девять сформировали рабочий сплит, три закрыли по результатам, два отложили из-за технической готовности площадок, еще два переназначили.

Отбраковка — не брак работы, а ее содержание: семь источников из шестнадцати не дожили до сезона.

Сколько времени давать источнику на тест

За полгода мы проверили 78 гипотез: 47 остались в работе, 31 остановили. Количество итераций зависело не от «важности» источника, а от того, насколько быстро можно было понять причину результата.

Например, на управляемой iOS-закупке проверили 24 гипотезы, на втором ядре — 23. На источник, который в итоге закрыли из-за емкости, ушло восемь гипотез: они были нужны, чтобы отделить проблему настройки от структурного ограничения инвентаря.

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

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

Правило когорты

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

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

Пример из кейса. Май: один и тот же сплит, разные стадии когорты

На 11 мая ДРР был выше KPI. Агентство, которое реагирует на дневную цифру, в этот момент режет сплит и теряет месяц. Мы дождались когорты: май закрылся с ДРР ниже KPI и выполнением плана по бронированиям 98% — лучшим на тот момент результатом проекта.

Поэтому в еженедельных статусах мы вели два показателя: ДРР d0 как оперативный сигнал и тотальный ДРР как основание для решений. Для этого собрали отдельный дашборд.

Ретаргетинг: от 5–6% бюджета до самого эффективного блока

Сегментацию настраивали для наибольшей инкрементальности ретаргетинга. Мы провели аналитику, выявив период, в который мы не должны взаимодействовать с пользователем нашими retargeting-кампаниями: менее 30 дней после последней брони.

Далее тестировали сегменты в следующем порядке:

- Апрель и май — статичные базы на период накопления постбэков: широкие сегменты пользователей, установивших приложение за последний год, полгода, три месяца, но не совершавших бронирования в последний месяц. Отмели широкие аудитории и оставили в ротации наиболее узкие.
- Июнь — переход на динамические аудитории по постбэкам: на первое время перешли на динамические аудитории, аналогичные статическим, но дали свободу full-service площадке по тесту дополнительных сегментов. Важно было не нарушать правило «не покупали в последний месяц».
- Июль — увеличили количество динамических сегментов до пяти. Это дало нам более точный таргетинг, повышенный CR в бронирование и увеличение объемов в 2,5 раза.

В июле второй RET-источник дал 163% выполнения плана и низкий ДРР. К концу проекта RET стал самым эффективным блоком сплита по ДРР.

Что нужно учесть при запуске RET на Android

- Universal Links должны быть корректно настроены в приложении. Без этого пользователь после клика по рекламе не попадет на нужный экран внутри приложения, и часть трафика будет теряться на этапе перехода.
- События перехода и целевые действия должны корректно передаваться в трекер. Даже при работающих диплинках без правильной передачи данных через SDK невозможно корректно атрибутировать установки, открытия приложения и последующие конверсии.
- Re-engagement и re-attribution — разные события, их нельзя объединять в одну метрику.

Как работали с креативами

За проект дизайн-команда подготовила 71 мастер-креатив на 40 концептов и 1 100 ресайзов под 16 размеров. В работе использовали статику, motion и UGC.

- Каждый креатив был размечен по элементам: мокап устройства, кнопка, люди в кадре, маскот, текст CTA. Это позволяло считать CPA и ДРР не только по целому баннеру, но и по отдельным механикам.
- Разметку намеренно балансировали: мокап использовали в 34 креативах из 71, кнопку — в 46, людей — в 25, маскота — в 22. Отдельно тестировали CTA: 32 креатива с «Забронировать», 13 — со «Скачать», 26 — без текста на кнопке.

Из 40 концептов 26 получили вторую и последующие версии, а самый проработанный дошел до десятой итерации. Подход был тем же, что и в медиабаинге: гипотеза — замер — следующая версия.

Креативную часть мы перестроили не вокруг «сделать больше баннеров», а вокруг поиска работающих механик. По ходу сезона обновляли performance-хуки, тестировали storytelling и motion-форматы.

Отдельным направлением стали UGC-креативы: мы не ограничились генеративными форматами (AI) и подготовили 11 реальных роликов с актерами. Эти креативы показали эффективность сразу в двух направлениях — как в UA-закупке, так и в RET-блоке, где помогали возвращать пользователей к первой покупке.

Собственная разработка внутри Performance

Отдельная проблема проекта — блокировка трекеров AppMetrica. В подобной ситуации рекламный кабинет продолжает расходовать бюджет, хотя трафик уже остановился. При этом метрики качества еще какое-то время кажутся нормальными.

Подобный сбой произошел 11 июня на крупнейшем iOS-канале, из-за чего за выходные объем конверсий рухнул практически до нуля. Мы оперативно пересобрали трекер и перезапустили кампании с нуля. После реанимации источник быстро вышел на плановые 90 тысяч рублей спенда в день и завершил июль с ДРР на низком уровне.

Но ручное устранение регулярных сбоев — неэффективная стратегия. Чтобы автоматизировать этот процесс, мы разработали Telegram-бота, который каждый час проверяет статус трекеров и мгновенно присылает детальный алерт: какой трекер ограничен, у какого партнера, с датами и причинами блокировки.

В функционал также заложены две команды:

- /check — просмотр блокировок в real-time.
- /status — состояние самого мониторинга.

Чаще всего триггером блокировки выступают «подозрительные показы» — именно тот случай, который технически невозможно отследить по метрикам. Качество трафика и удержание пользователей остаются в норме, но трекер уже не работает. Бот позволяет обнаружить отклонение в течение часа — реакция становится вопросом одного действия, а не расследования.

Бот мониторинга трекеров, разработанный под проект. Проверка идет каждые 60 минут; /check запускает ее вручную, /status показывает состояние мониторинга. В спокойном режиме бот отвечает, что заблокированных трекеров нет, — и это единственный способ отличить «все работает» от «все встало, но по метрикам это еще не видно».

Параллельно мы перестроили работу с доступами full-service площадок так, чтобы их байеры могли пересоздавать трекеры самостоятельно — они замечают блокировку первыми и реагируют быстрее всех. Это тот случай, когда правильное решение — не ускорить свою реакцию, а убрать себя из цепочки.

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

Крафт (мастерство), реализация, технические детали

Аналитика с учетом длинного цикла бронирования

Команда получила карту воронки с точными названиями событий вплоть до бронирования. Это позволяло видеть, на каком этапе источник теряет пользователя. Органический трафик использовали как бенчмарк качества: на еженедельных статусах сравнивали retention и другие поведенческие метрики платных каналов с органикой.
Для контроля экономики собрали отдельный дашборд с двумя показателями: ДРР d0 как оперативным сигналом и итоговым ДРР по созревшим когортам как основанием для решений. В работе закрепили 15-дневную когорту. Например, 11 мая ДРР превышал KPI, но после созревания когорты май закрылся ниже KPI и с 98% плана по бронированиям — лучшим на тот момент результатом.

Матрица качества и емкости источников

Высокое качество и высокая емкость — ядро сплита: пять источников масштабировали к пику. Высокое качество при низкой емкости — два источника отключили, несмотря на низкий ДРР. Низкое качество при высокой емкости — три источника оставили на ручной оптимизации. Низкое качество и низкая емкость — один источник закрыли.
Время теста зависело от причины результата. Качество оценивали за 2–4 недели после обучения алгоритмов. Проверка емкости занимала 2–4 месяца: последовательно тестировали ставки, инвентарь, плейсменты, ограничения кабинета и площадки. Если рабочей интеграции с трекером не было, запуск откладывали до полноценного теста.

Ретаргетинг от статичных баз к динамике

Анализ поведения пользователей определил обязательное исключение: не показывать RET-рекламу тем, кто бронировал жилье менее 30 дней назад. В апреле и мае, пока накапливались постбэки, тестировали статичные базы пользователей, установивших приложение за год, полгода и три месяца, но не бронировавших в последний месяц. Широкие аудитории отсеяли, оставив более узкие.
В июне перешли к динамическим аудиториям по постбэкам. Сначала воспроизвели статичные сегменты, затем дали full-service площадке возможность тестировать дополнительные при сохранении исключения недавних покупателей. В июле число динамических сегментов довели до пяти: выросли точность таргетинга, конверсия в бронирование и объем.
Техническая подготовка включала проверку диплинков, перехода на нужный экран приложения и передачи событий через SDK в трекер. Re-engagement и re-attribution учитывали раздельно.

Креативы как система проверяемых механик

Дизайн-команда подготовила 71 мастер-креатив на основе 40 концептов и 1 100 ресайзов под 16 размеров. Использовали статику, motion и UGC. До старта адаптировали гайдлайн клиента под требования площадок, согласовали мастер-баннеры и ресайзы. Часть источников запустили на материалах клиента, параллельно расширяя собственную библиотеку.
Каждый креатив размечали по элементам: мокап устройства, кнопка, люди, маскот, CTA. Это позволяло анализировать CPA и ДРР по механикам. Мокап присутствовал в 34 из 71 креатива, кнопка — в 46, люди — в 25, маскот — в 22. Варианты CTA: 32 креатива с «Забронировать», 13 со «Скачать», 26 без текста на кнопке.
Из 40 концептов 26 получили продолжение, самый проработанный дошел до десятой версии. По ходу сезона обновляли performance-хуки, проверяли storytelling и motion. Помимо AI-форматов, сняли 11 реальных UGC-роликов с актерами: они работали в привлечении новых пользователей и в ретаргетинге, возвращая аудиторию к первой покупке.

Собственная разработка для мониторинга трекеров

11 июня на крупнейшем iOS-канале возникла блокировка трекера AppMetrica: за выходные объем конверсий упал почти до нуля. Команда пересобрала трекер и перезапустила кампании. После восстановления источник вышел на плановые 90 тыс. рублей расходов в день и завершил июль с низким ДРР.
Чтобы быстрее обнаруживать повторные сбои, разработали Telegram-бота. Каждые 60 минут он проверяет статус трекеров и отправляет уведомление с партнером, датами и причинами блокировки. Команда /check запускает проверку вручную, /status показывает состояние мониторинга. В спокойном режиме бот подтверждает отсутствие заблокированных трекеров.
Блокировки по причине «подозрительных показов» нельзя надежно обнаружить только по качеству трафика и удержанию: показатели могут оставаться нормальными, когда трекер уже ограничен. Бот сокращает интервал обнаружения до часа. Дополнительно перестроили доступы full-service площадок, чтобы их байеры могли самостоятельно пересоздавать трекеры и быстрее восстанавливать закупку.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

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

Когда хороший CPA не решает задачу

В апреле одна SSP показывала CPA 631 рубль при плане 675 рублей. На тест выделяли около 350 тыс. рублей в месяц, но площадка не могла освоить больше половины бюджета. За два месяца провели шесть итераций: перезапуск кампаний, разделение плейсментов, whitelist паблишеров, новый кабинет, отбор наиболее конверсионных видеоформатов и оптимизацию по сырым выгрузкам.
После изменений качество возвращалось к бенчмаркам, но потолок объема сохранялся: качественного iOS-инвентаря под тревел-оффер было недостаточно. Источник отключили. Всего на проверку этого канала пришлось восемь гипотез — они помогли отделить проблему настроек от ограничения инвентаря.

Почему источнику дали второй шанс

DSP с коротким окном обучения впервые остановили в марте: ДРР был хорошим, объема не хватало. Через два месяца закупку возобновили, сменив оптимизацию с глубокого события на установки. Поддержка уточнила, что алгоритм обучается на событиях первых двух дней после установки. Для тревела, где бронирование происходит позже, конверсионных сигналов не хватало.
Оптимизация по установкам привела к критическому росту ДРР. Площадка подтвердила невозможность возврата к оптимизации по бронированиям; третью попытку не проводили. Еще одну full-service DSP закрыли из-за ДРР выше KPI после обучения: оптимизация по SSP и site_id не помогла.

Подготовка и взаимодействие с клиентом

Еще до запуска учли модерацию и юридическую проверку площадок. Когда китайский Новый год создал риск задержки одного OEM-источника, бюджет перенаправили в self-service каналы: их можно было масштабировать быстрее full-service DSP. Это позволило сохранить первую неделю закупки.
На еженедельных статусах с клиентом обсуждали экономику, созревание когорт и качество аудитории. Медиаплан строили с учетом потенциального лимита каждого источника и сценариев перераспределения. За проект подготовили десять версий медиаплана: семь месячных и три переплана по ходу кампании.
По данным материалов проекта, работа заняла 218 дней от первой встречи до закрытия сезона, включала 48 статусов и 24 внешних созвона, помимо внутренних. Всего проверили 78 гипотез: 47 продолжили работу, 31 остановили. На управляемую iOS-закупку пришлось 24 гипотезы, на второе ядро сплита — 23.
Результатом стала воспроизводимая процедура: решения по качеству — после обучения, по объему — после проверки ограничений, по ДРР — после созревания когорты. Она позволила менять масштаб закупки за дни без потери управляемости экономики.

Прочая информация о кейсе

Закупка трафика: февраль — июль 2026 года.

Старт кампаний: 16 февраля 2026 года. Привлечение новых пользователей обозначено как UA, ретаргетинг — как RET.
Точные значения ДРР в публичных материалах не раскрываются. Названия части площадок также не приводятся: результат источника зависит от оффера, сезона и доступного инвентаря. В кейсе раскрыты механики тестирования и логика решений.

Скриншоты

Комментарий заказчика

«Для нас было важно, чтобы агентство не просто показало хороший ДРР на старте, а смогло масштабировать закупку к сезону. По ходу проекта менялись объемы, источники и RET-сегменты, но экономика оставалась управляемой. К июлю мы получили 108% плана по бронированиям при низким ДРР— и, что не менее важно, понятную логику, как дальше управлять этим сплитом.»