Логи RTB без правильных полей — это просто шум, а не база для аналитики

Логи RTB без правильных полей — это просто шум, а не база для аналитики

Для разборов bid stream сохраняйте не весь request целиком, а минимальный набор, который позволяет восстановить путь аукциона:
— requestid / auctionid
— impid, seat, bidder, adapter
— tmax, timeout, bidfloor, cur
— schain, ads.txt / sellers.json attribution
— device / ua / ip / geo на уровне доступного consent

Отдельно держите поля, которые помогают объяснить loss причины: no-bid, timeout, mismatch по currency, dealid, floor exceeded, invalid creative, policy reject. Без этого вы не отличите «не купили» от «не успели ответить» и начнёте лечить fill rate не там, где утечка.

Если есть prebid server или client-side wrapper, логируйте связку auction -> bid -> render -> win notice. Иначе в отчёте будет красивый CPM, но вы не увидите, где разваливается цепочка: на bidder response, в GAM, на ad server decisioning или в viewability-сегменте.

Ещё один обязательный слой — идентификаторы для склейки: user key, session key, placement key, page key. Храните их в едином формате, иначе SPO-отчёты, fraud-детект и сравнение SSP будут жить в разных таблицах.

Практика простая: сначала определите 10–15 полей, без которых нельзя объяснить loss, а уже потом добавляйте расширенную телеметрию. Логи RTB ценны не объёмом, а тем, насколько быстро они отвечают на вопрос «почему эта заявка не превратилась в показ».