Claude Cowork, Claude Design объединили в один Claude

➡️ Читайте на сайте: https://aff.top/blog/claude-cowork-claude-design-obedinili-v-odin-claude

🧠 Ещё больше инсайтов → в канале AFF.top

Microsoft планирует вставлять рекламу в игры

➡️ Читайте на сайте: https://aff.top/blog/microsoft-planiruet-vstavliat-reklamu-v-igry

🧠 Ещё больше инсайтов → в канале AFF.top

Server-side tracking для вебинара: как мы закрыли «серую зону» между регистрацией и лидами

Компания: B2B SaaS (продукт для автоматизации процессов в компаниях среднего размера)
Задача: измерять воронку вебинаров end-to-end (регистрация → факт участия → заявки → прогрев → MQL/SQL), при этом уходить от неточной last-click атрибуции и потерь данных из‑за блокировщиков и ограничений браузеров. Дополнительно нужно было понять, какие источники трафика дают не просто заявки, а тех, кто реально дослушал и потом дошёл до продажи.

Решение: вместо «только пиксели в браузере» внедрили server-side событие-агрегацию и связали его с CRM через единый ключ пользователя. Архитектура получилась такая:
— На клиенте собираем минимальный набор: UTM/первичную кампанию, user_id (или анонимный идентификатор), event_id.
— Отправляем события на сервер через собственный endpoint (server-side), где нормализуем параметры, устраняем дубликаты по event_id и проставляем бизнес-метки (например, is_attended, attended_minutes).
— В момент подтверждения участия вебинара (по серверному callback’у) формируем событие «вебинар/факт участия» и прокидываем его в CRM-маркер лида.
— Для контента сделали отдельные события: просмотр страницы, клик по регистрации, старт трансляции, подтверждённое присутствие, скачивание материалов. Это позволило видеть микро-логику прогрева.
— В отчётах отказались от «одной линии» атрибуции и перешли на модель с учётом последовательности: источник регистрации оцениваем отдельно, вклад события присутствия — отдельно, а SQL/выручку — уже на уровне сегментов.

Конкретный результат: в ходе запуска воронки команда перестала «слепо» оптимизировать кампании по кликам и регистрациям. По факту внедрения server-side:
— Стабилизировали измерение участия: доля расхождений между аналитикой и CRM по статусам лида снизилась за счёт дубликатов и потерь событий на стороне браузера.
— Декомпозировали, какие каналы дают регистрацию без участия: это позволило перестать бюджетировать источники с низкой долей подтверждённого присутствия.
— Улучшили управляемость прогнозов по воронке: меньше неожиданных провалов между этапами «регистрация» и «MQL», потому что события стали воспроизводимыми и сверяемыми с CRM.

Какой урок вынесли: в 2026‑м выигрывают те, кто измеряет не «действие в браузере», а бизнес-события, подтверждённые системой. Server-side tracking даёт ключевое преимущество — вы контролируете качество данных: нормализация, дедупликация, единый ключ, подтверждение фактов (вроде присутствия на вебинаре), а не попытка угадать по last-click.

Если будете делать похожий проект, начните с одной «узкой» связки: например, регистрация → факт участия → лид в CRM. Это быстрее окупается, чем пытаться сразу закрыть всю атрибуцию по всем каналам и форматам.

— @ServerSideTrackingRu

Server-side GTM: что это и чем он отличается от обычного GTM

Server-side GTM — это способ собирать и передавать маркетинговые события не напрямую из браузера пользователя, а через собственный серверный контейнер. Проще говоря: часть логики трекинга уходит с клиента на ваш сервер, а уже оттуда данные отправляются в рекламные и аналитические системы.

Это не то же самое, что классический client-side GTM. В клиентской модели теги выполняются в браузере, зависят от скорости страницы, блокировщиков и ограничений cookies. В серверной модели вы лучше контролируете данные, можете обогащать события first-party (первичными) атрибутами и точнее управлять тем, что и куда отправляется.

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

Пример: пользователь оформил заявку на B2B-услугу. Браузер отправил событие в ваш серверный контейнер, там к нему добавили UTM-метки, идентификатор лида и согласованный набор полей, после чего событие ушло в GA4 и CRM. Так вы уменьшаете потери данных и строите основу для privacy-first атрибуции — атрибуции в условиях ограничений приватности.

— @ServerSideTrackingRu

First-party в большом ритейле: как X5 выстроила серверную аналитику для сквозного view-to-purchase

X5 — хороший пример того, как в 2026 году ритейл смещается от «разовых продаж» к управлению выручкой через весь цикл: охват → визит → покупка → повтор. Когда половина данных “протекает” через браузеры, трафик становится менее наблюдаемым, а last-click атрибуция перестаёт отвечать на вопрос бизнеса “что именно влияет на продажи”, компании начинают собирать собственную (first-party) картину и считать эффект уже на сервере.

Контекст
— privacy-first: часть конверсий не доходит до пикселей, меняются правила трекинга и идентификаторов;
— падение точности сквозной оценки: маркетинг видит клики/просмотры, но не уверен в том, что они действительно конвертируются в покупки;
— роль RevOps (ответственность маркетинга, продаж и customer success за выручку) растёт: нужен единый отчёт, а не набор разрозненных дашбордов.

Задача
Под задачу “повысить вклад performance-каналов в продажи” X5 требовалось:
— построить единую модель событий от приложения/сайта до покупки в кассе;
— отделить “видимость” (реклама достигла пользователя) от “действия” (пользователь реально купил);
— сделать измерения пригодными для оптимизации креативов и бюджетов без опоры на браузерные ограничения.

Решение (как обычно делают на практике в server-side архитектуре)
1) Серверная прослойка для событий
Все ключевые события (просмотр товара, просмотр страницы предложения, старт покупки, завершение покупки) стали уходить не напрямую в рекламные платформы из браузера, а через backend-сервис. На сервере:
— нормализуются параметры (идентификаторы карточек товаров, категории, сумма, валюта, тип клиента);
— добавляется контекст с первой стороны (например, состояние корзины, статус авторизации, регион);
— формируется единый формат “событие → профиль → конверсия”.

2) Управление идентификаторами и связями
Вместо “одной магической метки” внедрили связку: cookie/ID устройства + идентификатор пользователя при авторизации (там, где это законно и согласовано). Это повышает долю совпадений между этапами воронки.

3) Модель соответствия “view-to-purchase”
Чтобы отчитаться бизнесу, компания перешла от простых конверсий к связке “просмотр/интерес → покупка”. На сервере строилась корреляционная цепочка: какие параметры показа (категория, регион, сценарий) чаще всего приводят к покупке в заданном окне.

4) Инкрементальность вместо предположений last-click
Для проверки влияния кампаний использовали подходы “похоже на тест”: разрезы по группам, контрольные выборки и MMM/инкрементальные проверки на уровне каналов. Идея простая: сравнивать не только “у кого клик”, а “на сколько выросли продажи сверх базового уровня” после запуска.

Результат
Что получили (типичный измеримый эффект для такой трансформации, который X5 и похожие ритейлеры описывают на уровне показателей):
— рост доли корректно сопоставленных цепочек “событие → покупка” за счёт server-side и усиления связей между устройствами/авторизацией;
— снижение расхождений между маркетинговыми отчётами и фактическими продажами: серверная модель событий стала точкой истины;
— возможность оптимизировать не “под клики”, а под вклад в выручку: кампании, которые давали высокий engagement, но слабый view-to-purchase, начали выбывать из приоритетов;
— повышение управляемости: маркетинг стал быстрее повторять победные сценарии (креатив/аудитория/мерчандайзинг), потому что сигнал о покупке стал стабильнее.

Урок
1) В 2026 выигрывает не тот, кто “лучше считает клики”, а тот, кто собирает **доказуемую связь** между интересом и покупкой на сервере.
2) Серверная аналитика — это не только про технику. Это про единый формат событий и управляемую модель соответствия (view-to-purchase), чтобы RevOps опирался на один счётчик смысла.
3) Last-click нужно дополнять проверками инкрементальности: иначе при изменениях cookie-политик и росте “zero-click” поведение пользователя будет выглядеть иначе, чем есть на самом деле.

— @ServerSideTrackingRu