Bid request enrichment у SSP: какие поля реально добавляют ценность, а какие шумят

Bid request enrichment у SSP: какие поля реально добавляют ценность, а какие шумят

SSP часто расширяет bid request не только ради удобства, а чтобы поднять match rate, фильтровать supply и дать bidder'у больше сигналов для price discovery. Но не каждый enrichment полезен: чем больше полей, тем выше риск мусора, дублирования и расхождений между источниками.

Что обычно добавляют:
— site/app metadata: bundle, domain, pagecat, content, keywords
— device signals: UA, language, IP-производные, connection type, ifa/ifa_type
— seller context: seller_id, schain, ads.txt/app-ads.txt relations
— audience hints: segment IDs, cohort labels, GDPR/TCF consent flags
— transaction layer: deals, floors, auction type, ext-объекты

Главная проверка — не наличие поля, а его стабильность. Если enrichment плавает между SSP, bidder начинает переоценивать inventory или, наоборот, выкидывать его из-за low-confidence сигналов. Особенно это заметно на pagecat/content и audience segments: один и тот же supply может выглядеть как разные объекты в разных upstream.

Практика для валидации простая: логируйте raw request, сравнивайте заполненность по SSP, отмечайте поля, которые реально коррелируют с win rate и CPM, и отдельно режьте то, что только увеличивает payload. В SPO-отчётах enrichment полезен, когда он объясняет, почему один path продаётся лучше другого, а не когда просто раздувает JSON.

Чем чище enrichment, тем проще bidder'у принимать решение: оставляйте только те сигналы, которые меняют bid, а не те, которые красиво выглядят в схеме.