Почему рекламные отчёты не сходятся с логами биддера и кто может перестроить пайплайн

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

Что значит, если рекламные отчёты не сходятся с логами биддера?

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

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

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

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

Сопоставьте две стороны событие за событием. OpenRTB, протокол IAB Tech Lab для real-time bidding, даёт каждому аукциону идентификатор запроса на ставку (bid request ID), который присваивает биржа, а каждому показу в запросе — собственный идентификатор. Ваш биддер может попросить биржу подставлять эти идентификаторы в уведомление, которое она отправляет при вашем выигрыше, и в саму рекламу. Тогда каждое событие показа несёт те же идентификаторы, что и ваши логи биддера.

Ни одного из этих идентификаторов по отдельности недостаточно. По OpenRTB 2.6 каждая биржа задаёт идентификаторы запросов сама, поэтому ничто не мешает двум биржам использовать один и тот же. Идентификатор показа уникален только внутри своего запроса и обычно начинается с 1. Поэтому сопоставляйте по трём значениям сразу: биржа, идентификатор запроса и идентификатор показа.

Затем проведите пересчёт:

• За каждый час одного загруженного дня посчитайте выигрыши в логах биддера и показы в отчётах — и то и другое по UTC, сопоставляя их по этому ключу из трёх частей
• На следующий день посчитайте ещё раз. Если разрыв сократился, часть его составляли опоздавшие события
• Если доля выигрышей, которых по-прежнему не хватает, растёт в самые загруженные часы, пайплайн теряет события на пике. Доля, которая от часа к часу остаётся примерно одинаковой, — это нормально, потому что часть выигрышей так и не становится показами
• Разберите остальное. Если событие у каждой стороны попадает в разный час, значит, стороны используют разные часовые пояса или время отсечки. Двойной счёт обычно возникает из-за повтора. Если событие отсутствует только в итоговом отчёте, его убрал фильтр, например фильтрация ботов

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

Где события пропадают на пике трафика?

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

• Коллектор перегружен. Запросы, которые он отклоняет или на которые отвечает слишком поздно, пропадают, если браузер или приложение не отправят их снова. Коллектор, который отвечает «принято» до того, как событие оказалось в Kafka, к тому же теряет всё, что держал, когда падает
• Kafka не успевает принимать события. Документация Kafka описывает, что происходит, когда события приходят быстрее, чем их удаётся передать дальше. Код, который пишет в Kafka, ждёт заданное время, а затем сдаётся с ошибкой. Коллектор, который игнорирует эту ошибку, теряет событие бесследно
• Повторы создают дубли. В Kafka есть настройка, которая не даёт её собственным повторам записать вторую копию. Java-клиент Kafka включает её по умолчанию; клиентские библиотеки на других языках задают собственные умолчания, и некоторые оставляют её выключенной. Дубли, которые создаёт ваш код, она не ловит — например пакет, отправленный заново после перезапуска, или пиксель, который срабатывает дважды
• Пакетная вставка падает целиком. Документация ClickHouse рекомендует загружать события крупными пакетами. В одном из режимов загрузки одна битая строка приводит к тому, что отклоняется весь пакет. Загрузчик, который сдаётся, теряет все события пакета, а тот, что отправляет пакет заново без изменений, снова натыкается на ту же битую строку, поэтому битые строки нужно откладывать в сторону и считать. Когда запись упирается в таймаут и никто не знает, дошла ли она, повторная отправка точно такого же пакета безопасна, только если таблица настроена отбрасывать повторные пакеты, а базовая таблица ClickHouse на собственных серверах по умолчанию этого не делает

Попросите инженеров поднять такие записи за самый загруженный час неудачного дня:

• Ошибки и таймауты на балансировщике нагрузки и коллекторе, а также неудачные записи в Kafka в логах коллектора
• Отставание консьюмеров (consumer lag), то есть насколько отстали загрузчики, и все события, которые Kafka удалила непрочитанными, потому что они ждали дольше, чем она хранит данные
• Неудачные записи в ClickHouse с сообщениями об ошибках
• Почасовой счёт на каждом шаге: принято коллектором, записано в Kafka, прочитано загрузчиком, сохранено в ClickHouse

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

Чинить пайплайн, переходить на управляемый сервис или перестраивать его?

Починить текущий пайплайн:

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

Перейти на управляемый сервис, например Amazon MSK для Kafka или ClickHouse Cloud для ClickHouse, где серверы эксплуатирует провайдер:

• Когда подходит: ваши инженеры тратят больше времени на поддержание работы серверов Kafka и ClickHouse, чем на логику подсчёта, а потери возникают из-за того, что этим серверам на пике не хватает мощности
• Во что обойдётся: ежемесячный счёт, который растёт вместе с вашим трафиком. Оба сервиса берут плату за вычисления и хранение, а ClickHouse Cloud отдельно указывает исходящую передачу данных и собственный сервис приёма данных — по их страницам с ценами по состоянию на 7 октября 2026 года. Оцените счёт за самый загруженный месяц и стоимость будущего ухода с сервиса
• Чего не исправляет: коллектор и загрузчик, которые по-прежнему эксплуатируете вы, дубли, опоздавшие события и сверку с вашими логами биддера. Сервис хранит то, что вы ему отправляете, и ничего не знает о том, что насчитал ваш биддер
• Кому принадлежит код: вам, а сервис работает на условиях провайдера

Перестроить пайплайн:

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

Какие компании могут перестроить пайплайн рекламных событий на Kafka и ClickHouse?

Такую работу делают компании двух видов, и рейтинга ни тех, ни других эта статья не составляет. Инженерные компании в AdTech строят биддеры, биржи и ad-серверы, поэтому знают, откуда берутся идентификаторы аукционов, но спросите, эксплуатировали ли они пайплайн событий с вашими объёмами. Компании в области data engineering строят пайплайны событий для многих отраслей, хотя не всегда для AdTech. Спросите их, работали ли они с OpenRTB и сверяли ли цифры с биржей.

Что спросить, прежде чем нанимать компанию?

Задайте каждой компании из вашего списка одни и те же пять вопросов.

Как вы убираете дубли? В ответе должен прозвучать идентификатор, который каждое событие получает при создании, до любой повторной отправки, и который собран из идентификаторов аукциона и типа события. Пайплайн убирает дубли дважды: когда сохраняет события и ещё раз — когда их читают отчёты. Второй проход важен, потому что ClickHouse убирает дубли в фоне, в моменты, которые нельзя запланировать. В его документации сказано, что это «не гарантирует отсутствия дубликатов».

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

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

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

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

Какие тревожные сигналы?

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

Где здесь место amBrain?

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

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

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

Эта статья — не кейс. Она не описывает пайплайн событий ни одного клиента, а RTBBidder назван только как DSP, которую построил amBrain. Kafka и ClickHouse служат здесь примером стека, а не описанием проектов amBrain или инструментов, которыми он пользуется. Цен и сроков статья не приводит.

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

Частые вопросы

• Сойдутся ли когда-нибудь наши отчёты и логи биддера на 100 процентов? Нет. В OpenRTB сказано, что сообщение биржи о вашем выигрыше «не обязательно свидетельствует о доставленной, просмотренной или оплачиваемой рекламе», а часть событий отфильтровывается как бот-трафик. Добивайтесь стабильного разрыва с письменным объяснением каждой его части и договоритесь с каждым партнёром, по чьему подсчёту вы выставляете счета
• Обязательно ли использовать Kafka и ClickHouse? Нет. С той же задачей справляются и другие очереди и аналитические базы данных, а пересчёт и пять вопросов применимы к любой из них
• Как сохранить работу старых отчётов, пока строится новый пайплайн? Подавайте в оба пайплайна одни и те же события и каждый день сравнивайте каждый из них с логами биддера. Отчёты, по которым вы выставляете счета, переключайте последними — после полного расчётного периода, в котором объяснено каждое расхождение