Attribution Reporting API в Chrome: что реально внедрено и как не сломать отчётность

Attribution Reporting API в Chrome: что реально внедрено и как не сломать отчётность

Attribution Reporting API — это не замена всей атрибуции, а механизм для измерения конверсий без передачи user-level цепочки кликов в отчёт. Браузер сам сопоставляет источник и конверсию, а наружу отдаёт агрегированные отчёты или event-level данные с ограничениями по шуму и задержке.

Если внедряете его в стек, проверьте 3 вещи:
— source registration: на каком домене и в каком контексте регистрируется клик/просмотр;
— trigger registration: какие события считаются конверсией и какие поля вы реально отправляете;
— отчётность: где вы будете сравнивать данные с GA4, CAPI или логами сервера.

Тонкий момент — дедупликация. Attribution Reporting API не должен жить отдельно от Pixel, CAPI и server-side логики. Если у вас уже есть event_id, внешний click_id и серверный receive timestamp, заранее определите приоритет источника: браузерный отчёт, CAPI или внутренний лог. Иначе один purchase попадёт в два канала учёта.

Ещё одна ошибка — ожидать, что API вернёт тот же уровень детализации, что и классический last-click. Не вернёт: часть сигналов агрегируется, часть задерживается, часть режется политиками браузера. Поэтому схема внедрения должна начинаться не с “включить”, а с “какие KPI я вообще смогу подтверждать этим каналом”.

Практика простая: сначала подключайте API как дополнительный слой измерения, потом стройте маппинг событий и таблицу дедупликации. Так вы получите стабильный baseline и не будете принимать ограничения браузера за баг в трекинге.