ID5, UID 2.0 и LiveRamp: как не сломать identity stack в programmatic

ID5, UID 2.0 и LiveRamp: как не сломать identity stack в programmatic

Если у вас в стекe одновременно сидят ID5, UID 2.0 и RampID, ошибка обычно не в самих провайдерах, а в архитектуре маппинга. Главный вопрос — где лежит source of truth: в CMP, в prebid userId module или в server-side sync.

— Не смешивайте разные scopes одного и того же пользователя в одном key-value без явного приоритета. Иначе bidder видит несколько ID и начинает деградировать match rate.
— Проверьте TTL и refresh policy: stale ID хуже, чем отсутствие ID. Для long-tail трафика это критично.
— Не отправляйте один и тот же ID в несколько id systems без нормализации consent-state; потом это ломает сегментацию и дедупликацию.

Практика: в client-side оставляйте only one primary ID provider на сессию, а остальные — как fallback. На стороне Prebid держите порядок userIds детерминированным, иначе разные страницы начнут отдавать разные значения в bidstream. В SSP/DSP логике отдельно учитывайте MAID, hashed email и publisher IDs — это разные сущности, даже если они совпадают по match rate.

Если нужен стабильный identity stack, проектируйте его как очередность приоритетов и правил истечения, а не как список интеграций.