Бэктест рекламного правила до запуска

Вторник, 9:15. Специалист по performance-маркетингу наконец записывает правило, о котором думал три недели: «Если ROAS за последние 7 дней ниже 1,0 — остановить кампанию». Рядом с кнопкой сохранения есть вторая: что это правило сделало бы за последние 28 дней? Он нажимает. Результат на экране совсем не похож на картинку в голове: правило сработало бы 46 раз, задело бы 9 кампаний из 12 хотя бы однажды, и среди остановленных оказалась бы ретаргетинговая кампания, которая принесла больше всего выручки за месяц. Причина прозаична: её ROAS стабильно падает до 0,8 утром в понедельник и возвращается к 2,4 к среде. Цифры здесь приведены как пример. Не пример — вывод: будь правило включено, лучшая кампания аккаунта закрылась бы в понедельник утром, пока в дашборд никто не смотрел.

Дальше мы разбираем бэктест не как ритуал уверенности, а как инструмент, который измеряет охват правила и его слепые зоны. Сначала отделяем то, что бэктест доказывает, от того, что доказать не может. Затем смотрим, откуда на самом деле берётся пороговое значение, что скрывает окно в 28 дней и в чём состоит проблема обратной связи — правило переписывает ту самую историю, на которой его проверяют. Потом: чем симуляция отличается от бэктеста, как ограничители срезают число срабатываний, как читать это число по таблице решений, что ловит режим «только показать» и какие доказательства вы собираете уже после запуска. В конце — когда правило пора выводить из работы.

Что бэктест доказывает, а что нет

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

Чего он не доказывает — так это результата. Бэктест не скажет вам «с этим правилом ROAS был бы выше», и не может сказать: если бы правило остановило кампанию 12 марта, данных за 13–28 марта просто не существовало бы. История, которая у вас есть, — это история без вмешательства правила. Провести эту границу заранее — значит не нагружать бэктест тем, чего он не выдержит. В разработке действует та же дисциплина: прогнать автоматизацию на прошлых входных данных до продакшена — самый дешёвый способ увидеть её поведение, и тестирование AI-агента до запуска строится на той же логике.

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

Откуда на самом деле берётся пороговое значение

Большинство правил не работает не потому, что они плохо написаны, а потому что написаны против неверного числа. Откуда взялась единица в «остановить, если ROAS ниже 1,0»? Обычно это круглая цифра, произнесённая на планёрке, никак не связанная с реальным распределением в аккаунте. Если медианный ROAS у вас 0,9, такой порог остановит половину кампаний. Если медиана 3,2 — правило не сработает ни разу за год и останется висеть как украшение.

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

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

Что скрывает окно в 28 дней

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

Второе ограничение — качество данных. Прежде чем правило будет сохранено, контроль здоровья данных проверяет свежесть синхронизации, покрытие за 28 дней и валюту аккаунта; из устаревших или неполных данных правило не рождается. Эта проверка защищает основание, на котором стоит бэктест, но не чинит атрибуцию: если конверсии приписаны не той кампании, бэктест пометит не ту кампанию. Поэтому UTM-метки и отслеживание кампаний должны быть настроены до того, как вы начнёте писать правила.

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

Правило переписывает историю: проблема обратной связи

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

С бюджетными правилами смещение работает в другую сторону. Если бы правило «повышать бюджет при ROAS выше цели» действовало, выросший бюджет, скорее всего, поднял бы CPM и частично утянул ROAS обратно; бэктест этой реакции не видит, потому что его данные получены при меньшем бюджете. То есть на правилах масштабирования бэктест оптимистичен, а на правилах остановки — преувеличивает.

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

Когда симуляция полезнее бэктеста

Бэктест спрашивает «случилось бы это», симуляция — «что будет при таких значениях». В экране «Симуляция на ваших числах» вы вводите примерные метрики вручную: ROAS 0,7, расход 90 000 ₽, частота 4,2. Совпадает ли условие, как ограничитель обрежет изменение бюджета, с каким значением применилось бы действие — всё видно, ничего не применяется.

Различие критично в трёх случаях. Первый: у только что запущенной кампании нет истории, бэктест вернёт пустоту, а симуляция всё равно проверит логику. Второй: вы хотите вручную пройтись по краям — что происходит ровно на пороге, не ломается ли условие при нулевом расходе. Третий: в аккаунтах с малым объёмом 28 дней статистически тонки и без того; в LinkedIn Ads для B2B, где число конверсий за месяц едва доходит до двузначного, найденная бэктестом закономерность легко оказывается совпадением.

Рабочий порядок: опишите правило обычной фразой, просмотрите черновик «условие → действие», проверьте логику симуляцией и только потом измеряйте охват бэктестом. В обратном порядке вы потратите день на спор о числе срабатываний условия, которое написано неверно.

Как ограничители срезают число срабатываний

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

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

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

Сколько срабатываний считать здоровым числом

Единственно верного числа нет, но диапазон достаточно ясно указывает на следующий шаг. Таблица ниже написана для окна в 28 дней и среднего аккаунта с 10–30 активными кампаниями; масштабируйте под своё число кампаний.

Результат бэктеста	Вероятная причина	Следующий шаг
0 срабатываний	Порог вне распределения	Вернуться к распределению, взять медиану
1–5 срабатываний	Узкое избирательное правило	Сразу перевести в режим подтверждения
6–20 срабатываний	Разумный охват	Неделя «только показать», затем подтверждение
20+ срабатываний, мало кампаний	Колебания на одних и тех же кампаниях	Увеличить паузу между действиями
В списке почти все кампании	Порог слишком мягкий или метрика не та	Разделить правило, сузить область

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

Что ловит режим «только показать»

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

Два инструмента ловят разные классы ошибок. Бэктест обнажает изъяны логики; «только показать» вытаскивает проблемы потока данных и тайминга — задержку синхронизации, метрики, которые устаканиваются лишь к концу дня, понимание, что правилу нужно работать в выбранные дни и часы, а не каждый час. Список решений, накопленный за неделю в этом режиме, убеждает сильнее таблицы за 28 дней: каждой строке соответствует кампания, которую можно открыть прямо сейчас.

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

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

Как только правило переведено в автоматический режим, работа бэктеста заканчивается и начинается измерение. У каждого применённого действия сравниваются периоды до и после равной длины, и это сравнение наблюдательное: причинности оно не утверждает. Оно не скажет «ROAS вырос благодаря правилу», а скажет «семь дней до действия выглядели так, семь дней после — так». Разницу важно сохранять: вышедший на той же неделе новый макет или сезонный сдвиг способны объяснить весь эффект сами по себе, поэтому тестирование креативов в отдельной системе заодно очищает и измерение автоматизации.

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

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

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

Когда правило пора выводить из работы

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

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

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

Частые вопросы

Может ли бэктест навредить кампаниям в аккаунте?

Нет. Бэктест только читает историю и сообщает, что сделало бы правило; в подключённый аккаунт не записывается ни одно значение. То же справедливо для режима «только показать» и для симуляции.

Бэктест дал 0 срабатываний — включать правило?

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

Можно ли взять окно длиннее 28 дней?

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

Почему реальный результат отличается от бэктеста?

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