Кто виноват в сливе рекламного бюджета?
При создании рекламного line item рекламодатель устанавливает бюджет - N долларов в день.
С точки зрения любого line item стратегия (в Х) простая: в каждом аукционе он делает ставку из расчёта k долларов за целевое действие (показ, клик, покупка): k * p(event). Значение k определяет компонента под названием пэйсинг (pacing).
Количество выигранных аукционов в течение дня, а также потраченный бюджет - строго монотонная функция от k. Пэйсинг занимается подбором такого k, чтобы было потрачено ровно N долларов за день.
На практике возникает неловкая ситуация. Пэйсинг как будто бы компонента, принимающее важное решение, от которого зависят все метрики рекламодателя, а не просто маленькая калибровочная компонента. И он получает все косые взгляды в момент, когда что-то идёт не так.
Команде бэкэнда одним непримательным утром пришла стопка жалоб от рекламодателей - в районе 7 утра у многих сильно скакнули стоимости показов, и бюджет на два часа был слит за 15 минут. Разумеется, все пошли искать какие-то инциденты в пэйсинге и проверять, почему у него поехала крыша.
Той же ночью произощёл ещё один инцидент, в котором копалась команда моделинга - ночью поплавилась одна инфровая компонента и в результате очень сильно упал Success Rate модели с 4 до 6 утра, после чего выкатили фикс.
На общей встрече рекламы, когда рассказали про проблему со слитым бюджетом, почесав репу, я на опыте предположил, что эти 2 инцидента связаны, и что именно произошло, и оказался в точности прав - мелочь, а приятно.
Когда бэкэнд, считающий p(event) с помощью вызова инференс движка модели, получал 🖕вместо ответа, он использовал 0 в качестве p(event). Таким образом, у оптимизирующих клики или продажи ставка за показ превращалась в 0 и они не могли выиграть в аукционах.
Видя, что бюджет тратится сильно медленнее целевой скорости, пэйсинг начинает накручивать k - стоимость события, и в итоге нарастил его в несколько раз у многих line item. Условно, в трубе, засоренной на 80%, пэйсинг увеличил давление в 5 раз, чтобы вся вода успела протечь.
В чудо-момент, в который мы чиним инференс, Success Rate взлетает до 100%, и все участники аукциона стали получать честный p(event). Нормальный p(event), умноженный на раздутый k, дал всем огромную стоимость показов, которую все дружно заплатили.
Два урока, который мы из этого вынесли - во-первых, fallback не должен быть нулевой - какое угодно плохое предсказание среднего не возбудило бы пэйсинг так сильно. Во-вторых, внезапно, но в случае больших проблем с моделью восстанавливать норму нужно медленно, потому что пэйсинг поддерживает хрупкий баланс в системе и ему нужно давать время на подумать. Уже через пару недель, когда у нас сломался чекпоинт ретривала, я не выкатывал фикс на весь движок, а выкатывал вручную, начиная с 1 ноды, потом 2, 4 и т.д., и тем самым избежал повторения ситуации.
@knowledge_accumulator
При создании рекламного line item рекламодатель устанавливает бюджет - N долларов в день.
С точки зрения любого line item стратегия (в Х) простая: в каждом аукционе он делает ставку из расчёта k долларов за целевое действие (показ, клик, покупка): k * p(event). Значение k определяет компонента под названием пэйсинг (pacing).
Количество выигранных аукционов в течение дня, а также потраченный бюджет - строго монотонная функция от k. Пэйсинг занимается подбором такого k, чтобы было потрачено ровно N долларов за день.
На практике возникает неловкая ситуация. Пэйсинг как будто бы компонента, принимающее важное решение, от которого зависят все метрики рекламодателя, а не просто маленькая калибровочная компонента. И он получает все косые взгляды в момент, когда что-то идёт не так.
Команде бэкэнда одним непримательным утром пришла стопка жалоб от рекламодателей - в районе 7 утра у многих сильно скакнули стоимости показов, и бюджет на два часа был слит за 15 минут. Разумеется, все пошли искать какие-то инциденты в пэйсинге и проверять, почему у него поехала крыша.
Той же ночью произощёл ещё один инцидент, в котором копалась команда моделинга - ночью поплавилась одна инфровая компонента и в результате очень сильно упал Success Rate модели с 4 до 6 утра, после чего выкатили фикс.
На общей встрече рекламы, когда рассказали про проблему со слитым бюджетом, почесав репу, я на опыте предположил, что эти 2 инцидента связаны, и что именно произошло, и оказался в точности прав - мелочь, а приятно.
Когда бэкэнд, считающий p(event) с помощью вызова инференс движка модели, получал 🖕вместо ответа, он использовал 0 в качестве p(event). Таким образом, у оптимизирующих клики или продажи ставка за показ превращалась в 0 и они не могли выиграть в аукционах.
Видя, что бюджет тратится сильно медленнее целевой скорости, пэйсинг начинает накручивать k - стоимость события, и в итоге нарастил его в несколько раз у многих line item. Условно, в трубе, засоренной на 80%, пэйсинг увеличил давление в 5 раз, чтобы вся вода успела протечь.
В чудо-момент, в который мы чиним инференс, Success Rate взлетает до 100%, и все участники аукциона стали получать честный p(event). Нормальный p(event), умноженный на раздутый k, дал всем огромную стоимость показов, которую все дружно заплатили.
Два урока, который мы из этого вынесли - во-первых, fallback не должен быть нулевой - какое угодно плохое предсказание среднего не возбудило бы пэйсинг так сильно. Во-вторых, внезапно, но в случае больших проблем с моделью восстанавливать норму нужно медленно, потому что пэйсинг поддерживает хрупкий баланс в системе и ему нужно давать время на подумать. Уже через пару недель, когда у нас сломался чекпоинт ретривала, я не выкатывал фикс на весь движок, а выкатывал вручную, начиная с 1 ноды, потом 2, 4 и т.д., и тем самым избежал повторения ситуации.
@knowledge_accumulator