Розклад, захисти та пріоритети

Ця стаття про те, коли правило перевіряє об'єкти, що не дає йому діяти занадто часто або поверх ручної роботи баєра і хто перемагає, якщо на один об'єкт претендують кілька правил. Налаштування знаходяться на кроках «Розклад» та «Захисти та сповіщення» конструктора, пріоритет — на кроці «Назва та кабінети».

Розклад: як часто правило перевіряє об'єкти

Що важливо знати:

• Нове правило створюється з періодичністю «Кожну годину» і без вікон активності.

• Планувальник перевіряє правила раз на 5 хвилин, тому фактичний запуск може бути на кілька хвилин пізніше розкладу. При великій черзі кабінетів (за один прохід обробляється до 50 кабінетів) — ще пізніше.

• «Раз на добу» (1440 хвилин) не прив'язаний до часу: наступний запуск — через 24 години після попереднього. Потрібен запуск у конкретний час — обирайте «Щоденно».

• Пропущений час не надолужується. Якщо система не працювала три години, погодинне правило запуститься один раз, а не три. Рішення все одно приймається за свіжими даними, і серія запусків підряд нічого б не додала.

• Розклад рахується окремо для кожного кабінету правила.

Вікна активності

Вікна активності обмежують, в які дні та години правило взагалі може запускатися. Вікон немає — правило працює цілодобово («Вікон немає: правило працює цілодобово»).

• Вікно — це дні тижня (Пн–Нд) і відрізок доби «з — по». Кінець вікна не включається: вікно 06:00–18:00 закривається рівно о 18:00. «24:00» — кінець доби.

• Вікно не може переходити через північ. Нічний інтервал задається двома вікнами: наприклад, «22:00–24:00» і «00:00–06:00».

• Вікна одного дня не повинні перетинатися — інакше «Вікна активності перетинаються».

• Вікно не може бути порожнім («з» повинно бути раніше «по») — інакше «Вікно активності порожнє».

• У «Щоденно» та «В задані години» кожен час запуску повинен потрапляти у вікно — інакше «Час запуску поза вікнами активності».

• Всього вікон — до 28. Нове вікно в конструкторі створюється як «будні, 06:00–24:00».

Як вікна поєднуються з періодичністю:

• Кожні N хвилин: поза вікна правило не запускається, всередині — запускається з заданим інтервалом. Коли вікно відкривається, перший запуск відбувається на найближчій перевірці планувальника.

• Щоденно / в задані години: час поза вікном свого дня не спрацьовує зовсім. Наприклад, при вікні Пн–Пт час 09:00 у неділю не спрацює і в понеділок не «дожене». Час у самому кінці вікна (наприклад, 17:57 при вікні до 18:00) виконуватиметься, навіть якщо планувальник дійшов до правила через кілька хвилин після закриття вікна.

Приклад: масштабування тільки з 00:00 до 18:00, стоп-лосс цілодобово

Завдання: масштабувати прибуткові адсети тільки в першій половині дня за часом кабінету, щоб Facebook встиг прокрутити новий бюджет, а стоп-лосс тримати включеним завжди.

• О 10:00 працюють обидва правила. Якщо обидва спрацювали на одному адсеті, перемагає пауза — вона завжди сильніша підвищення бюджету.

• О 19:00 масштабування не запускається, стоп-лосс продовжує слідкувати за витратами.

• О 00:00 вікно масштабування знову відкривається, і правило запускається на найближчій перевірці.

Порада. Якщо масштабування дивиться на «вчора» або «N повних днів» по когорті, починайте вікно не з 00:00, а з 06:00: в перші години доби депозити по вчорашнім вечірнім клікам ще доїжджають, і ROI за вчора занижений. Так зроблено в шаблонах «Масштабування прибуткових» та «Урізання збиткових» — у них вікно 06:00–24:00.

Приклад: тільки вночі

Сповіщення про стрибок CPM потрібно тільки вночі, коли ніхто не дивиться кабінет. Вікна: «Пн–Нд, 22:00–24:00» та «Пн–Нд, 00:00–06:00», періодичність «Кожну годину».

Приклад: тільки в будні в робочий час

Вікно «Пн–Пт, 09:00–21:00», періодичність «Щоденно» о 10:00 та 16:00. У вихідні правило не запускається.

Часовий пояс — у кожного кабінету свій

У правила немає свого часового поясу. Розклад, вікна активності, «сьогодні» та «вчора» в умовах, доба для ліміту дій та включення о 00:00 рахуються за часовим поясом кожного кабінету окремо. Конструктор показує пояси вибраних кабінетів на кроці «Розклад».

Приклад. Правило з вікном 00:00–18:00 на двох кабінетах: Europe/Kyiv та America/New_York. У київському кабінеті вікно відкриється опівночі по Києву, у нью-йоркському — опівночі по Нью-Йорку, тобто на кілька годин пізніше. Кожен кабінет живе за своїми годинами.

Захисти

Захисти рахуються для пари «правило — об'єкт»: дії інших правил не витрачають ліміти цього правила.

Перерва після дії

• Відраховується в звичайних годинах від моменту дії і йде через північ: перерва 12 годин після дії о 20:00 закінчиться о 08:00.

• Діє на всі дії правила по об'єкту, включаючи сповіщення — інакше повідомлення приходило б кожен прогон, поки умова тримається.

• Виключення — правило з паузою до кінця дня: його перерва закінчується не пізніше ввімкнення о 00:00, щоб вранці правило знову слідкувало за об'єктом. Саме ввімкнення о 00:00 перерва не запускає.

• Якщо результат попередньої дії ще не підтвердив Facebook, правило не повторює дію по тих же даних: «Пропущено: пауза між діями» з причиною «Попередню дію ще не підтверджено».

Приклад. Масштабування «+20 % при ROI вчора більше 50 %» запускається кожну годину, перерва 24 години. Бюджет підняли в понеділок о 07:00 — наступне підвищення по цьому адсету можливе не раніше вівторка о 07:00. Без перерви правило піднімало б бюджет кожну годину, поки ROI за вчора не зміниться.

Дій на об'єкт за добу

• Доба — за часовим поясом кабінету, лічильник обнуляється о 00:00 за часом кабінету.

• Сповіщення рахуються, системне ввімкнення о 00:00 — ні.

• Працює разом з перервою: перерва задає паузу між діями, ліміт — стелю на добу.

Приклад. Правило «Сповістити, якщо CPI за 24 години вище $3» з перервою 4 години та лімітом 2: навіть якщо CPI високий увесь день, по одному адсету прийде не більше двох сповіщень за добу.

Пауза після ручної зміни

• Ручною рахується зміна у Facebook або Ads Manager, зміна користувачем в Adset.pro та скасування дії правила в журналі. Зміни, які зробили автоправила, ручними не рахуються.

• Захист розділений за полями: після ручної зміни статусу правило не торкається статусу, але може змінювати бюджет; після ручної зміни бюджету — навпаки.

• Сповіщення цьому захисту не підпорядковуються.

• Значення 0 — не чекати. Але навіть з 0 правило ніколи не включить об'єкт, який вимкнула людина (див. нижче).

Приклад. Стоп-лосс поставив адсет на паузу до кінця дня о 14:00. Баєр бачить, що депозити просто затримуються, і о 15:00 включає адсет в Ads Manager. У стоп-лосса перерва 0, і без цього захисту він вимкнув би адсет на наступному прогоні о 15:30. З паузою після ручної зміни 24 години правило не торкнеться статусу адсета до 15:00 наступного дня.

Допустиме відставання даних

Перед кожним прогоном правило перевіряє, наскільки свіжі дані витрат Facebook і конверсій трекера по кабінету. Якщо вони старші порога, прогон пропускається цілком — краще не діяти, ніж діяти за застарілою витратою.

Причини пропуску, які видно в журналі: «Жоден профіль не синхронізує кабінет», «Синхронізація Facebook впала на всіх профілях», «Витрати Facebook ще не синхронізувалися», «Синхронізація витрат Facebook відстає», «Свіжість конверсій трекера невідома», «Конверсії трекера відстають».

Щоб дізнаватися про такі пропуски одразу, увімкніть подію «Застарілі дані» в «Сповіщати про події» (за замовчуванням увімкнені тільки «Дії» та «Помилки»).

Порада. Для стоп-лосса тримайте поріг 60–90 хвилин: рішення «втратив без депозитів» за витратою тригодинної давності небезпечніше пропуску. Для правил з вікнами «вчора» та «N повних днів» поріг можна підняти.

Ліміт бюджету кабінету

Стеля суми добових бюджетів усіх активних CBO-кампаній та ABO-адсетів кабінету. Перевіряється при підвищенні добового бюджету та при включенні об'єкта правилом, у якого заданий ліміт. Якщо місця менше, ніж просить дія, підвищення урізається до залишку; місця немає — дія пропускається. Докладний приклад — в статті «Дії».

Важливо. Ліміт задається в правилі і діє тільки на його дії. Ручні підвищення та правила без ліміту він не стримує. Якщо кілька масштабуючих правил працюють на одному кабінеті, задайте ліміт у кожному.

Пріоритети та конфлікти правил

Пріоритет задається на кроці «Назва та кабінети»: число від 1 до 100, за замовчуванням 50. Підказка в конструкторі: «при конфлікті правил одного кабінету перемагає більший пріоритет; пауза завжди сильніша підвищення бюджету».

Правила одного кабінету, яким пора запускатися, обробляються разом, і конфлікти між ними вирішуються так:

1. Пауза сильніша за все. Пауза перемагає включення і підвищення бюджету незалежно від пріоритету.

2. Постійна пауза сильніша за паузу до кінця дня — навіть якщо у правила з паузою до кінця дня пріоритет вищий. Інакше об'єкт включився б о 00:00 всупереч правилу, яке хотіло вимкнути його назавжди.

3. Далі — за пріоритетом. Статус об'єкта змінює одне правило — з більшим пріоритетом. Бюджет об'єкта (кожен вид бюджету) також змінює одне правило — з більшим пріоритетом.

4. Хто зайняв статус, той зайняв об'єкт. Якщо правило з більшим пріоритетом ставить об'єкт на паузу або включає його, бюджетні дії правил з меншим пріоритетом по цьому об'єкту пропускаються.

5. При рівному пріоритеті перемагає правило, створене раніше.

6. Пропущене не заважає. Дія, відхилена захистом або лімітом, об'єкт не займає: наприклад, пауза, яка чекає закінчення перерви, не блокує чуже підвищення бюджету.

7. Сповіщення не конфліктують ні з чим.

8. Тестові правила не заважають бойовим. Правило в режимі Dry-run нічого не займає. Його симуляція враховується разом з усіма бойовими правилами кабінету, тому журнал тесту показує, що було б з урахуванням бойових правил. Тестові правила одне з одним не конфліктують.

В журналі програна дія позначається «Пропущено: конфлікт з іншим правилом» з причиною і посиланням «Перемогло правило …».

Сценарії: правило А (пріоритет 80) та правило Б (пріоритет 30) на одному адсеті

Важливо. Конфлікти вирішуються між правилами, які запускаються по кабінету в одному прогоні. Якщо у правил різний розклад, кожне діє в свій прогон: масштабування підніме бюджет о 10:00, а стоп-лосс о 10:30 все одно поставить адсет на паузу. Від «пінг-понга» між правилами захищають перерва після дії та ліміт дій за добу.

Порада. Задайте пріоритети усвідомлено: стоп-лоссам і kill-правилам — високий (80–100), масштабуванню — середній (50), сповіщенням — будь-який. Тоді при будь-якому збігу розкладів захисні правила будуть важливішими.

Ручні зміни в Ads Manager: як правило їх поважає

Баєр завжди важливіший за правило. Ось що правило робить, щоб не перетирати ручну роботу:

• Не включає вимкнене людиною. Дія «Активний» включає об'єкт, тільки якщо останню зміну статусу зробило автоправило. Якщо об'єкт вимкнули в Ads Manager, в Adset.pro або скасуванням — «Пропущено: нещодавня ручна зміна» з причиною «Статус змінили вручну». Чекати тут безглуздо: правило не включить такий об'єкт ніколи, поки його знову не вимкне яке-небудь правило.

• Чекає після ручної правки. Пауза після ручної зміни (за замовчуванням 24 години) — окремо для статусу і бюджету.

• Звіряється з Facebook перед зміною. Якщо статус або бюджет змінилися між рішенням правила і відправкою зміни, дія пропускається: «Пропущено: об'єкт змінився» («Статус змінився після рішення» або «Бюджет змінився після рішення»).

• Не включає о 00:00 торкнуте людиною. Якщо об'єкт, поставлений на паузу до кінця дня, вручну змінювали або редагували в Facebook після паузи, включення о 00:00 скасовується, а власник правила отримує сповіщення.

• Не скасовує поверх чужих змін. Скасування дії в журналі відхиляється, якщо після дії об'єкт змінювали людина або інше правило.

• Ураховує ручні підвищення в ліміті зростання. Ліміт зростання за добу рахується від бюджету на початок доби: якщо баєр вже підняв бюджет вручну вище стелі, правило підвищувати не буде.

Правило дізнається про ручні зміни з синхронізації кабінету. Зміна, зроблена в Ads Manager між синхронізацією та дією правила, ловиться звіркою з Facebook перед відправкою.

Порада. Якщо ви часто правите бюджети вручну в першій половині дня, а правило масштабує вранці, збільшіть паузу після ручної зміни або зсуньте вікно активності правила, щоб не заважати один одному.

Читайте також

• Автоправила — всі статті розділу

• Дії: пауза, включення, бюджет, сповіщення

• Попередній перегляд, тестовий і бойовий режими

• Журнал: прогон, «Чому?» і скасування

• Сповіщення

• Чому правило не спрацювало