Сценарии

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

Пример триггера:

Этот же триггер в виде графа:

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

Список доступных узлов:

Источники

• Расписание

Условия

• Сравнение с группой
• Качество данных
• Сравнение с прошлым
• Проверка потока
• Эффект действия
• Условие по метрике
• Появление/пропажа
• Switch (эскалация)
• Тренд метрики

Действия

• Действие в сети
• Уведомление
• Действие в трекере

Трансформации

• Лимит действий
• Агрегат потока
• Фильтр объектов
• Обновить из снапшота
• Top / Bottom

Поток

• Слияние ветвей
• Ожидание

Как читать граф

По стрелкам между узлами течет поток объектов - набор объектов (что такое объект) вместе со статистикой из рекламной сети и трекера. Каждый узел получает поток на вход, что-то с ним делает и передает дальше через свои выходы.

У большинства узлов-условий три выхода:

• true - объекты, для которых условие выполнено
• false - объекты, для которых условие посчитано, но не выполнено
• no_data - объекты, для которых условие посчитать не удалось (нет значения метрики, мало истории и т.д.)

INFO

Разделение false и no_data - это не занудство, а точность. Объект без конверсий и объект с CPA ниже порога это две большие разницы. Первый уйдет в no_data, второй в false. В триггерах они были неразличимы, в сценариях вы сами решаете, что делать с каждым (например повесить на no_data уведомление).

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

Разберем каждый узел подробнее.

Источники

Расписание

Details

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

Поля:

• Расписание - интервал запуска сценария. Работает так же, как расписание у триггеров: чем чаще запуск, тем меньше боты и фродеры успеют слить из вашего бюджета.
• Период (дней) - за сколько дней забирать статистику. Полный аналог временного периода триггеров. Максимум индивидуален для каждой рекламной сети.
• Смещение периода - сдвиг забора статистики от "сегодня" в днях. Зачем это нужно, подробно расписано в разделе отступ у триггеров.
• Тип объекта - кампания / объявление / сайт (у некоторых сетей еще группа объявлений и другие). Определяет, что именно будет анализировать и обрабатывать весь сценарий: все узлы ниже по графу работают с объектами этого типа.
• Параллельные запуски - что делать, если пришло время нового запуска, а предыдущий еще работает:
  • Пропускать тик при живом запуске - новый запуск не стартует, ждем следующего расписания. Вариант по умолчанию и самый безопасный.
  • Разрешить параллельные - запуски работают одновременно. Осторожно: два параллельных запуска могут одновременно выполнять действия над одними и теми же объектами.
  • Отменять предыдущий - старый запуск отменяется, стартует новый. Полезно, если свежие данные всегда важнее незавершенной работы.
  • Ставить тик в очередь - новый запуск дождется завершения текущего и стартует сразу после него (в очереди помещается только один запуск).

INFO

Когда предыдущий запуск может быть "еще жив"? Например, если в сценарии есть узел ожидание на полчаса, а расписание - каждые 15 минут.

Условия

Сравнение с группой

Details

Сравнивает каждый объект с его собственной группой.

Пример: отключить площадку, у которой CPA на 70% выше медианы по кампании. Порог не нужно подбирать руками в абсолютных числах - он плавает вместе с кампанией.

INFO

Группа это все объекты статистики выбранного источника (вся кампания за период), а не суженный предыдущими узлами поток. Даже если до этого узла дошли 3 объекта, сравниваться они будут со всей кампанией.

Поля:

• Источник данных - откуда брать метрику, из рекламной сети или трекера. Что откуда лучше брать - читайте в условиях триггеров.
• Метрика - метрика для сравнения. Набор зависит от источника данных.
• Статистика группы - с чем сравниваем объект:
  • Среднее - среднее арифметическое по группе. Чувствительно к выбросам: один сайт-аномалия сдвинет базу.
  • Медиана - середина группы. Устойчива к выбросам, для CPA/ROI обычно лучший выбор.
  • Перцентиль - произвольная точка распределения. Например P75 по расходу - граница "дорогой четверти".
• Перцентиль (0-100) - какой перцентиль считать. Заполняется только если выбрана статистика "Перцентиль".
• Отклонение - в какую сторону ищем отклонение:
  • Выше группы - объект хуже/больше группы (для CPA, расхода)
  • Ниже группы - объект ниже группы (для ROI, CR)
• Порог отклонения, % - насколько процентов объект должен отклониться от групповой базы, чтобы уйти в true.

Выходы: true - отклонился на порог и больше, false - посчитан, но в пределах нормы, no_data - у объекта нет значения метрики (или база группы равна нулю).

Качество данных

Details

Гейт-предохранитель: проверяет, что данным вообще можно верить, ДО того как сценарий начнет что-то отключать.

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

Каждая проверка опциональна, но хотя бы одна должна быть заполнена:

• Макс. возраст снапшота, мин - насколько свежей должна быть последняя загруженная статистика по связке. Если данные старше - проверка провалена.
• Макс. расхождение расходов сеть/трекер, % - сравнивает сумму расходов по рекламной сети и по трекеру. Расходы никогда не совпадают точно, но если расхождение аномально большое - что-то сломалось (отвалился postback, слетела метка cost).
• Минимум объектов в статистике - если сеть вернула подозрительно мало объектов (обычно сайтов 500, а тут 3) - данные явно неполные.
• Макс. доля объектов без метрики, % - какой процент объектов может быть без значения выбранной метрики. При выборе этой проверки дополнительно указываются источник данных и метрика для проверки пропусков.

Выходы: true - данные пригодны, работаем дальше; false - проверки провалены, список проблем сохраняется в деталях запуска.

INFO

Правильное подключение: рабочую логику (условия и действия) вешаем на true, а на false - узел уведомление. Тогда при проблемах с данными действия просто не выполнятся, а вы получите сообщение о том, что именно не так.

Сравнение с прошлым

Details

Сравнивает текущее значение метрики со значением N дней назад.

Пример: ROI кампании упал на 30% по сравнению с той неделей - сбавить ставку и сообщить мне.

Поля:

• Источник данных - рекламная сеть или трекер.
• Метрика - что сравниваем.
• Направление - какое изменение ищем:
  • Вырос - метрика выросла на порог и больше
  • Снизился - метрика упала на порог и больше
  • Изменился - сдвиг в любую сторону на порог и больше
• Дней назад - с какой точкой в прошлом сравниваем (окно там будет той же длины, что и текущее).
• Порог изменения (в единицах режима) - величина изменения, начиная с которой объект уходит в true. В каких единицах - зависит от режима сравнения ниже.
• Режим сравнения - как измерять изменение:
  • Относительное изменение, % - классические проценты, режим по умолчанию. Порог 30 = "изменился на 30%".
  • Абсолютное изменение - разница "сейчас минус тогда" в единицах самой метрики. Незаменим для profit и ROI, которые могут переходить через ноль (проценты от ноля - математическая боль).
  • Процентные пункты - та же разница, но для процентных метрик. "CTR снизился на 0.3 п.п." звучит честнее, чем "CTR упал на 30%" при CTR 1%.
  • Во сколько раз - кратность. Порог 2 = "вырос минимум вдвое" (или упал минимум вдвое, для направления "Снизился"). Порог не может быть меньше 1.

INFO

Зачем столько режимов? Метрики около ноля дают бессмысленные проценты: CTR 0.01 → 0.02 это формально "+100%", хотя по факту ничего не произошло. Выбирайте режим под метрику: деньги и объемы - проценты, ROI/profit - абсолют, CTR/CR - процентные пункты.

Выходы: true - изменение прошло порог, false - посчитано, но порог не пройден, no_data - нет текущего значения или нет точки в прошлом (история накапливается с момента запуска сценариев по связке; при публикации недостающая история добирается автоматически).

Проверка потока

Details

Простое условие по произвольному полю потока. В отличие от остальных условий, работает не с объектами по отдельности, а с потоком целиком: весь поток уходит либо в true, либо в false.

Пример: если после фильтрации осталось больше 20 объектов - не отключать, а сообщить (в связке с узлом агрегат потока).

Поля:

• Поле - путь к полю потока через точку. Самые полезные:
  • selection.matched_objects - текущий набор объектов потока (сравнивается по количеству)
  • metadata.aggregate.value - результат узла агрегат потока
  • stats.network / stats.tracker - статистика источника (по количеству строк)
• Оператор - равно / не равно / больше / меньше.
• Значение - с чем сравниваем.

INFO

Для списков и словарей сравнивается их длина. То есть условие selection.matched_objects больше 5 означает "в потоке больше 5 объектов".

Выходы: true / false - весь поток без изменений.

Эффект действия

Details

Отвечает на вопрос "а помогло ли то, что мы сделали?". Находит последнее выполненное действие над объектом, делит историю метрики на "до" и "после" (сам день действия исключается как смешанный) и сравнивает средние.

Пример: если после снижения ставки CPA так и не улучшился - отключить площадку совсем.

Поля:

• Источник данных - рекламная сеть или трекер.
• Метрика - по какой метрике оцениваем эффект.
• Слаг действия (пусто - любое) - оценивать эффект конкретного действия (например set_coeff) или последнего действия вообще.
• Оценка эффекта - что считаем результатом:
  • Улучшилась - метрика изменилась в хорошую сторону. Узел сам знает полярность: для расхода, CPA и CPC "лучше" значит "меньше", для остальных - "больше".
  • Ухудшилась - метрика изменилась в плохую сторону.
  • Изменилась - сдвиг в любую сторону.
• Порог изменения, % - насколько процентов должны отличаться средние "до" и "после".
• Минимум точек с каждой стороны - сколько дней статистики должно быть и до, и после действия, чтобы сравнение имело смысл (по умолчанию 2).
• Мин. дней после действия (стабилизация) - не оценивать эффект раньше, чем пройдет столько дней после действия. Аукционы перестраиваются не мгновенно - дайте изменению отработать.
• Окно наблюдения, дней - глубина истории вокруг действия (по умолчанию 14).

Выходы: true - эффект есть и прошел порог, false - эффект посчитан, но порога не достиг, no_data - действия не было, мало точек с какой-то стороны, идет стабилизация или после оцениваемого действия было другое (эффект уже "загрязнен" - честно посчитать нельзя).

INFO

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

Условие по метрике

Details

Рабочая лошадка - прямой аналог условия триггера. Проверяет метрику каждого объекта против порога.

Поля:

• Источник данных - рекламная сеть или трекер. Что откуда брать.
• Метрика - набор зависит от источника и конкретной рекламной сети / трекера.
• Оператор - равно / не равно / больше / меньше.
• Значение - целое число или число с плавающей точкой.
• Игнорировать ID (через запятую) - объекты из этого списка становятся невидимыми для узла и не попадают ни в один выход. Аналог списка игнорирования в блоках триггеров.

Выходы: true - условие выполнено, false - метрика есть, но условие не выполнено, no_data - у объекта нет значения этой метрики.

DANGER

Как и в триггерах - учитывайте валюту рекламной сети.

Появление/пропажа

Details

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

Кейс на пропажу: "сайт, который стабильно приносил профит, пропал из ротации - надо разбираться".

Поля:

• Источник данных - рекламная сеть или трекер.
• Режим:
  • Появился - объект есть в текущей статистике, но не встречался за окно наблюдения.
  • Пропал - объект был в истории, но в текущей статистике отсутствует.
• Окно наблюдения, дней - сколько дней истории считать "прошлым".
• Каким был раньше: метрика / оператор / значение - опциональный квалификатор: условие на среднее историческое значение метрики. Заполняется либо целиком (все три поля), либо никак. Пример: "был доходным и пропал" = метрика profit, оператор больше, значение 0.

Выходы: true - появившиеся/пропавшие (прошедшие квалификатор, если он задан), false - остальные объекты, no_data - кандидат без исторических значений метрики квалификатора.

INFO

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

Switch (эскалация)

Details

Несколько условий с приоритетом: объект уходит в выход ПЕРВОГО подошедшего кейса и в следующих уже не участвует.

Пример: лестница блэклиста - "расход > 50 без конверсий → отключить; расход > 20 → срезать коэффициент; расход > 10 → уведомить". В триггерах пришлось бы городить три параллельных блока, и объект мог сработать во всех трех сразу.

Поля:

• Игнорировать ID (через запятую) - эти объекты не участвуют ни в одном кейсе.
• Кейсы - упорядоченный список. Каждый кейс это:
  • набор условий (источник данных / метрика / оператор / значение - как в условии по метрике), объединенных по И - сработают объекты, подошедшие под все условия кейса сразу;
  • собственный выход узла, к которому подключается своя ветвь действий.

Объекты, не подошедшие ни под один кейс, уходят в выход default.

INFO

Порядок кейсов решает все: ставьте самые строгие условия (самые высокие пороги) первыми, иначе мягкий кейс перехватит объекты раньше строгого.

Тренд метрики

Details

Ловит устойчивое движение метрики на дистанции, а не разовый скачок. По ряду дневных значений строится линейная регрессия - шумные качели вверх-вниз трендом не считаются.

Пример: CR площадки плавно сползает уже неделю - выключить, пока не сполз в ноль.

Поля:

• Источник данных - рекламная сеть или трекер.
• Метрика - по чему ищем тренд.
• Направление:
  • Снижение - метрика устойчиво падает
  • Рост - метрика устойчиво растет
• Окно наблюдения, дней - глубина ряда (от 3 до 45 дней).
• Минимум точек - сколько дней со значением метрики нужно для расчета (по умолчанию 3). Дыры в ряду допустимы.
• Порог изменения, % - насколько процентов метрика должна измениться за окно (по линии тренда), чтобы объект ушел в true.
• Мин. устойчивость тренда (R²) - фильтр шума от 0 до 1. R² показывает, насколько точки легли на прямую: 1 - идеальная линия, около 0 - хаос. Значения 0.5–0.7 отсекают большинство случайных качелей.
• Мин. ненулевых точек - сколько дней с ненулевым значением должно быть в ряду. Защита от "трендов" на рядах из нолей с парой всплесков.
• Макс. пропусков в окне, дней - сколько дней без данных допустимо. Больше - объект не оценивается.
• Мин. объём за окно + Метрика объёма - минимальный суммарный объем трафика за окно (по умолчанию метрика объема - показы). "CTR упал на 30%" при 20 показах - это не тренд, это статистическая пыль.

Выходы: true - устойчивый тренд нужного направления с изменением от порога, false - тренд посчитан, но не подошел (в том числе неустойчивый - с R² ниже гейта), no_data - мало точек, слишком много пропусков, мало объема или ноль в базе расчета.

INFO

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

Действия

Действие в сети

Details

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

Поля:

• Действие - что делаем. Для действий с параметром (установить цену / коэффициент) дополнительно вводится значение.
• Пауза повтора, мин - минимальный интервал между повторными действиями над одним и тем же объектом. Защита от "дребезга", когда объект балансирует на грани условия и сценарий дергает его каждый запуск.
• Повторное применение:
  • Пропускать уже применённое - если действие над объектом уже выполнялось и с тех пор ничего не менялось, повторно не выполнять. Вариант по умолчанию: не долбить API сети одинаковыми запросами.
  • Выполнять всегда - выполнять при каждом срабатывании. Нужно редко, например если объект кто-то включает обратно руками.

Выходы: main - весь поток идет дальше (статусы каждого объекта сохраняются в деталях запуска), failed - объекты, над которыми действие не удалось (повесьте сюда уведомление - узнаете о проблемах с API сети первым), skipped - объекты, пропущенные из-за паузы повтора или политики повторного применения.

Уведомление

Details

Отправляет сообщение в ваши каналы уведомлений. Список объектов, дошедших до узла (например ID отключенных сайтов), добавляется в сообщение автоматически.

Поля:

• Сообщение - текст. Поддерживаются макросы (клик по кнопке на форме вставляет макрос в текст):
  • {{matched_objects}} - совпавшие объекты списком
  • {{processed_objects}} - обработанные объекты списком
  • {{matched_count}} / {{processed_count}} - количество совпавших / обработанных
  • {{campaign_name}} / {{campaign_id}} - название и ID кампании
  • {{binding_id}} - ID связки
  • {{workflow_name}} / {{workflow_id}} - название и ID сценария
  • {{time_frame}} - период статистики в днях
  • {{run_id}} - ID запуска
• Когда отправлять:
  • Есть объекты или текст - вариант по умолчанию: шлем, если есть объекты или непустое сообщение.
  • Только при объектах - тишина, пока поток пуст. Спасает от сообщений "Проверка завершена, 0 объектов" каждые 15 минут.
  • Всегда - шлем при каждом срабатывании. Подходит для heartbeat-контроля, что сценарий вообще живой.
• Не чаще, мин - троттлинг: не больше одного сообщения от этого узла за указанное окно. Подавленные отправки помечаются в деталях запуска.

INFO

В список попадает не больше 50 объектов, длина сообщения ограничена 3500 символами - Telegram не резиновый.

Действие в трекере

Details

Выполняет действие в трекере над объектами потока. Как и у триггеров, действия трекеров косметические - метки BlackList/WhiteList и подобное - но с ними результаты работы сценария видны прямо в отчетах трекера.

Поля:

• Действие - что делаем, набор зависит от трекера.
• Пауза повтора, мин - как у действия в сети.
• Повторное применение - как у действия в сети: Пропускать уже применённое (по умолчанию) или Выполнять всегда.

Выходы: main / failed / skipped - так же, как у Действия в сети.

Трансформации

Лимит действий

Details

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

Каждый лимит опционален, нужен хотя бы один. Если заданы несколько - применяется самый строгий:

• Не более N объектов - жесткий потолок на количество объектов за запуск.
• Не более X% объектов статистики - потолок как доля от всех объектов кампании. Удобно, когда количество сайтов в кампании плавает.
• Не более X% суммы метрики - потолок как доля от суммы метрики (при выборе указываются источник и метрика доли, обычно расход). "Не отключать за раз сайты более чем на 20% расхода кампании".
• Не более N действий за сутки - суточный бюджет действий сценария. Считаются реально выполненные действия за последние 24 часа.

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

Агрегат потока

Details

Считает одно число по всему потоку и кладет его в поток. Сам решений не принимает - решение принимает следующий за ним узел проверка потока по полю metadata.aggregate.value.

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

Поля:

• Источник данных - рекламная сеть или трекер.
• Метрика - по какой метрике считаем.
• Функция:
  • Количество объектов - сколько объектов в потоке
  • Сумма - сумма метрики по потоку
  • Среднее - среднее арифметическое
  • Взвешенное среднее - среднее с весами по другой метрике. Например средний CPA, взвешенный по расходу: дорогие площадки влияют сильнее.
  • Медиана - середина распределения, устойчива к выбросам
  • Минимум / Максимум - крайние значения
  • Перцентиль - произвольная точка распределения (дополнительно указывается перцентиль 0-100)
  • Доля прошедших объектов - доля объектов потока от всех объектов статистики. "Под условие попало 80% сайтов" - вероятно, проблема не в сайтах, а в данных.
• Метрика веса (для взвешенного среднего) - по какой метрике взвешивать (по умолчанию расход).

Выход: main - поток без изменений плюс посчитанный агрегат.

Фильтр объектов

Details

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

Пример: дальше пропускать только сайты с расходом больше 0 - чтобы тяжелые условия ниже не месили пустышки.

Поля:

• Источник данных / Метрика / Оператор / Значение - метрик-условие, как в условии по метрике. Заполняется целиком либо не заполняется вовсе.
• Игнорировать ID (через запятую) - исключить перечисленные ID из потока. Можно использовать и без метрик-условия - тогда узел работает как чистый список игнорирования.

Выход: main - суженный поток (может оказаться и пустым, тогда узлы ниже отработают вхолостую без действий).

Обновить из снапшота

Details

Обновляет статистику в потоке из последних сохраненных данных - БЕЗ запроса к рекламной сети или трекеру.

Кейс - связка с ожиданием: установили коэффициент → подождали → обновили статистику → проверили метрику. Без этого узла условие после паузы видело бы данные на момент старта запуска.

Поля:

• Источник данных - что обновлять: сеть / трекер / оба (по умолчанию оба).

Выход: main - поток со свежей статистикой. Выбор объектов, сделанный предыдущими узлами, сохраняется.

INFO

Свежесть данных равна свежести последнего фонового забора статистики по связке - узел не заставляет сеть пересчитать статистику, а берет то, что уже загружено.

Top / Bottom

Details

Отбирает крайние объекты по метрике. Кейс: "показать топ-5 сайтов по расходу без конверсий" или "работать только с сайтами, которые дают 80% расхода кампании" - остальной хвост не трогать.

Поля:

• Источник данных - рекламная сеть или трекер.
• Метрика - по чему сортируем.
• Режим:
  • Top N - N объектов с наибольшим значением
  • Bottom N - N объектов с наименьшим значением
  • Top X% объектов - верхние X% объектов по значению
  • Bottom X% объектов - нижние X% объектов
  • Формирующие X% метрики - объекты, которые в сумме дают X% от общей суммы метрики (классика: 20% сайтов, дающих 80% расхода)
• N или процент - число для режимов Top/Bottom N, процент (до 100) для остальных.

Выход: main - суженный поток. Объекты без значения метрики в отборе не участвуют и отбрасываются.

Поток

Слияние ветвей

Details

Сводит несколько ветвей графа в одну. Ждет все входящие ветви и сливает их наборы объектов.

Поля:

• Режим слияния:
  • Объединение - объекты, пришедшие хотя бы по одной ветви. Например "отключили ИЛИ уведомили" - все в одну итоговую сводку.
  • Пересечение - только объекты, пришедшие по ВСЕМ ветвям. Главный кейс: объект должен пройти два независимых условия сразу, например "CPA выше медианы группы" И "тренд CR снижается" - двойное подтверждение перед отключением.

Выход: main - слитый поток.

INFO

Узел ждет все подключенные ветви. Если какая-то ветвь до него не дошла (ее объекты закончились на условии выше), узел будет пропущен - для пересечения это логично: нет одной ветви, нет и пересечения.

Ожидание

Details

Ставит ветвь на паузу. Кейс: выполнили действие → подождали → обновили статистику → проверили, что получилось.

Поля:

• Секунды - длительность паузы. Максимум 86400 секунд (сутки).

Выход: main - поток без изменений, но позже.

INFO

Пауза держит запуск сценария "живым" - не забудьте про политику параллельных запусков в Расписании, если пауза длиннее интервала запуска.