Attribution Reporting API в Chrome: что реально внедрено и как это читать без иллюзий

Attribution Reporting API в Chrome: что реально внедрено и как это читать без иллюзий

Attribution Reporting API — это не «новая атрибуция вместо всего», а набор приватных отчётов, где браузер сам ограничивает, что и когда уходит на сервер. Для performance это значит: вы больше не получаете привычный user-level лог, а работаете с агрегатными сигналами и шумом.

Что важно проверить в интеграции:
— зарегистрированы ли source и trigger в нужных окнах;
— не теряются ли event-level отчёты из-за неверного scope;
— совпадает ли идентификатор конверсии между click и conversion;
— есть ли у вас план сверки с backend-покупками и обычным CAPI.

Типовая ошибка — пытаться встроить AR API как замену Pixel/CAPI. Правильнее считать его дополнительным каналом валидации: он помогает закрывать часть разрывов, но не даёт полного дубля событий и не предназначен для детального user journey. Если у вас воронка длинная, отдельный reconciliation layer обязателен.

Для sGTM схема обычно такая: браузер отправляет source/trigger, сервер принимает агрегированные отчёты, а дальше вы сверяете их с first-party order table. Если на этом шаге нет единого event_id и чистой нормализации campaign/source, расхождения будут выглядеть как «потеря атрибуции», хотя проблема в стыковке данных.

Итог простой: внедрение стоит читать как переход от детального логирования к вероятностной сверке. Настраивайте AR API только вместе с event_id, backend truth и понятной схемой дедупликации — иначе сигнал будет, а ответа на вопрос «какая кампания дала продажу» не будет.