Topics API: как браузер пытается заменить third-party cookies без передачи истории по всем сайтам

Topics API: как браузер пытается заменить third-party cookies без передачи истории по всем сайтам

Topics API — это не про «профили пользователей», а про короткий список интересов, который браузер выводит локально и отдает сайтам как сигнал. Идея простая: вместо полного трейсинга по сети вы видите категорию уровня “Sports”, “Travel”, “Autos” — без доступа к конкретным URL и без постоянного идентификатора.

Для performance это значит три вещи:
— сигнал слабее, чем cookie-based audience;
— категория живет ограниченное время и может меняться;
— одно значение Topics нельзя читать как источник истины для attribution или frequency capping.

В практической схеме Topics лучше рассматривать как дополнительный контекст для медиаплана, а не как замену first-party data. Если у вас есть CRM, consented audience и server-side события, приоритет остается за ними; Topics годится как верх воронки и для тестов инкрементальности. В sGTM его обычно не «обрабатывают», а используют в логике на стороне сайта или ad tech-слоя.

Минимальный чек-лист:
— не смешивать Topics с user_id или email_hash;
— не строить сегменты только на одной категории;
— проверять, какие темы вообще доступны в вашем сценарии;
— заранее описать, где Topics участвует: таргетинг, измерение или креатив.

Вывод простой: Topics API — это шумоподавленный контекст, а не новая супер-идентификация. Чем раньше вы разведете first-party события, consent и browser signals по разным ролям, тем меньше сюрпризов будет в атрибуции.