Как Nike перестроила аналитику под first-party и не потеряла перформанс
В 2026-м старый вопрос «какой канал дал продажу?» всё чаще заменяется вопросом «какая связка данных помогает управлять выручкой». Хороший пример — Nike, которая в последние годы системно уводила маркетинг в сторону first-party-данных и server-side-аналитики.
Контекст был типичный для крупного ритейла: растущий объём трафика из paid social, поисковых кампаний, email и приложений, но при этом ухудшение видимости в клиентских браузерах. Из-за ограничений на cookies и блокировщиков часть конверсий переставала попадать в рекламные кабинеты. В итоге last-click-атрибуция всё сильнее занижала вклад верхних этапов воронки и переоценивала брендовый спрос.
Задача у Nike была не просто «сохранить измерение», а связать между собой сайт, приложение, CRM и офлайн-покупки так, чтобы маркетинг, продукт и e-commerce смотрели на одни и те же цифры. Для бренда такого масштаба это уже не история про отчётность, а про управление LTV (пожизненной ценностью клиента) и повторными покупками.
Что сделали:
— Перевели сбор ключевых событий на server-side: клики, добавления в корзину, покупки, авторизацию, подписки.
— Начали передавать события из своих серверов в рекламные платформы и аналитику с более чистыми идентификаторами.
— Усилили first-party-слой: логины, профили, данные приложения, история заказов.
— Свели измерение к нескольким уровням: платная реклама, собственные каналы, поведение на сайте и реальная выручка.
По сути, Nike ушла от модели, где маркетинг жил в рамках «последнего клика», к модели, где можно оценивать вклад канала в цепочку касаний. Это особенно важно в эпоху, когда AI-overviews и zero-click-сценарии сокращают объём прямого трафика: выигрывает не тот, кто собрал больше кликов, а тот, кто лучше связал их с выручкой.
Результат таких изменений обычно не сводится к одному красивому числу. Но бизнес-эффект понятен: меньше потерь событий, выше качество атрибуции, точнее работа с аудиторией для ремаркетинга и lookalike-подобных сегментов, лучше связка маркетинга с продажами и retention.
Урок здесь простой: server-side — это не «техническое улучшение ради отчёта». Это способ вернуть управляемость маркетингу, когда браузерная аналитика уже не отражает реальное влияние канала. И чем сложнее путь клиента, тем выше ценность собственной first-party-инфраструктуры.
— @ServerSideTrackingRuPro
В 2026-м старый вопрос «какой канал дал продажу?» всё чаще заменяется вопросом «какая связка данных помогает управлять выручкой». Хороший пример — Nike, которая в последние годы системно уводила маркетинг в сторону first-party-данных и server-side-аналитики.
Контекст был типичный для крупного ритейла: растущий объём трафика из paid social, поисковых кампаний, email и приложений, но при этом ухудшение видимости в клиентских браузерах. Из-за ограничений на cookies и блокировщиков часть конверсий переставала попадать в рекламные кабинеты. В итоге last-click-атрибуция всё сильнее занижала вклад верхних этапов воронки и переоценивала брендовый спрос.
Задача у Nike была не просто «сохранить измерение», а связать между собой сайт, приложение, CRM и офлайн-покупки так, чтобы маркетинг, продукт и e-commerce смотрели на одни и те же цифры. Для бренда такого масштаба это уже не история про отчётность, а про управление LTV (пожизненной ценностью клиента) и повторными покупками.
Что сделали:
— Перевели сбор ключевых событий на server-side: клики, добавления в корзину, покупки, авторизацию, подписки.
— Начали передавать события из своих серверов в рекламные платформы и аналитику с более чистыми идентификаторами.
— Усилили first-party-слой: логины, профили, данные приложения, история заказов.
— Свели измерение к нескольким уровням: платная реклама, собственные каналы, поведение на сайте и реальная выручка.
По сути, Nike ушла от модели, где маркетинг жил в рамках «последнего клика», к модели, где можно оценивать вклад канала в цепочку касаний. Это особенно важно в эпоху, когда AI-overviews и zero-click-сценарии сокращают объём прямого трафика: выигрывает не тот, кто собрал больше кликов, а тот, кто лучше связал их с выручкой.
Результат таких изменений обычно не сводится к одному красивому числу. Но бизнес-эффект понятен: меньше потерь событий, выше качество атрибуции, точнее работа с аудиторией для ремаркетинга и lookalike-подобных сегментов, лучше связка маркетинга с продажами и retention.
Урок здесь простой: server-side — это не «техническое улучшение ради отчёта». Это способ вернуть управляемость маркетингу, когда браузерная аналитика уже не отражает реальное влияние канала. И чем сложнее путь клиента, тем выше ценность собственной first-party-инфраструктуры.
— @ServerSideTrackingRuPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Cloudeflare грозит Google блокировкой трафика
Cloudflare объявил: с 15 сентября 2026 года ИИ-краулеры будут заблокированы по умолчанию на всех сайтах с рекламой — включая Googlebot, Applebot и Bingbot.
Главная претензия — к Google: один и тот же бот индексирует страницы и собирает данные для обучения нейросетей, что даёт поисковику нечестное преимущество.
Но есть нюанс, который меняет всю к…
➡️ Читайте на сайте: https://aff.top/blog/cloudeflare-grozit-google-blokirovkoi-trafika
🧠 Ещё больше инсайтов → в канале AFF.top
Cloudflare объявил: с 15 сентября 2026 года ИИ-краулеры будут заблокированы по умолчанию на всех сайтах с рекламой — включая Googlebot, Applebot и Bingbot.
Главная претензия — к Google: один и тот же бот индексирует страницы и собирает данные для обучения нейросетей, что даёт поисковику нечестное преимущество.
Но есть нюанс, который меняет всю к…
➡️ Читайте на сайте: https://aff.top/blog/cloudeflare-grozit-google-blokirovkoi-trafika
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Гайд: как заработать первые деньги на Pornhub
Pornhub — самый посещаемый адалт-сайт в мире, и на нём действительно можно зарабатывать. Но схема устроена иначе, чем кажется.
Автор залил ролики, набрал 16 000 просмотров — и получил 47 центов встроенной монетизации. Реальные деньги были в другом.
Есть нюансы с верификацией, голосом в роликах и законодательством РФ, которые ломают большинство с…
➡️ Читайте на сайте: https://aff.top/blog/gaid-kak-zarabotat-pervye-dengi-na-pornhub
🧠 Ещё больше инсайтов → в канале AFF.top
Pornhub — самый посещаемый адалт-сайт в мире, и на нём действительно можно зарабатывать. Но схема устроена иначе, чем кажется.
Автор залил ролики, набрал 16 000 просмотров — и получил 47 центов встроенной монетизации. Реальные деньги были в другом.
Есть нюансы с верификацией, голосом в роликах и законодательством РФ, которые ломают большинство с…
➡️ Читайте на сайте: https://aff.top/blog/gaid-kak-zarabotat-pervye-dengi-na-pornhub
🧠 Ещё больше инсайтов → в канале AFF.top
Разберите URL-параметры в серверном контейнере
В server-side tagging серверный контейнер принимает разные HTTP-запросы, а внутри них часто лежат URL-строки, зашитые в query-параметрах. Типичный пример — адрес страницы в старых и промежуточных схемах разметки. Если не распарсить такие данные на стороне сервера, часть полей уедет в хранилища и вендорам в «сыром» виде.
Чек-лист:
— Проверьте, где в запросах у вас спрятан URL.
Чаще всего это параметры вроде document location, referrer, landing page или кастомные поля из формы. Сначала найдите все точки входа, где URL передаётся как строка.
— Нормализуйте строку до разбора.
Перед парсингом убедитесь, что значение декодировано, без двойного URL-encoding и лишних символов. Иначе серверный шаблон будет резать не тот адрес.
— Выделите нужные части URL.
Отдельно извлеките протокол, домен, путь, UTM-метки, идентификаторы и hash-фрагмент. Это упрощает передачу данных в first-party хранилище и в рекламные системы.
— Отсекайте мусор до отправки дальше.
Не тащите в аналитику лишние параметры, служебные токены и дубли. Чем чище payload, тем меньше ошибок в атрибуции и отчётах.
— Проверьте логику для разных типов запросов.
Один и тот же URL может приходить из браузера, формы, CRM или бэкенда. Убедитесь, что шаблон корректно работает на всех источниках, а не только на веб-хите.
— Сверьте результат с downstream-системами.
После разбора посмотрите, как поля попадают в аналитический склад, рекламные API и BI-отчёты. Ошибка в серверном парсинге часто проявляется уже не в контейнере, а на этапе сравнения данных.
Когда это пригодится: при миграции на server-side analytics, настройке first-party трекинга и чистке URL-данных перед передачей в аналитику и вендорам.
— @ServerSideTrackingRuPro
В server-side tagging серверный контейнер принимает разные HTTP-запросы, а внутри них часто лежат URL-строки, зашитые в query-параметрах. Типичный пример — адрес страницы в старых и промежуточных схемах разметки. Если не распарсить такие данные на стороне сервера, часть полей уедет в хранилища и вендорам в «сыром» виде.
Чек-лист:
— Проверьте, где в запросах у вас спрятан URL.
Чаще всего это параметры вроде document location, referrer, landing page или кастомные поля из формы. Сначала найдите все точки входа, где URL передаётся как строка.
— Нормализуйте строку до разбора.
Перед парсингом убедитесь, что значение декодировано, без двойного URL-encoding и лишних символов. Иначе серверный шаблон будет резать не тот адрес.
— Выделите нужные части URL.
Отдельно извлеките протокол, домен, путь, UTM-метки, идентификаторы и hash-фрагмент. Это упрощает передачу данных в first-party хранилище и в рекламные системы.
— Отсекайте мусор до отправки дальше.
Не тащите в аналитику лишние параметры, служебные токены и дубли. Чем чище payload, тем меньше ошибок в атрибуции и отчётах.
— Проверьте логику для разных типов запросов.
Один и тот же URL может приходить из браузера, формы, CRM или бэкенда. Убедитесь, что шаблон корректно работает на всех источниках, а не только на веб-хите.
— Сверьте результат с downstream-системами.
После разбора посмотрите, как поля попадают в аналитический склад, рекламные API и BI-отчёты. Ошибка в серверном парсинге часто проявляется уже не в контейнере, а на этапе сравнения данных.
Когда это пригодится: при миграции на server-side analytics, настройке first-party трекинга и чистке URL-данных перед передачей в аналитику и вендорам.
— @ServerSideTrackingRuPro
Ретеншн без «магии»: как мы собрали server-side события и восстановили LTV-разрез в e-commerce (case breakdown)
Бренд/компания
Российский e-commerce (категория: товары повседневного спроса, цикл покупки — повторный). Маркетинг работал по набору кампаний и промокодов, но в аналитике «разъезжались» ключевые вещи: факт доставки/оплаты, корректный источник заказа и итоговая ценность клиента.
Задача
1) Перестать терять часть воронки в вебе и приложении из‑за блокировщиков, отказов и ограничений браузеров.
2) Собрать first-party событийную модель так, чтобы можно было строить когортные разрезы по доставленным заказам и реальной оплате.
3) Пересобрать атрибуцию для оптимизации: уходить от last-click к более устойчивому view на вклад каналов (в рамках доступных данных).
Решение
1) Server-side tracking как «источник истины»
— События с клиента (клики, просмотр карточки, добавление в корзину, начало оформления) отправлялись на сервер, а не напрямую в измерительную систему.
— На server-side происходили валидации (формат параметров, обязательные ключи), дедупликация и привязка к user/session_id.
— Для событий покупки добавили коррекцию: заказ фиксируется только после подтверждения статуса (оплата/закрытие), а не на момент нажатия «оплатить».
2) Единая схема событий и параметры качества
— В карточке события строго описали состав параметров: идентификаторы заказа, корзины/композиции, валюта, скидка/промокод (как *код*, а не как «картинка к баннеру»), а также канал-источник, который формируется по правилам на стороне сайта.
— Это позволило устранить типовую проблему: кампании с одинаковыми названиями в разных источниках начинали «смешиваться» в отчетах.
3) Консолидация клиента и когорт в first-party
— Стали использовать одинаковые идентификаторы на этапах: регистрация/логин/аноним до входа.
— При переходе из гостя в авторизованного пользователя сервер объединял историю по соответствию идентификаторов. В результате когорты начали строиться не «по кнопке», а по факту жизненного цикла.
4) RevOps-логика для ценности, а не для клика
Маркетинг не пытался «дожать» цифры показами. Вместо этого оптимизация опиралась на то, что влияет на выручку после первого визита: повторные покупки и их маржа. Для этого построили сегменты по статусам и времени между заказами.
Конкретный результат
— Веб- и app-данные перестали «рассыпаться» между платформами: доля полных purchase-событий (с ключевыми параметрами заказа) выросла, а расхождения между отчетами по статуса заказа сократились.
— Когорты по retention стали воспроизводимыми: повторные покупки начали попадать в правильные группы по типу промо и источнику привлечения.
— На уровне оптимизации кампаний стало понятно, какие каналы дают не просто первый заказ, а **возврат с измеряемой ценностью (LTV)** — в сегментах, где ранее аналитика переоценивала last-click из‑за потерь событий.
Урок для читателя
1) В 2026 задача не «подключить пиксель», а построить систему, где покупка подтверждается событием правильного статуса. Server-side — это способ сделать измерение устойчивым к приватности и техническим сбоям.
2) События без валидации и дедупликации всегда будут спорить между собой. Дисциплина схемы (что считается заказом, когда событие считается финальным) важнее частоты отправки.
3) Для e-commerce, где средний чек под давлением экономии, нельзя оптимизироваться только под первую покупку. Нужно переводить фокус на retention/LTV и строить когорты так, чтобы они не ломались при смене браузера или обновлении SDK.
4) Атрибуция становится инженерной задачей: приоритет — консистентность данных и инкрементальные (по смыслу) подходы, а не «клик ради клика».
Если хотите, могу в следующем посте дать шаблон server-side схемы событий для e-commerce: какие именно параметры хранить, как формировать финал покупки и как избежать смещения когорт при переходе user из гостя в авторизованного.
— @ServerSideTrackingRuPro
Бренд/компания
Российский e-commerce (категория: товары повседневного спроса, цикл покупки — повторный). Маркетинг работал по набору кампаний и промокодов, но в аналитике «разъезжались» ключевые вещи: факт доставки/оплаты, корректный источник заказа и итоговая ценность клиента.
Задача
1) Перестать терять часть воронки в вебе и приложении из‑за блокировщиков, отказов и ограничений браузеров.
2) Собрать first-party событийную модель так, чтобы можно было строить когортные разрезы по доставленным заказам и реальной оплате.
3) Пересобрать атрибуцию для оптимизации: уходить от last-click к более устойчивому view на вклад каналов (в рамках доступных данных).
Решение
1) Server-side tracking как «источник истины»
— События с клиента (клики, просмотр карточки, добавление в корзину, начало оформления) отправлялись на сервер, а не напрямую в измерительную систему.
— На server-side происходили валидации (формат параметров, обязательные ключи), дедупликация и привязка к user/session_id.
— Для событий покупки добавили коррекцию: заказ фиксируется только после подтверждения статуса (оплата/закрытие), а не на момент нажатия «оплатить».
2) Единая схема событий и параметры качества
— В карточке события строго описали состав параметров: идентификаторы заказа, корзины/композиции, валюта, скидка/промокод (как *код*, а не как «картинка к баннеру»), а также канал-источник, который формируется по правилам на стороне сайта.
— Это позволило устранить типовую проблему: кампании с одинаковыми названиями в разных источниках начинали «смешиваться» в отчетах.
3) Консолидация клиента и когорт в first-party
— Стали использовать одинаковые идентификаторы на этапах: регистрация/логин/аноним до входа.
— При переходе из гостя в авторизованного пользователя сервер объединял историю по соответствию идентификаторов. В результате когорты начали строиться не «по кнопке», а по факту жизненного цикла.
4) RevOps-логика для ценности, а не для клика
Маркетинг не пытался «дожать» цифры показами. Вместо этого оптимизация опиралась на то, что влияет на выручку после первого визита: повторные покупки и их маржа. Для этого построили сегменты по статусам и времени между заказами.
Конкретный результат
— Веб- и app-данные перестали «рассыпаться» между платформами: доля полных purchase-событий (с ключевыми параметрами заказа) выросла, а расхождения между отчетами по статуса заказа сократились.
— Когорты по retention стали воспроизводимыми: повторные покупки начали попадать в правильные группы по типу промо и источнику привлечения.
— На уровне оптимизации кампаний стало понятно, какие каналы дают не просто первый заказ, а **возврат с измеряемой ценностью (LTV)** — в сегментах, где ранее аналитика переоценивала last-click из‑за потерь событий.
Урок для читателя
1) В 2026 задача не «подключить пиксель», а построить систему, где покупка подтверждается событием правильного статуса. Server-side — это способ сделать измерение устойчивым к приватности и техническим сбоям.
2) События без валидации и дедупликации всегда будут спорить между собой. Дисциплина схемы (что считается заказом, когда событие считается финальным) важнее частоты отправки.
3) Для e-commerce, где средний чек под давлением экономии, нельзя оптимизироваться только под первую покупку. Нужно переводить фокус на retention/LTV и строить когорты так, чтобы они не ломались при смене браузера или обновлении SDK.
4) Атрибуция становится инженерной задачей: приоритет — консистентность данных и инкрементальные (по смыслу) подходы, а не «клик ради клика».
Если хотите, могу в следующем посте дать шаблон server-side схемы событий для e-commerce: какие именно параметры хранить, как формировать финал покупки и как избежать смещения когорт при переходе user из гостя в авторизованного.
— @ServerSideTrackingRuPro
Когда last-click не работает: метрики ответственности в B2B
Классический last-click (клик по последнему касанию) в B2B-воронке умирает не столько из-за блокировщиков рекламы, сколько из-за структурного несоответствия. Если вы всё ещё считаете ROAS (возврат на рекламу) по последнему клику в цепочке из 5–15 касаний, вы систематически занижаете вклад ассистирующих каналов и переоцениваете закрывающие.
В 2026 году B2B-маркетинг уже не про «привёл лид — молодец». RevOps (управление выручкой) требует, чтобы маркетинг отвечал за сквозную экономику сделки, а не за заполнение CRM контактами. И здесь серверный трекинг становится не просто способом сохранить данные, а фундаментом для метрик ответственности.
Почему? Потому что MMM (маркетинг-микс-моделирование) и инкрементальный замер (incrementality) требуют агрегированных сигналов на уровне пользовательских когорт, а не мусора из браузерных cookie. Без server-side сбора данных о повторных визитах, времени до конверсии и пересечениях каналов вы не построите адекватную causal-модель (причинно-следственную). Вы останетесь с логами рекламных систем, которые сами себе и скаут, и судья.
Наблюдение из практики этого года: в одном B2B-продукте с циклом сделки 4 месяца мы заменили click-based атрибуцию
— @ServerSideTrackingRuPro
Классический last-click (клик по последнему касанию) в B2B-воронке умирает не столько из-за блокировщиков рекламы, сколько из-за структурного несоответствия. Если вы всё ещё считаете ROAS (возврат на рекламу) по последнему клику в цепочке из 5–15 касаний, вы систематически занижаете вклад ассистирующих каналов и переоцениваете закрывающие.
В 2026 году B2B-маркетинг уже не про «привёл лид — молодец». RevOps (управление выручкой) требует, чтобы маркетинг отвечал за сквозную экономику сделки, а не за заполнение CRM контактами. И здесь серверный трекинг становится не просто способом сохранить данные, а фундаментом для метрик ответственности.
Почему? Потому что MMM (маркетинг-микс-моделирование) и инкрементальный замер (incrementality) требуют агрегированных сигналов на уровне пользовательских когорт, а не мусора из браузерных cookie. Без server-side сбора данных о повторных визитах, времени до конверсии и пересечениях каналов вы не построите адекватную causal-модель (причинно-следственную). Вы останетесь с логами рекламных систем, которые сами себе и скаут, и судья.
Наблюдение из практики этого года: в одном B2B-продукте с циклом сделки 4 месяца мы заменили click-based атрибуцию
— @ServerSideTrackingRuPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Сбер запустит свой криптокошелёк
Сбер готов запустить криптокошелёк — инфраструктура уже есть. Ждут только закона о регулировании крипты, который планируют принять к 1 сентября 2026 года.
Хранить и, судя по всему, обменивать крипту можно будет прямо в приложении — без сторонних обменников.
Но есть один нюанс, из-за которого обменники никуда не денутся. 🔍
➡️ Читайте на сайте: https://aff.top/blog/sber-zapustit-svoi-kriptokoshelek
🧠 Ещё больше инсайтов → в канале AFF.top
Сбер готов запустить криптокошелёк — инфраструктура уже есть. Ждут только закона о регулировании крипты, который планируют принять к 1 сентября 2026 года.
Хранить и, судя по всему, обменивать крипту можно будет прямо в приложении — без сторонних обменников.
Но есть один нюанс, из-за которого обменники никуда не денутся. 🔍
➡️ Читайте на сайте: https://aff.top/blog/sber-zapustit-svoi-kriptokoshelek
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Индия потребовала от Telegram удалять пиратский контент
Индия потребовала от Telegram удалять пиратский контент — претензия в том, что платформа не ограничивает размер файлов, что позволяет свободно распространять фильмы.
Дуров ответил, что Telegram годами работает в Индии без какой-либо коммерческой выгоды для себя.
Почему давление началось именно сейчас — вопрос открытый. Возможный ответ — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/indiia-potrebovala-ot-telegram-udaliat-piratskii-kontent
🧠 Ещё больше инсайтов → в канале AFF.top
Индия потребовала от Telegram удалять пиратский контент — претензия в том, что платформа не ограничивает размер файлов, что позволяет свободно распространять фильмы.
Дуров ответил, что Telegram годами работает в Индии без какой-либо коммерческой выгоды для себя.
Почему давление началось именно сейчас — вопрос открытый. Возможный ответ — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/indiia-potrebovala-ot-telegram-udaliat-piratskii-kontent
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Google ads меняет стратегию по конверсиям
Google меняет логику автоматических стратегий ставок: с 17 августа 2026 года кампании будут строже придерживаться указанного целевого CPA, а не давать лиды по минимально возможной цене.
Если сейчас твоя кампания даёт лиды по $5, а цель стоит $10 — после обновления алгоритм «поднимет» фактическую стоимость лида к целевой, зато отдаст больше трафик…
➡️ Читайте на сайте: https://aff.top/blog/google-ads-meniaet-strategiiu-po-konversiiam
🧠 Ещё больше инсайтов → в канале AFF.top
Google меняет логику автоматических стратегий ставок: с 17 августа 2026 года кампании будут строже придерживаться указанного целевого CPA, а не давать лиды по минимально возможной цене.
Если сейчас твоя кампания даёт лиды по $5, а цель стоит $10 — после обновления алгоритм «поднимет» фактическую стоимость лида к целевой, зато отдаст больше трафик…
➡️ Читайте на сайте: https://aff.top/blog/google-ads-meniaet-strategiiu-po-konversiiam
🧠 Ещё больше инсайтов → в канале AFF.top
Server-side аналитика для ритейла: как Lamoda собрала данные о возвратах в единый контур
Контекст
В 2024-2025 рынок fashion-ритейла в РФ столкнулся с двойным давлением: средний чек просел на 6-8%, а доля возвратов в сегменте одежды и обуви стабильно держится выше 30%. Каждый возврат — это не просто логистическая потеря, а слепое пятно в воронке: клиентский путь обрывается, и маркетинг продолжает платить за привлечение пользователя, который уже ушёл.
У Lamoda к этому моменту был зрелый стек: собственный CDP (платформа клиентских данных), события с сайта и приложения стекались в аналитику через Google Analytics 360 и внутренний DWH (хранилище данных). Но событие «возврат» жило в учётной системе 1С и SAP, почти не пересекаясь с маркетинговыми данными. Получался парадокс: команда performance видела клики и заказы, а финансовый эффект кампаний — нет.
Задача
Связать офлайн-события возвратов с онлайн-идентификаторами пользователя, чтобы:
— считать реальную маржинальность кампаний после возвратов;
— сегментировать аудиторию по склонности к возврату и не платить за её повторное привлечение;
— передавать сигнал в MMM-модель (модель смешения маркетинговых каналов) для корректной атрибуции.
Решение
Команда аналитики Lamoda совместно с data-инженерами реализовала классический server-side подход (обработка данных на сервере, а не в браузере пользователя):
1. Событие возврата из SAP начали отправлять на серверный контейнер Google Tag Manager Server-Side. Идентификатором служил user_id из CDP, а не cookie или client_id браузера.
2. На сервере событие обогащалось: подтягивались история покупок, источник первого касания, RFM-сегмент (сегментация по давности, частоте и сумме покупок) клиента. После этого данные уходили и в GA4, и во внутреннее DWH.
3. В BigQuery построили витрину, где каждой транзакции присваивался статус «чистая» (без возврата) или «с возвратом». Эту витрину отдали медиабайерам через Looker-дашборд и подключили к MMM.
4. Возвратные сегменты вынесли в отдельные аудитории и исключили из look-alike (поиск похожих пользователей) для performance-кампаний.
Результат
— Доля возвратов в performance-кампаниях снизилась с 34% до 27% за полгода.
— CPO (стоимость подтверждённого заказа) с поправкой на возвраты вырос в отчётности на 12%, но фактически это был не рост затрат, а честный учёт — раньше эти деньги просто не были видны.
— MMM после включения сигнала о возвратах пересчитал вес каналов: доля brand-search (поиск по бренду) в модели выросла, а у ряда performance-кампаний снизилась. Бюджет перераспределили, общий ROAS (окупаемость рекламных расходов) вырос на 8%.
Урок
Возврат — это такое же продуктовое событие, как покупка или отписка. Если оно не попадает в маркетинговый контур, вы оптимизируете воронку по верхней части и платите дважды: за привлечение и за повторное привлечение того же пользователя.
Server-side здесь — не про «модный стек», а про право бизнеса видеть собственный клиентский путь без потерь. Браузерная аналитика возвраты просто не ловит: cookie живёт 14 дней, а возврат часто случается на 10-15 день. Только серверная связка идентификаторов даёт целостную картину.
В эпоху, когда retention (удержание клиентов) и LTV (пожизненная ценность клиента) важнее первой покупки, такие «неудобные» события определяют, кто из маркетологов выживет — тот, кто считает метрики честно.
— @ServerSideTrackingRuPro
Контекст
В 2024-2025 рынок fashion-ритейла в РФ столкнулся с двойным давлением: средний чек просел на 6-8%, а доля возвратов в сегменте одежды и обуви стабильно держится выше 30%. Каждый возврат — это не просто логистическая потеря, а слепое пятно в воронке: клиентский путь обрывается, и маркетинг продолжает платить за привлечение пользователя, который уже ушёл.
У Lamoda к этому моменту был зрелый стек: собственный CDP (платформа клиентских данных), события с сайта и приложения стекались в аналитику через Google Analytics 360 и внутренний DWH (хранилище данных). Но событие «возврат» жило в учётной системе 1С и SAP, почти не пересекаясь с маркетинговыми данными. Получался парадокс: команда performance видела клики и заказы, а финансовый эффект кампаний — нет.
Задача
Связать офлайн-события возвратов с онлайн-идентификаторами пользователя, чтобы:
— считать реальную маржинальность кампаний после возвратов;
— сегментировать аудиторию по склонности к возврату и не платить за её повторное привлечение;
— передавать сигнал в MMM-модель (модель смешения маркетинговых каналов) для корректной атрибуции.
Решение
Команда аналитики Lamoda совместно с data-инженерами реализовала классический server-side подход (обработка данных на сервере, а не в браузере пользователя):
1. Событие возврата из SAP начали отправлять на серверный контейнер Google Tag Manager Server-Side. Идентификатором служил user_id из CDP, а не cookie или client_id браузера.
2. На сервере событие обогащалось: подтягивались история покупок, источник первого касания, RFM-сегмент (сегментация по давности, частоте и сумме покупок) клиента. После этого данные уходили и в GA4, и во внутреннее DWH.
3. В BigQuery построили витрину, где каждой транзакции присваивался статус «чистая» (без возврата) или «с возвратом». Эту витрину отдали медиабайерам через Looker-дашборд и подключили к MMM.
4. Возвратные сегменты вынесли в отдельные аудитории и исключили из look-alike (поиск похожих пользователей) для performance-кампаний.
Результат
— Доля возвратов в performance-кампаниях снизилась с 34% до 27% за полгода.
— CPO (стоимость подтверждённого заказа) с поправкой на возвраты вырос в отчётности на 12%, но фактически это был не рост затрат, а честный учёт — раньше эти деньги просто не были видны.
— MMM после включения сигнала о возвратах пересчитал вес каналов: доля brand-search (поиск по бренду) в модели выросла, а у ряда performance-кампаний снизилась. Бюджет перераспределили, общий ROAS (окупаемость рекламных расходов) вырос на 8%.
Урок
Возврат — это такое же продуктовое событие, как покупка или отписка. Если оно не попадает в маркетинговый контур, вы оптимизируете воронку по верхней части и платите дважды: за привлечение и за повторное привлечение того же пользователя.
Server-side здесь — не про «модный стек», а про право бизнеса видеть собственный клиентский путь без потерь. Браузерная аналитика возвраты просто не ловит: cookie живёт 14 дней, а возврат часто случается на 10-15 день. Только серверная связка идентификаторов даёт целостную картину.
В эпоху, когда retention (удержание клиентов) и LTV (пожизненная ценность клиента) важнее первой покупки, такие «неудобные» события определяют, кто из маркетологов выживет — тот, кто считает метрики честно.
— @ServerSideTrackingRuPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
В Codex внедрят GPT-5.6 Ultra
OpenAI добавит в Codex эксклюзивную версию GPT-5.6 Sol Ultra — не ту, что выйдет в паблик, а отдельную, усиленную модель.
Два ключевых режима: расширенные рассуждения (модель думает дольше) и мульти-агентная работа с параллельными субагентами. Релиз ожидается 7–9 июля 2026.
Но есть один нюанс, который OpenAI пока не раскрывает 👀 Подробности — в …
➡️ Читайте на сайте: https://aff.top/blog/v-codex-vnedriat-gpt-5-6-ultra
🧠 Ещё больше инсайтов → в канале AFF.top
OpenAI добавит в Codex эксклюзивную версию GPT-5.6 Sol Ultra — не ту, что выйдет в паблик, а отдельную, усиленную модель.
Два ключевых режима: расширенные рассуждения (модель думает дольше) и мульти-агентная работа с параллельными субагентами. Релиз ожидается 7–9 июля 2026.
Но есть один нюанс, который OpenAI пока не раскрывает 👀 Подробности — в …
➡️ Читайте на сайте: https://aff.top/blog/v-codex-vnedriat-gpt-5-6-ultra
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Компания Meta выпустила Muse Image
Meta выпустила Muse Image — нейросеть, которая генерирует изображения как агент: сама ищет референсы, пишет код и рассуждает перед созданием картинки.
Одна из фишек — можно скинуть ссылку на публичный профиль человека в соцсети, и модель возьмёт его внешность за референс.
Есть один вопрос, который интересует всех арбитражников: как это повлияет …
➡️ Читайте на сайте: https://aff.top/blog/kompaniia-meta-vypustila-muse-image
🧠 Ещё больше инсайтов → в канале AFF.top
Meta выпустила Muse Image — нейросеть, которая генерирует изображения как агент: сама ищет референсы, пишет код и рассуждает перед созданием картинки.
Одна из фишек — можно скинуть ссылку на публичный профиль человека в соцсети, и модель возьмёт его внешность за референс.
Есть один вопрос, который интересует всех арбитражников: как это повлияет …
➡️ Читайте на сайте: https://aff.top/blog/kompaniia-meta-vypustila-muse-image
🧠 Ещё больше инсайтов → в канале AFF.top
Server-side не про “теги”, а про ответственность
Мне кажется, в 2026 большинство команд по-прежнему спорят только о том, куда поставить очередной пиксель. А проблема глубже: без серверной валидации и единых first-party правил события легко превращаются в шум, и тогда любые метрики (конверсии, доля повторных визитов, качество лидов) начинают спорить с бизнесом. Особенно в RevOps-реальности, где маркетинг, sales и customer success отвечают за выручку — не за красивый отчёт. Если вы не управляете сбором данных как продуктом, “точность” всегда будет случайной.
— @ServerSideTrackingRuPro
Мне кажется, в 2026 большинство команд по-прежнему спорят только о том, куда поставить очередной пиксель. А проблема глубже: без серверной валидации и единых first-party правил события легко превращаются в шум, и тогда любые метрики (конверсии, доля повторных визитов, качество лидов) начинают спорить с бизнесом. Особенно в RevOps-реальности, где маркетинг, sales и customer success отвечают за выручку — не за красивый отчёт. Если вы не управляете сбором данных как продуктом, “точность” всегда будет случайной.
— @ServerSideTrackingRuPro
Forwarded from Я ЗЛОЙ, Я ГАНГСТА
This media is not supported in your browser
VIEW IN TELEGRAM
Хоменок потребовал, чтобы кардиналы уволили Иванова — новая драма из нижней аффилки.
Вспоминаем этого персонажа: в преддверии МАК и джигейт конф овнер Х6 Group Антон Хоменок назвал себя «инфлюенсером года» и заявил, что если не выиграет награды — значит, премии на конфах купленные. Как и можно было ожидать, умник ничерта не выиграл, но это унижение не помешало ему сделать предложение своей девушке на «коррумпированной» сцене джигеев.
Так вот, на конфе Хоменок посоветовал СЕО кардиналов уволить ЕЮ — мол, он фрик, с которым нельзя сотрудничать. Эта инфа разумеется дошла до Иванова — в ответ он предложил выкупить всю конторку кардиналов (их овнер пока не ответил). Вообще удивительно, с какой уверенностью Антоха даёт коллегам по сфере советы, не понимая базовые вещи (например, тот факт, что ЕЮ — вообще не наёмный сотрудник). Под конец Хоменок слился со стрима с Ивановым, заваливая его комплиментами — ожидаемое лицемерие, что тут скажешь.
К слову, когда ЕЮ спросил у Алексеева, уволил бы тот его, овнер приватов ответил, что скорее Иванов его уволит (что, может, и не так, но главному алкашу сферы всё равно было приятно).
🥴 — «инфлюенсер года», хуле
🤡 — типичный ЧСВшник без реальных достижений в сфере, такая лайф
😈 Я ЗЛОЙ, Я ГАНГСТА
Вспоминаем этого персонажа: в преддверии МАК и джигейт конф овнер Х6 Group Антон Хоменок назвал себя «инфлюенсером года» и заявил, что если не выиграет награды — значит, премии на конфах купленные. Как и можно было ожидать, умник ничерта не выиграл, но это унижение не помешало ему сделать предложение своей девушке на «коррумпированной» сцене джигеев.
Так вот, на конфе Хоменок посоветовал СЕО кардиналов уволить ЕЮ — мол, он фрик, с которым нельзя сотрудничать. Эта инфа разумеется дошла до Иванова — в ответ он предложил выкупить всю конторку кардиналов (их овнер пока не ответил). Вообще удивительно, с какой уверенностью Антоха даёт коллегам по сфере советы, не понимая базовые вещи (например, тот факт, что ЕЮ — вообще не наёмный сотрудник). Под конец Хоменок слился со стрима с Ивановым, заваливая его комплиментами — ожидаемое лицемерие, что тут скажешь.
К слову, когда ЕЮ спросил у Алексеева, уволил бы тот его, овнер приватов ответил, что скорее Иванов его уволит (что, может, и не так, но главному алкашу сферы всё равно было приятно).
🥴 — «инфлюенсер года», хуле
🤡 — типичный ЧСВшник без реальных достижений в сфере, такая лайф
Please open Telegram to view this post
VIEW IN TELEGRAM