Логи RTB бесполезны, если не сохранять поля, которые объясняют bid loss и win rate

Логи RTB бесполезны, если не сохранять поля, которые объясняют bid loss и win rate

Сохраняйте не только request/response, а связку идентификаторов: auction id, imp id, request id, seat id, bidder name, source / schain, seller id, site/app id, placement id. Без этого не собрать путь запроса через wrapper, SSP и downstream.

Из полезного в bid request обычно хватает:
— timestamp в UTC;
— device: ua, ip, ifa/uid, geo;
— geo, language, os, browser;
— adunit: format, size, floor, prebid timeout;
— consent/regs, deal id, adomain, currencies.

Из bid response фиксируйте:
— bid price, currency, ad markup type;
— ttl / exp, creative id, advertiser domain;
— dealid, meta: advertiser / network / agency если есть;
— errors, no-bid reason, timeout reason;
— rendered / viewable / win notice, если трекинг доходит до события.

Важно хранить не только сырые JSON, но и нормализованные поля для аналитики. Иначе одна и та же сущность будет называться по-разному в разных логах, а SPO и floor-аналитика развалятся на несовместимые таблицы. Отдельно сохраняйте версию схемы и source of truth для каждого поля.

Минимальный набор для дешборда: auction id, bidder, adunit, geo, floor, timeout, bid, win, deal, consent, reason. Этого хватает, чтобы искать утечки в bid stream, оценивать влияние таймаута и понимать, где режется fill rate.

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