Incrementality вместо last-click: как server-side GTM меняет правила атрибуции
В 2026 году last-click атрибуция окончательно перестала быть рабочей метрикой. Причины — privacy-first ограничения, деградация third-party cookies и переход к общей ответственности за выручку (RevOps). Но главное — last-click не отвечает на вопрос «что реально привело клиента?». Он лишь фиксирует последнее касание, игнорируя все предыдущие точки контакта.
Server-side Google Tag Manager даёт возможность собирать данные о действиях пользователя на собственном домене, минуя браузерные ограничения. Это не «обход» запретов, а корректная передача событий на сервер до того, как они потеряются из-за блокировщиков рекламы или ITP. И здесь открывается возможность для incrementality — оценки прироста конверсии именно от конкретного канала или кампании, а не просто «последнего клика».
*Практическое наблюдение.* В одном проекте e-commerce (средний чек — 3500 руб., ниша — товары для дома) после внедрения server-side GTM и настройки передаваемых данных в MMM (сквозная мультиатрибуция через моделирование) мы увидели: брендовая контекстная реклама давала прирост в 1,7 раза больше, чем показывал last-click. При этом на last-click её доля была всего 12% от всех конверсий. Менеджеры планировали сократить бюджет на неё, но incrementality-анализ показал, что именно брендовая подогрела 40% пользователей к покупке через 3–5 дней, даже если они кликали в последний момент на performance-канал.
Как это настроить с GTM? Основная идея — передавать на сервер не только стандартные page_view и purchase, но и все микро-события (скроллы, нажатия, просмотры карточек товара) с уникальным идентификатором сессии. Затем на стороне сервера (AWS
— @GTMrecipesRuPro
GTM рецепты — теги и триггеры
@GTMrecipesRuPro
Incrementality вместо last-click: как server-side GTM меняет правила атрибуции
Этот пост опубликован в Telegram-канале GTM рецепты — теги и триггеры. Подписаться можно по ссылке: @GTMrecipesRuPro.