Attribution Reporting API в Chrome: что реально уже внедрено, а что ещё надо закладывать в архитектуру

Attribution Reporting API в Chrome: что реально уже внедрено, а что ещё надо закладывать в архитектуру

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

Если строите схему под ARA, проверьте 4 вещи:
— источник клика и конверсии должны быть размечены так, чтобы браузер мог связать событие;
— отчётность делится на aggregatable и event-level, это разные сценарии;
— окно атрибуции короткое и ограниченное, не пытайтесь перенести туда логику CRM;
— дедупликацию с Pixel/CAPI/other server events нужно проектировать отдельно, ARA её не заменяет.

На практике это означает: не хранить ожидание «полного user-level пути» в браузере, а переносить акцент на first-party события, чистые event names и стабильные параметры кампаний. Для команды аналитики полезно заранее описать матрицу: какой источник истины для purchase, какой — для lead, какой — для view-through, и где ARA только дополняет картину.

Если инфраструктура уже умеет собирать server-side события, ARA лучше воспринимать как ещё один слой измерения, а не как замену CAPI или sGTM. Чем раньше в схеме есть нормальный event_id, понятные окна и единые naming rules, тем меньше сюрпризов при сравнении браузерной и серверной атрибуции.