Дневной pacing рекламного бюджета: почасовой план и правила перераспределения

Редакция mevrica

Арбитраж трафика5 мин чтения

Обновлено 1 августа 2026 г.

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

Рабочая цель

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

Отделите три бюджета

• Финансовый лимит — максимально допустимый денежный отток команды
• Внутренняя дневная цель — сколько планируется направить в конкретный день
• Платформенная настройка бюджета — механизм доставки с собственными правилами списания и overdelivery

Эти значения могут не совпадать. Например, Google Ads описывает средний дневной бюджет и для большинства кампаний допускает дневное списание до удвоенного среднего при месячном лимите 30,4 среднего дневного бюджета. Это правило конкретной платформы, а не универсальная формула внутреннего pacing.

Постройте кривую возможности

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

WITH hourly AS (
  SELECT report_date, extract(hour FROM report_hour)::int AS hour,
         sum(spend_minor) AS spend_minor
  FROM campaign_hourly
  WHERE report_date BETWEEN :history_start AND :history_end
    AND is_anomalous_day = false
  GROUP BY 1,2
), shares AS (
  SELECT report_date, hour,
         sum(spend_minor) OVER (PARTITION BY report_date ORDER BY hour)
         / NULLIF(sum(spend_minor) OVER (PARTITION BY report_date),0)::numeric AS cumulative_share
  FROM hourly
)
SELECT hour,
       percentile_cont(0.5) WITHIN GROUP (ORDER BY cumulative_share) AS target_share
FROM shares
GROUP BY hour
ORDER BY hour;

Пример почасового плана

Это учебные значения, не готовый профиль для кабинета. Реальная кривая строится отдельно по GEO, дню недели, источнику и часовому поясу; суммы выражаются в выбранной валюте после документированной нормализации.

Ошибка pacing

В момент h рассчитайте target_spend_h = daily_target × target_share_h. Ошибка e_h = actual_spend_h − target_spend_h. Положительная ошибка означает опережение, отрицательная — отставание. Но действие выполняется только за пределами deadband: мелкие колебания не должны запускать постоянные правки.

target_spend = daily_target * cumulative_target_share[hour]
error_ratio = (actual_spend - target_spend) / max(target_spend, epsilon)

if data_lag > allowed_lag or quality_guard_failed:
    freeze changes
elif abs(error_ratio) <= deadband:
    keep current control
else:
    raw_step = -gain * error_ratio
    step = clamp(raw_step, -max_step, +max_step)
    apply only if time_since_last_change >= cooldown

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

Не догоняйте бюджет без доступной возможности

Если к 18:00 расход отстаёт, простое удвоение ставки может купить худший инвентарь. Рассчитайте remaining opportunity по историческому объёму и текущему прогнозу. Catch-up ограничивается минимальной маржой, cap оффера, скоростью лендинга и допустимой концентрацией источника.

planned_catch_up = max(0, target_spend_now - actual_spend)
safe_capacity = min(
  forecast_quality_inventory_value,
  offer_cap_value_remaining,
  cash_limit_remaining,
  operational_capacity_value
)
allowed_catch_up = min(planned_catch_up, safe_capacity)

Задержки создают раскачку

Расход, клики и конверсии приходят с разной задержкой. Если контроллер реагирует быстрее обновления затрат, он несколько раз исправит одну и ту же старую ошибку. Храните observed_at, source_event_time и freshness; при превышении SLA замораживайте автоматические изменения и показывайте оператору устаревший статус.

Guardrails качества

• Не ускорять расход при недоступном или медленном лендинге
• Не повышать доставку после достижения cap или денежного лимита
• Использовать только зрелые нижние метрики для оценки качества
• Ограничивать долю одного плейсмента или источника
• После крупного изменения выдерживать cooldown
• Останавливать автоматику при неполных расходах или нарушении временной зоны

Перераспределение между кампаниями

Свободный бюджет передаётся не кампании с самым высоким вчерашним ROI, а следующей доступной единице качественной возможности. Для кандидатов оценивают ожидаемую предельную маржу, неопределённость, remaining cap и способность принять дополнительный объём. Исторический средний результат не гарантирует такую же отдачу на следующем рубле.

Журнал решения

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

Недотрат не всегда является ошибкой

Если качественной возможности нет, сохранённый бюджет лучше принудительно купленного объёма ниже минимальной экономики. Финальный KPI pacing должен учитывать не только процент освоения, но и качество предельного расхода.

Источники и границы применимости

Google Ads: средний дневной бюджет и лимиты списания · Google Ads: pacing insights

Вывод

Надёжный дневной pacing начинается с исторической кривой возможности, а не с прямой линии. Целевой коридор, deadband, cooldown и ограниченный шаг защищают от раскачки; maturity и quality guardrails не дают догонять расход ценой плохого трафика. Бюджет считается освоенным только тогда, когда куплена допустимая возможность, а не просто достигнута цифра.