amBrain
AdTechOct 14, 202611 мин чтения

Чинить, переходить на управляемый сервис или перестраивать: во что обходится каждый путь, если пайплайн теряет рекламные события на пике

Измерение рекламыПайплайны событийУправляемые сервисыПочинка или перестройка
Ошибка загрузки изображения

Если пайплайн теряет рекламные события на пике, сначала посчитайте, во что вам за год обходится разрыв. Затем сравните с этой суммой починку, переход на управляемый сервис и перестройку.

Если ваш пайплайн рекламных событий теряет показы и клики на пике трафика, выхода три. Можно починить те части пайплайна, где события утекают, перевести на управляемый сервис серверы, которые передают и хранят события (часто это Kafka и ClickHouse), или перестроить пайплайн силами внешней компании. От выбранного пути зависит и то, кого нанимать. Для починки нужны инженеры внутри вашей команды, а для перестройки — компания, способная сделать пайплайн целиком и передать его вам. Прежде чем выбирать, посчитайте, во что вам за год обходится разрыв между отчётами по атрибуции и логами биддера. Затем сравните пути по стоимости, по тому, сколько контроля у вас остаётся, и по тому, как скоро снова придут в порядок цифры, по которым вы выставляете счета.

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

Во что нам обходится разрыв между отчётами по атрибуции и логами биддера?

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

За что вы платите, решает биржа. В OpenRTB 2.6 — стандарте IAB Tech Lab, по которому биржи и биддеры торгуют рекламой в реальном времени, — сказано, что биржа отправляет уведомление о биллинге, «когда выигравшая ставка становится оплачиваемой согласно бизнес-политике конкретной биржи». Каждая биржа выставляет вам счета по своей политике и по своим записям, а рекламодателям вы выставляете счета по своим отчётам. Каждый показ, который теряет ваш пайплайн, вы оплатили, но так и не включили в счёт. Показ, посчитанный дважды, дважды попадает в счёт, и вы возвращаете эти деньги рекламодателю в виде компенсации, когда его собственный подсчёт расходится с вашим.

Возьмём круглые цифры, а не чьи-то реальные данные. Платформа покупает 500 миллионов показов в месяц и перепродаёт их рекламодателям по 2 доллара за тысячу. Если она теряет 3 процента событий показов, 15 миллионов показов не попадают в счета, а это 30 000 долларов в месяц, или 360 000 долларов в год, без учёта дублей и компенсаций.

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

Годовая сумма — примерный потолок того, во что должен обойтись путь. Если путь стоит дороже разрыва, который он устраняет, нужна другая причина его выбрать — например, текущий пайплайн не выдержит роста трафика.

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

Сколько стоит каждый путь в деньгах?

Починку и перестройку оплачивают в основном как проекты. Управляемый сервис добавляет ежемесячный счёт на всё время, пока вы им пользуетесь.

За починку текущего пайплайна вы платите временем инженеров — своих собственных или внешних, работающих внутри вашей команды. Новой подписки нет. Заложите второй раунд исправлений: первый загруженный период после них часто вскрывает следующее узкое место.

Управляемый сервис выставляет счёт каждый месяц, и часть суммы начисляется за каждый гигабайт событий, так что счёт меняется вместе с вашим трафиком. Всё, что работает за пределами серверов провайдера, ваши инженеры по-прежнему эксплуатируют сами. Amazon MSK Serverless — один из вариантов управляемого сервиса AWS для Kafka (очереди, которая хранит события на пути от сбора к базе данных). На его странице с ценами по состоянию на 14 октября 2026 года указан почасовой тариф за каждый кластер, то есть за каждую отдельную установку сервиса, и за каждую партицию — часть очереди. К этому добавляется плата за каждый гигабайт, записанный в очередь, и за каждый гигабайт, прочитанный из неё, плюс тариф за хранение. Поэтому каждая дополнительная программа, которая читает те же события, например ежедневный пересчёт по вашим логам биддера, увеличивает счёт.

Стоимость пути с управляемым сервисом считайте по трафику, который вы ожидаете в самый загруженный месяц следующего года, и сверьте этот трафик с лимитами провайдера. Кластер MSK Serverless, например, замедляет запись свыше 200 мегабайт в секунду — так указано на странице с его квотами по состоянию на 14 октября 2026 года.

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

Сколько контроля оставляет нам каждый путь?

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

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

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

Какой путь быстрее всего приведёт в порядок цифры, по которым мы выставляем счета?

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

Как выбрать путь по собственным данным?

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

  • Какая часть разрыва — потерянные события, а какая — правила подсчёта? Эту разбивку даёт пересчёт
  • На каких шагах события пропадают на пике? Почасовые цифры на каждом шаге, от коллектора до базы данных, показывают, где они проседают
  • На что в прошлом квартале ушли часы, которые ваши инженеры отдали пайплайну? Разделите тикеты и алерты на время, потраченное на поддержание работы серверов, и время на исправление проблем с подсчётом или данными
  • Какой трафик пайплайн должен выдерживать через двенадцать месяцев? Прогоните записанный день собственного трафика с такой интенсивностью и посмотрите, выдержит ли пайплайн

Если поставить три пути рядом, картина такая.

  • Починка текущего пайплайна. Часы инженеров, полный контроль и результаты, которые можно проверить на следующем пике
  • Управляемый сервис. Ежемесячный счёт, который меняется вместе с трафиком, обновления по графику провайдера и результаты после миграции
  • Перестройка силами внешней компании. Проект плюс месяцы параллельной работы, контроль через договор и результаты как минимум через один полный расчётный период

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

Можно ли сочетать пути?

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

Перестройка не обязательно означает, что серверы придётся эксплуатировать самим. Новый пайплайн может работать на управляемой очереди и управляемой аналитической базе данных, а некоторые провайдеры эксплуатируют ещё и загрузчик — шаг, который записывает события из очереди в базу данных. ClickHouse Cloud, облачная версия базы данных ClickHouse, предлагает для этого ClickPipes. Документация ClickHouse Cloud называет ClickPipes «управляемой платформой интеграции», а среди источников ClickPipes перечисляет Kafka и AWS MSK. Тогда внешняя компания строит то, что присуще именно вашей платформе, например правила подсчёта и ежедневный пересчёт по вашим логам биддера, а также коллектор и загрузчик там, где не подходит ни один управляемый вариант.

Что должно показывать предложение внешней компании?

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

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

Строит ли amBrain пайплайны рекламных событий?

amBrain строит пайплайны событийной аналитики для AdTech: сбор и обработка событий показов и кликов и отчётность по ним. В AdTech amBrain также занимается разработкой DSP, платформ real-time bidding и рекламных бирж, а RTBBidder — demand-side платформа, которую amBrain построил для клиента.

amBrain диагностирует медленные системы в трейдинге и AdTech: работающую платформу замеряют от начала до конца, и в отчёте названо, куда уходит время.

amBrain делает софт с 2019 года. Компания работает в трёх форматах: полная разработка, выделенная команда или инженеры внутри вашей команды. О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов».

Здесь не описан пайплайн ни одного клиента. Amazon MSK, Kafka, ClickHouse и ClickPipes упомянуты как распространённые примеры, и amBrain не утверждает, что пользовался ими или переводил какой-либо пайплайн на управляемый сервис. Статья не приводит ни цен, ни сроков amBrain, а суммы в долларах выше — вымышленный пример.

Если обратитесь в amBrain, начните с годовой цены вашего разрыва и почасовых цифр за самый загруженный день.

Частые вопросы о починке или перестройке пайплайна рекламных событий

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

На столе похожая архитектура?

Принесите текущую архитектуру и тот сценарий отказа, который вас беспокоит, — разберём его вместе за полчаса.