Проверка качества данных: не принимать рекламные решения по сломанным данным

Вторник, 09:40. Кто-то из команды перформанса открывает панель: у летней кампании ROAS 0,4 при пороге правила 1,0. Правило собрано верно, условие написано верно, действие выбрано верно — кампания останавливается. Ближе к вечеру конверсии на стороне площадки догружаются, и дневная отдача той же кампании оказывается вдвое выше порога. Правило не ошиблось. Таблица, которая его кормила, была старше на девятнадцать часов, и часть конверсий ещё не была записана. Цифры здесь условные, но ситуация узнаваема: остановили не плохую кампанию, а фразу, прочитанную с наполовину пустой таблицы.

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

Где именно ломаются рекламные данные?

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

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

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

• Отложенные конверсии: ROAS, прочитанный до закрытия окна атрибуции, всегда занижен.
• Неполный день: незавершённые данные текущего дня попадают в дневной порог.
• Разные валюты: кабинет считает в одной валюте, порог написан в другой.
• Сдвиг часового пояса: день площадки и день отчёта начинаются в разное время.
• Дубли записей: одна конверсия учитывается и с площадки, и из CRM.

Что проверка качества данных подтверждает, а что нет?

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

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

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

Свежесть синхронизации: с какого возраста данные портят решение?

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

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

Проверка	На что смотрит	Пример порога	Если проверка не пройдена
Свежесть синхронизации	Последняя удачная выгрузка	Не старше 6 часов	Правило не запускается, причина в логе
Полнота данных	Непрерывность истории	Все 28 дней на месте	Правило остаётся черновиком
Валюта	Валюта кабинета и порога	Совпадают точно	Действия с бюджетом блокируются
Часовой пояс	Граница суток в кабинете и отчёте	Начинается в один час	Дневные пороги отключаются
Зрелость конверсий	Закрыто ли окно атрибуции	Последние 3 дня не в счёт	Остановка уходит на согласование

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

Сколько дней данных достаточно для остановки кампании?

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

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

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

Как расхождение валют и часовых поясов искажает решение по бюджету?

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

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

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

Почему при отложенных конверсиях смотреть на ROAS рано?

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

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

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

Что делать правилу, пока проверка не пройдена?

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

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

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

Как испытать правило до его включения?

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

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

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

Как превратить качество данных в еженедельную рутину?

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

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

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

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

Проверка качества данных полностью останавливает правило?

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

Нужно ли настраивать пороги отдельно для каждого аккаунта?

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

Если данные устарели, почему бы правилу не принять приблизительное решение?

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

Если проверка пройдена, значит ли это, что данные верны?

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