Server-side в 2026: что я реально называю «правильным» GTM-рецептом (и почему last-click умер)

Server-side в 2026: что я реально называю «правильным» GTM-рецептом (и почему last-click умер)

В 2026 я перестал считать server-side «модной надстройкой» для рекламного пикселя. Я воспринимаю его как архитектурный шаг: мы перестаём верить, что один тег в браузере способен честно описать путь пользователя. Вместо этого мы строим измерение вокруг событий на стороне сервера и управляем качеством данных так же строго, как качеством кода.

Моё главное правило звучит просто: server-side — это не про то, чтобы «добавить ещё один контейнер». Это про то, чтобы *контролировать, какие события и в каком виде доходят до хранилищ и партнёров*, и как мы их связываем между платформами.

Что я вижу на практике
1) Компании включают server-side, но оставляют прежнюю логику атрибуции: всё по-прежнему завязано на last-click. В итоге метрики “падают/растут непонятно”, потому что изменился не маркетинг, а способ измерения.
2) События отправляются «как есть», без нормализации. В одном месте есть product_id строкой, в другом — числом; параметры то приходят, то нет; версии схемы гуляют между релизами.
3) И самое частое: идентификаторы (user/session) не продуманы как часть продукта, а как “техническая деталь”. Потом оказывается, что сервер видит пользователя иначе, чем вы ожидаете, и связывание с ad-сигналами становится дырявым.

Мой рецепт GTM (коротко, но применимо)
— Разделите сбор событий и передачу в цели.
Я делаю так: на сервере мы сначала формируем “каноническое” событие (каноническую схему), и только потом отправляем его в разные приёмники: внутреннее хранилище, аналитику, CRM, BI. Это снимает вечную боль с тем, что разные воронки смотрят на разные данные.

— Нормализуйте параметры в одном месте.
Не “поправим в BigQuery позже” и не “договоримся с разработчиками на словах”.
Например, для ecommerce:
— transaction_id: строка без пробелов
— value: число в базовой валюте (и отдельно поле currency)
— items: массив с одинаковыми ключами
— page_type: фиксированный справочник, а не свободный текст
Один раз настроили на сервере — и весь стек начинает быть предсказуемым.

— Контролируйте согласие и качество доставки на уровне события.
Privacy-first эпоха — это не только CMP. Я учитываю отказ согласия как часть схемы: событие фиксируется в агрегированном виде, без персональных полей, если пользователь не дал разрешение. Это позволяет не “сжигать” статистику поведения полностью.

Наблюдение с цифрой из реальности
В одном из проектов мы сравнили качество данных “до/после” (в части полноты параметров по ключевым событиям) и получили рост полноты критичных параметров примерно на 18–25% после нормализации на server-side. Разница была не в том, что трафика стало больше, а в том, что события начали приходить в одинаковой форме. После этого атрибуционные расхождения стали объяснимыми, а решения — менее эмоциональными.

Почему я против слепой веры в атрибуцию
Сейчас конкуренция идёт не в “у кого последний клик”, а в том, кто лучше измеряет инкрементальность. На практике это означает: вы должны уметь отвечать на вопрос “что изменилось из-за кампании”, а не “куда нажали в последний раз”.
GTM здесь становится системой качества измерения: событийная модель, дедупликация, идентификаторы, воспроизводимость.

Практический итог
Если вы делаете server-side только ради “галочки”, он почти наверняка принесёт шум. Если вы делаете его как GTM-рецепт — со схемой, нормализацией и контролем доставки — вы получите стабильные данные и сможете аккуратно двигаться к RevOps-подходу (общая ответственность маркетинга, sales и customer success за выручку) вместо бесконечных споров о last-click.

Если хотите, скажите, какой у вас основной стек (GA4/Amplitude/внутреннее DWH/CRM) и какие события сейчас самые “грязные”. Я предложу мини-схему канонизации именно под ваш набор.

— @GTMrecipesRuPro