Attribution Reporting API в Chrome: что реально внедрено и где ломается логика привычной атрибуции

Attribution Reporting API в Chrome: что реально внедрено и где ломается логика привычной атрибуции

Attribution Reporting API — это не замена CAPI или sGTM, а браузерный способ передать факт конверсии без передачи сырых идентификаторов в ad-tech цепочку. Для performance-команды важны две вещи: событие может быть отложено и агрегировано, а детализация на уровне пользователя здесь намеренно ограничена.

Что учитывать при внедрении:
— регистрация источника и триггера живёт отдельно;
— отчёты бывают event-level и aggregatable, и это разные режимы;
— окно атрибуции, приоритеты и дедупликация задаются заранее, а не «как получится»;
— если у вас уже есть server-side логика, AR API закрывает не всё, а только часть браузерной потери.

Типовая ошибка — ждать от AR API привычного user-level reconciliation. Его задача другая: помочь измерять вклад рекламы там, где cookies и кросс-сайт связка слабеют. Поэтому схема должна быть простой: client-side регистрирует событие, server-side хранит бизнес-истину, а отчёты из браузера используются как дополнительный слой, а не единственный источник.

Если внедряете AR API в стек, сначала проверьте маппинг conversion event → trigger, затем логику приоритета кампаний и то, как вы будете сверять отчёт с backend-конверсией. Иначе получите «есть отчёт, но нет понимания, почему он такой».