ID5, UID 2.0 и LiveRamp: как выбрать identity layer без лишнего шума в bid stream

ID5, UID 2.0 и LiveRamp: как выбрать identity layer без лишнего шума в bid stream

Если смотреть на stack через bid request, различия не в «бренде», а в том, где живёт граф и как он матчится:
— ID5 обычно удобен там, где нужен быстрый on-site consent-aware match и понятная интеграция в wrapper.
— UID 2.0 сильнее, если у вас есть first-party логика и вы хотите контролировать round-trip через токенизацию.
— LiveRamp чаще выбирают, когда важнее enterprise-матчинг и переносимость между DSP/SSP-слоями.

Проверять нужно не обещания в презентации, а три вещи: match rate по гео и device class, latency на auction path, и долю запросов, где ID вообще доезжает до bidder. Если ID приходит только в части трафика, не надо строить на нём core bidding logic — оставляйте его как enrichment layer, а не как single point of decision.

В интеграции чаще ломается не сам ID-провайдер, а конфигурация: неверный consent string, разный порядок enrichment в Prebid, отсутствие fallback на contextual, дублирование псевдонимов в user.ext. Для SPO полезно отдельно смотреть, где ID используется в request, а где только в post-auction measurement.

Практика простая: храните identity как модульный слой, тестируйте каждого провайдера на одном и том же inventory, и не смешивайте match-логику с логикой выбора bidder. Тогда смена ID-партнёра не превращается в переписывание всего auction stack.