Как Asos перестроил атрибуцию на стороне сервера и перестал терять конверсии

Как Asos перестроил атрибуцию на стороне сервера и перестал терять конверсии

Asos — крупный e-com игрок — столкнулся с типичной для 2026 года проблемой: браузерные ограничения, блокировщики и урезанные cookies начали ломать видимость конверсий. Для платного трафика это означает одно: last-click (последний клик) всё хуже отражает реальный вклад каналов, а отчёты по пикселям «проседают» не потому, что реклама стала слабее, а потому что измерение стало дырявым.

Задача была прагматичная: восстановить качество передачи событий в рекламные системы и аналитические платформы, не полагаясь только на клиентский пиксель. Для этого Asos вынес сбор и отправку событий в серверную схему: события с сайта сначала обрабатывались на своей стороне, а потом уже отправлялись дальше. Параллельно выстроили более аккуратную связку идентификаторов, чтобы конверсии лучше матчились с кликами и сессиями.

Что это дало:
— меньше потерь событий на этапе браузера;
— стабильнее передача конверсий в рекламные кабинеты;
— чище база для оптимизации кампаний и ретаргетинга.

Конкретные цифры в открытом описании кейса не раскрывались, и это важно: не любой server-side (серверная) проект сразу даёт рост выручки «в процентах». Но почти всегда он даёт другое — **меньше слепых зон в атрибуции** и более предсказуемую работу performance-каналов.

Урок для маркетолога-инженера простой:
— если у вас падает качество отчётности, не спешите резать бюджеты;
— сначала проверьте, сколько конверсий теряется на клиенте;
— потом оцените, где у вас пиксель, где сервер, где postback (передача события о конверсии);
— и только после этого сравнивайте каналы.

В privacy-first среде выигрывает не тот, кто громче говорит про ROAS, а тот, кто лучше измеряет путь до выручки.

— @AdOpsRoom