Почему показов меньше, чем в счете SSP: расхождения и сверка

Показы у DSP и в счете SSP расходятся, потому что стороны считают разные события в разных местах: DSP — пиксель отрисовки в разметке, SSP — свой момент биллинга, о котором она сообщает уведомлением burl. К этому добавляются потери и повторы HTTP-уведомлений, разные часовые пояса и фильтрация недействительного трафика. Сверка сводится к тому, чтобы договориться об одном событии, привести данные к одному поясу, схлопнуть дубли и сравнить по идентификаторам.

#Какие события вообще можно считать

Раздел 7.8 спецификации OpenRTB 2.6 сравнивает способы подсчета оплачиваемых показов:

Определение из спецификации: burl — адрес, который биржа вызывает, когда выигравшая ставка становится оплачиваемой по ее бизнес-правилам (обычно «доставлено» или «просмотрено»). Поле появилось в OpenRTB 2.5.

{
  "id": "b-1", "impid": "1", "price": 85.0, "crid": "cr-7",
  "burl": "https://dsp.example/bill?auc=${AUCTION_ID}&imp=${AUCTION_IMP_ID}&p=${AUCTION_PRICE}",
  "adm": "<div>…<img src=\"https://dsp.example/imp?auc=${AUCTION_ID}&imp=${AUCTION_IMP_ID}\"></div>"
}

Здесь два счетчика: burl вызывает сервер биржи, пиксель в adm — устройство. Расхождение между ними — нормальное явление, вопрос в его величине и причинах.

#Откуда берутся расхождения

#1. Разные события

Если SSP выставляет счет по своему событию (например, по факту загрузки креатива), а DSP считает пиксель, который срабатывает позже, разница неизбежна: часть показов «умирает» между этими моментами. Хуже, если одна сторона считает выигрыши: спецификация предупреждает, что лишь часть выигранных аукционов становится показами — из-за последующих аукционов у издателя, невозможности воспроизвести видео и т. п. Подробнее о том, почему выигрыш не равен показу, — в статье «Воронка RTB» и в глоссарии «Win notice».

#2. Клиентская сеть

Пиксель отрисовки идет с устройства по мобильной сети. Запрос может не дойти, его может заблокировать блокировщик рекламы, приложение может закрыться раньше. Спецификация называет пиксель в разметке «склонным к расхождениям» и рекомендует в мобильных приложениях не использовать его как основание для биллинга, а опираться на burl или независимое измерение (например, OMID).

#3. Доставка «хотя бы один раз» и дубли

Уведомление о биллинге — финансовое событие, поэтому спецификация советует отправителю повторять вызов, если ответ не HTTP 200 или 204 (например, каждые 10 секунд в течение минуты), а получателю — делать обработчик идемпотентным, чтобы не посчитать дважды. Следствие: при сбоях сети одно и то же уведомление приходит несколько раз. Если DSP не схлопывает события по ключу, ее счетчик завышен.

Такая же картина с нативной рекламой: если площадка вызывает и eventtrackers, и imptrackers (или собственный массив пикселей SDK) с одним и тем же URL, один показ дает несколько событий.

#4. Часовые пояса и границы суток

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

#5. Фильтрация недействительного трафика

Одна сторона может исключать показы, признанные недействительными (ad fraud, боты, внутренний трафик), а другая — нет. Пока правила фильтрации не совпадают, не сойдутся и итоги.

#6. Деньги и единицы

Ставка в OpenRTB — CPM, цена за тысячу. Сумма по одному показу — ставка / 1000. Ошибка в единицах дает расхождение в тысячу раз и сразу видна; ошибка в валюте или налогах (с НДС и без) — тоньше. Во второй цене списывается цена клиринга, а не ставка, — сравнивать нужно с ${AUCTION_PRICE}.

#Как сверяться: пошаговый порядок

1. Договориться о событии. Какой сигнал оплачивается: burl, пиксель, VAST <Impression>, видимый показ (viewability)? Спецификация прямо советует сторонам заранее согласовать определение оплачиваемого события и способ его подсчета.
2. Один часовой пояс. Обе выгрузки — в UTC или в одном поясе.
3. Одна валюта и единицы. Суммы в одной валюте, с одинаковым учетом налогов; цены — в одних единицах (CPM или за показ).
4. Дедупликация. Ключ показа — идентификатор аукциона плюс идентификатор показа (${AUCTION_ID} + ${AUCTION_IMP_ID}). Считать уникальные ключи, а не строки.
5. Сначала итоги, потом разрезы. Сравнить сутки целиком, затем по слотам, форматам, креативам. Расхождение, сосредоточенное в одном слоте или формате, указывает на конкретную интеграцию.
6. Сверка по идентификаторам. Обменяться выборкой идентификаторов аукционов за час и найти три группы: есть у обоих, только у SSP, только у DSP. Каждая группа объясняет свою часть разницы.
7. Зафиксировать результат. Причина, доля, решение — чтобы следующая сверка начиналась не с нуля.

Пример запроса для дедупликации событий (ClickHouse-подобный SQL):

SELECT toDate(event_time, 'UTC') AS day,
       count()                                  AS raw_events,
       uniqExact(auction_id, imp_id)            AS unique_impressions
FROM billing_events
WHERE event_time >= '2026-10-01' AND event_time < '2026-10-08'
GROUP BY day
ORDER BY day;

Если raw_events заметно больше unique_impressions, дубли есть, и все потребители этих данных должны считать уникальные ключи.

#Как читать три группы при сверке

#Пример сверки в цифрах

Условный пример за одни сутки по одному слоту. SSP выставила счет за 100 000 показов, у DSP пикселей отрисовки 97 300, уведомлений burl — 101 200 строк.

Что видно из таблицы:

• без дедупликации DSP «насчитала» больше, чем выставлено в счете, — из-за повторных уведомлений;
• после дедупликации и приведения к одному поясу счетчик burl практически совпал со счетом SSP;
• пиксель отрисовки ниже на несколько процентов — часть показов не дала клиентского события. Для биллинга это ожидаемо, а для оценки качества слота полезно: если разрыв между burl и пикселем растет, на слоте что-то ломается в отрисовке.

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

#Особые случаи: видео и нативная реклама

Видео. Для VAST-видео и аудио спецификация называет официальным сигналом оплачиваемого показа событие VAST <Impression> и не рекомендует опираться на burl. Если биржа все же вызывает burl, он должен срабатывать одновременно с <Impression>, иначе появляются дополнительные расхождения. При сверке видео сравнивают счетчики <Impression> у обеих сторон, а не burl с пикселем.

Нативная реклама. Трекеры показа передаются в нативном ответе (eventtrackers, устаревшие imptrackers), и SDK площадки решает, когда их вызывать. Если SDK вызывает и новые, и старые трекеры, или дублирует их собственным механизмом, у DSP появляются повторы. Поэтому для нативной рекламы дедупликация по идентификатору показа обязательна.

Мобильные приложения. Предзагрузка рекламы приводит к тому, что разметка загружена, а показ не состоялся. Спецификация рекомендует в приложениях не считать оплачиваемыми события из разметки, а использовать burl или независимое измерение.

#Что зафиксировать в договоре

• Какое событие оплачивается и чей счетчик главный.
• Часовой пояс и отчетный период.
• Допустимый порог расхождения и порядок сверки при его превышении: кто готовит выгрузку, в каком формате, в какие сроки.
• Правила исключения недействительного трафика.
• Для видео — опора на VAST <Impression> и как с ним соотносится burl: спецификация предупреждает, что одновременное использование может давать дополнительные расхождения.

Важно. Спецификация не дает «нормального» процента расхождений. Любая цифра, которую называют стандартом, — договоренность сторон, а не правило OpenRTB.

#Как Ibiza считает показы и списания

В DSP Ibiza показ и списание бюджета считаются по собственному пикселю показа, а уведомление burl записывается отдельным событием, если биржа его присылает. Повторы — ретраи биржи или второй трекер нативного SDK — отбрасываются по ключу показа до того, как попадут в деньги и отчеты. Сравнение двух счетчиков показывает расхождение с площадкой раньше, чем придет ее счет. Какие макросы подставлять в трекеры — в документации «Макросы и трекеры».