Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
В Whatsapp скамят пользователей с помощью поддельных никнеймов
WhatsApp запустил никнеймы — и почти сразу начался скам. Мошенники регистрируют имена, похожие на бренды, звёзд и политиков, с минимальными опечатками.
Индия, где 500 млн пользователей WhatsApp, потребовала от Meta объяснений за 3 дня. Meta говорит, что точные совпадения заблокированы — но одна буква в другом месте защиту не триггерит.
Похоже, п…
➡️ Читайте на сайте: https://aff.top/blog/v-whatsapp-skamiat-polzovatelei-s-pomoschiu-poddelnykh-nikneimov
🧠 Ещё больше инсайтов → в канале AFF.top
WhatsApp запустил никнеймы — и почти сразу начался скам. Мошенники регистрируют имена, похожие на бренды, звёзд и политиков, с минимальными опечатками.
Индия, где 500 млн пользователей WhatsApp, потребовала от Meta объяснений за 3 дня. Meta говорит, что точные совпадения заблокированы — но одна буква в другом месте защиту не триггерит.
Похоже, п…
➡️ Читайте на сайте: https://aff.top/blog/v-whatsapp-skamiat-polzovatelei-s-pomoschiu-poddelnykh-nikneimov
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Вышел ZCode - аналог Claude code
Вышел ZCode — десктопный аналог Claude Code от разработчиков GLM-5.2. Работает с API от Anthropic, поддерживает SSH-деплой на сервер, в том числе Linux.
Вместо пошаговых скриптов — система целеполагания Goal: закидываешь сложный промт, агент сам разбивает задачу и выполняет. Плюс управление через Telegram-бота.
Но главная фича — мультиагентность…
➡️ Читайте на сайте: https://aff.top/blog/vyshel-zcode-analog-claude-code
🧠 Ещё больше инсайтов → в канале AFF.top
Вышел ZCode — десктопный аналог Claude Code от разработчиков GLM-5.2. Работает с API от Anthropic, поддерживает SSH-деплой на сервер, в том числе Linux.
Вместо пошаговых скриптов — система целеполагания Goal: закидываешь сложный промт, агент сам разбивает задачу и выполняет. Плюс управление через Telegram-бота.
Но главная фича — мультиагентность…
➡️ Читайте на сайте: https://aff.top/blog/vyshel-zcode-analog-claude-code
🧠 Ещё больше инсайтов → в канале AFF.top
Как 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