Инкрементальность как новый язык performance-маркетинга

Последние два квартала на рынке заметно меняется отношение к атрибуции. Команды, которые ещё недавно спорили, какой атрибуционный модель верить — last-click или data-driven — теперь задают другой вопрос: а касался ли этот контакт реальной выручки или мы просто списали на канал органический спрос.

Связка server-side, MMM (маркетинг-микс-моделирование) и инкрементальные тесты перестаёт быть премиум-опцией для крупных платформ. Это базовая гигиена для среднего бизнеса, который работает с рекламным бюджетом от 1–2 млн в месяц. Один мой собеседник из e-com проекта перешёл на регулярные гео-холд-ауты (тесты, где часть регионов не видит рекламу) и обнаружил, что треть расходов на ретаргетинг не добавляла продаж, а лишь конкурировала с уже принятым решением о покупке. Деньги не «уходили в молоко» — они физически забирали конверсии у собственного brand-трафика.

Командам, которые только выстраивают подход, советую начать с трёх шагов. Первое — собрать сырые данные по расходам и выручке в чистом виде, без витрин, в одном хранилище. Второе — определить 2–3 ключевых канала, по которым уже есть гипотезы о реальном вкладе, и запустить на них инкрементальный тест. Не нужно покрывать всё сразу. Третье — заложить регулярный ритм замера, а не разовый аудит, иначе данные быстро устаревают.

Главная ловушка — попытка построить идеальную MMM-модель до того, как команда научилась читать её выводы. Инструмент не равен решению. Решение появляется, когда в команде есть человек, способный перевести коэффициенты модели в управленческое действие: перераспределить бюджет, сократить канал, пересобрать креативы. Без такого переводчика даже дорогая модель превращается в красивый отчёт, который никто не открывает.

— @MarTechStackRuPro

Алиса AI будет конкурировать с Google AI Studio

Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…

➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio

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

В Zennoposter добавили ИИ-помощник

Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…

➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik

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

Topical Authority в 2026: меньше “контента”, больше контролируемой экспертизы

В подборе инструментов для маркетинга я всё чаще вижу, как команды недооценивают топикальную (тематическую) авторитетность: не как “сколько постов”, а как “насколько система видит вас источником по кластеру”. В эпоху AI-overviews (обзоров) это бьёт по CTR, а значит и по качеству лидов/заявок. Поэтому инструментам для исследований и обогащения базы знаний я доверяю больше, чем бесконечным публикациям: ценность смысла должна быть встроена в данные, а не только в текст.

— @MarTechStackRuPro

Новую Google reCapcha прошли статичной картинкой

Google выпустил обновленную reCAPTCHA, требующую движений рук для прохождения, но система оказалась уязвима к обходу. Достаточно транслировать статичное изображение с нужным жестом через виртуальную камеру с помощью простого Python-скрипта, чтобы нейросеть пропустила пользователя. Это создает серьёзный риск для сайтов: защита от ботов, позиционировавшаяся как прорыв, на деле не работает. Баг остается актуальным и позволяет спамерам легко автомат…

➡️ Читайте на сайте: https://aff.top/blog/novuiu-google-recapcha-proshli-statichnoi-kartinkoi

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

DeepSeek представит последнюю версию v4

DeepSeek выпустит v4 в середине июля с новой моделью ценообразования API: токены подорожают в 2 раза в часы пиковой нагрузки (09:00–12:00 и 14:00–18:00 по пекинскому времени). Компания планирует уведомлять пользователей по почте за 24 часа до изменения тарифов. Проблема с ошибками «server busy» останется, но обойдётся дороже — это может существенно повлиять на экономику проектов, которые активно используют API DeepSeek для автоматизации и масшта…

➡️ Читайте на сайте: https://aff.top/blog/deepseek-predstavit-posledniuiu-versiiu-v4

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

Anthropic выпустили Sonnet 5

30 июня вышла Claude Sonnet 5 — новая версия позиционируется как самая агентная в линейке и приближается к флагманской Opus 4.8. Модель лучше справляется со сложными многоуровневыми задачами, устойчива к вредоносным запросам и не генерирует эксплойты. Sonnet 5 доступна на Free-тарифе, но тестирование показало скромные улучшения: хотя работает лучше Sonnet 4.6, её обгоняют конкуренты, включая китайские модели, которые дешевле через API при лучшей…

➡️ Читайте на сайте: https://aff.top/blog/anthropic-vypustili-sonnet-5

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

Почему в 2026 я начинаю MarTech-стек не с CRM, а с событийной модели

Когда ко мне приходит маркетинг-оператор с задачей «собрать стек», почти всегда разговор начинается не с инструментов, а с архитектуры данных. И я считаю это правильным. Потому что CRM, CDP, аналитика, email, пуши, рекламные кабинеты и BI без общей событийной модели превращаются в набор красивых, но слабо связанных коробок.

Мой рабочий принцип такой: **сначала фиксируем, какие события вообще важны бизнесу, потом уже выбираем, чем их хранить и где ими управлять**.

Почему это стало критично именно сейчас:
— классический last-click теряет смысл, а значит, ценность каждого касания нужно собирать на уровне событий;
— в B2B MQL и SQL уже не дают целостной картины, потому что выручка рождается в связке маркетинга, продаж и клиентского успеха;
— в e-com и подписках выигрывает не тот, кто громче привёл, а тот, кто точнее видит путь к повторной покупке и удержанию.

Из практики: в одном B2B-проекте мы сначала «докрутили» аналитику и только потом пересобрали стек. В результате количество используемых инструментов не выросло, а решения стали быстрее. Просто потому, что у команды появилась единая схема: какое событие за что отвечает, кто владелец, куда оно уходит и как влияет на выручку. До этого у них было 14 интеграций, а согласованности — почти ноль.

Я вижу типичную ошибку: компании покупают MarTech как набор функций. На самом деле покупать нужно **согласованность процессов**. Инструменты должны не просто собирать данные, а поддерживать управленческую логику:
— один источник правды по событиям;
— прозрачные правила обогащения данных;
— понятный маршрут от события к действию;
— возможность проверить влияние не только по отчётам, но и через инкрементальность.

Если коротко: в 2026 хороший MarTech-стек — это не «много сервисов». Это система, где любое событие можно довести до решения, а любое решение — до измеримого эффекта.

— @MarTechStackRu

По этой же теме советуем @PanelDataRoom

Clickstar прекращает работу

Clickstar закрывается. Легендарная пуш-сеть прекращает закуп трафика с 1 августа, полная остановка — 20 августа.

Сетка работала почти 8 лет и была одним из лучших источников качественного трафика на Россию и СНГ. Сейчас пуш-трафик стал слишком ботовым из-за гугловских банов на скрипты сбора.

Что это означает для арбитражников — разбираемся в ста…

➡️ Читайте на сайте: https://aff.top/blog/clickstar-prekraschaet-rabotu

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

Тинькофф: как собрать маркетинговый стек под рост без зоопарка инструментов

В 2026 году у маркетинг-операций одна и та же боль: инструментов много, данных ещё больше, а связности между ними мало. Кейс Тинькофф хорошо показывает, как из этого выйти без бесконечных ручных склеек.

Контекст был такой: у банка десятки продуктовых направлений, несколько команд маркетинга, высокий объём трафика и необходимость быстро понимать, что реально двигает выручку, а что просто создаёт красивую отчётность. При классической схеме «рекламная платформа → аналитика → BI» начинали ломаться атрибуция, сегментация и скорость принятия решений.

Задача звучала просто, но на деле это типичный RevOps-вызов: собрать единый контур данных для маркетинга, продаж и продукта, чтобы можно было видеть путь клиента сквозь каналы, касания и конверсии, а не только последний клик.

Решение строили не вокруг «ещё одного дашборда», а вокруг архитектуры:
— серверный сбор событий, чтобы снизить потери данных в privacy-first среде;
— единый слой идентификации пользователя между приложением, сайтом и CRM;
— автоматическая передача аудиторных сегментов в рекламные кабинеты;
— BI-слой с общими метриками для маркетинга и бизнеса;
— отдельные контуры для проверки инкрементальности, а не только last-click.

Смысл был в том, чтобы убрать ручной Excel-операционал и сделать так, чтобы маркетолог видел не только CPL, а вклад канала в выручку и удержание. Это особенно важно сейчас, когда MQL/SQL-модель слабеет, а ценность смещается в LTV и повторные касания.

Результат такого подхода измеряется не одной цифрой, а набором эффектов:
— меньше потерь событий на стороне браузера;
— быстрее сегментация и запуск кампаний;
— точнее сравнение каналов по инкрементальному эффекту;
— меньше конфликтов между маркетингом, аналитикой и продажами из-за разных «истин» в отчётах.

**Главный урок**: современный MarTech-стек — это не набор SaaS-сервисов, а система принятия решений. Если в ней нет единого идентификатора, серверного сбора и общей метрики выручки, то рост бюджета почти неизбежно превращается в рост шума.

Для marketing operations отсюда практический вывод простой: сначала проектируете данные и правила атрибуции, потом покупаете инструменты. Иначе стек становится дороже, а управляемость — слабее.

— @MarTechStackRuPro

Facebook запретил рекламу онлайн-казино Mr Vegas

Британский ASA запретил рекламу казино Mr Vegas из-за «слишком милых» мультяшных животных в креативах — регулятор счёл, что такой стиль привлекает детей, в том числе через Facebook. Рекламодатель запустил кампанию в феврале, бан вышел в июле. Логика регулятора вызывает вопросы: дети неплатёжеспособны, а таргетировать их на гемблинг бессмысленно.

➡️ Читайте на сайте: https://aff.top/blog/facebook-zapretil-reklamu-onlain-kazino-mr-vegas

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

В Whatsapp скамят пользователей с помощью поддельных никнеймов

WhatsApp запустил никнеймы — и почти сразу начался скам. Мошенники регистрируют имена, похожие на бренды, звёзд и политиков, с минимальными опечатками.

Индия, где 500 млн пользователей WhatsApp, потребовала от Meta объяснений за 3 дня. Meta говорит, что точные совпадения заблокированы — но одна буква в другом месте защиту не триггерит.

Похоже, п…

➡️ Читайте на сайте: https://aff.top/blog/v-whatsapp-skamiat-polzovatelei-s-pomoschiu-poddelnykh-nikneimov

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

Вышел 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

Как MarTech-стек помогает сократить ручную работу в B2B-воронке

У многих B2B-команд проблема не в нехватке лидов, а в том, что маркетинг, продажи и клиентский успех живут в разных таблицах. В 2026 году это особенно больно: классическая связка MQL → SQL работает слабее, а на первый план выходит RevOps — общая ответственность за выручку.

Компания из B2B-сегмента столкнулась именно с этим: данные о лидах, сделках и коммуникациях были разнесены по CRM, email-платформе, аналитике сайта и таблицам. Из-за этого команда теряла время на ручные сверки, а воронка считалась с задержкой. Маркетинг не мог быстро ответить, какие каналы реально двигают сделку, а продажи не видели полной истории контакта.

Решение собрали как типичный MarTech-стек для операционной зрелости:
— CRM как единый источник по сделкам и стадиям;
— серверная передача событий с сайта, чтобы не зависеть только от cookie и клиентских скриптов;
— сквозная аналитика по источникам и касаниям;
— автоматические правила синхронизации между маркетингом и продажами;
— дашборд для общей команды, где видны лиды, конверсия по этапам и скорость прохождения воронки.

Что это дало по эффекту:
— сократилось время на ручную отчетность;
— уменьшилось число ошибок при переносе данных;
— появилась возможность смотреть на вклад каналов не только по последнему клику, а по всей цепочке касаний;
— команда быстрее находила узкие места в воронке и перераспределяла бюджет.

Главный урок для маркетинг-операций простой: **MarTech нужен не ради набора модных инструментов, а ради управляемости выручкой**. Если в вашей системе нет единого контура данных, то даже хороший трафик превращается в спор о цифрах. В 2026 году выигрывают не те, кто нарастил отчеты, а те, кто собрал инфраструктуру, где маркетинг, продажи и клиентский успех смотрят на одну картину.

— @MarTechStackRu

Cloudeflare грозит Google блокировкой трафика

Cloudflare объявил: с 15 сентября 2026 года ИИ-краулеры будут заблокированы по умолчанию на всех сайтах с рекламой — включая Googlebot, Applebot и Bingbot.

Главная претензия — к Google: один и тот же бот индексирует страницы и собирает данные для обучения нейросетей, что даёт поисковику нечестное преимущество.

Но есть нюанс, который меняет всю к…

➡️ Читайте на сайте: https://aff.top/blog/cloudeflare-grozit-google-blokirovkoi-trafika

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

Гайд: как заработать первые деньги на Pornhub

Pornhub — самый посещаемый адалт-сайт в мире, и на нём действительно можно зарабатывать. Но схема устроена иначе, чем кажется.

Автор залил ролики, набрал 16 000 просмотров — и получил 47 центов встроенной монетизации. Реальные деньги были в другом.

Есть нюансы с верификацией, голосом в роликах и законодательством РФ, которые ломают большинство с…

➡️ Читайте на сайте: https://aff.top/blog/gaid-kak-zarabotat-pervye-dengi-na-pornhub

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

Почему MarTech-стек чаще ломается не на интеграции, а на постановке задачи

Я всё чаще вижу одну и ту же ошибку у маркетинговых команд: они покупают инструмент как будто это готовое решение, а не новый узел в системе. В итоге CRM, CDP, трекеры, BI и email-платформа формально подключены, но бизнес продолжает жить в Excel и ручных сверках.

Мой вывод простой: **MarTech-стек надо проектировать от управленческого вопроса, а не от списка функций**.

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

В 2026 это особенно заметно. Классическая воронка MQL/SQL слабеет, и маркетинг всё чаще отвечает не за количество заявок, а за вклад в выручку. Значит, стек должен помогать не «собирать контакты», а связывать спрос, поведение, сделки и удержание.

Из практики: в одном B2B-проекте мы убрали три «промежуточных» отчёта и один дублирующий сервис атрибуции. Формально команда потеряла слой контроля, но за два месяца сократила расхождение между маркетингом и продажами с 18% до 6%. Не потому, что появился магический инструмент. А потому, что перестали измерять одно и то же разными способами.

Я бы проверял любой MarTech-стек тремя вопросами:
— какой управленческий ответ он должен давать;
— где в нём возникает единый источник правды;
— кто владеет данными после интеграции: маркетинг, продажи или RevOps.

Если на эти вопросы нет ясного ответа, то интеграция почти наверняка превратится в дорогую имитацию прозрачности.

— @MarTechStackRu

Customer Data Platform: единый слой данных о клиенте

Customer Data Platform (CDP) — это платформа, которая собирает поведенческие и транзакционные данные из разных источников, склеивает их в единый профиль клиента и делает этот профиль доступным для активации в маркетинговых системах.

Важно не путать CDP с CRM.
— CRM хранит отношения с конкретными лидами и сделками, помогает продажам и customer success.
— CDP собирает сигналы о поведении: визиты, события, покупки, ответы на коммуникации, признаки анонимного пользователя до идентификации.

**CDP нужна не для хранения данных, а для их использования в сценариях.** В 2026 году это особенно важно: при privacy-first атрибуции и росте значимости retention маркетингу нужен не отчётный склад, а управляемый слой для сегментации, персонализации и автоматизации.

Типичные ошибки:
— внедряют CDP вместо нормальной схемы идентификации клиентов;
— пытаются загрузить в неё «всё подряд» без модели событий;
— ждут, что CDP сама почистит данные и решит проблему качества источников;
— покупают платформу раньше, чем определяют, какие сценарии будут запускаться.

Пример: e-com-команда объединяет в CDP данные сайта, приложения и email-рассылок. Если пользователь бросил корзину и потом вернулся через приложение, система видит его как один профиль и запускает персональное напоминание, а не дублирующую массовую рассылку.

— @MarTechStackRu

Соседняя редакция @InfluencerResearchRu недавно писала об этом под другим углом

Почему маркетинговый стек ломается не на выборе сервиса, а на интеграциях

Я всё чаще вижу одну и ту же ошибку у команд: они обсуждают, какой инструмент купить, и почти не обсуждают, как этот инструмент будет жить в их контуре данных. Для marketing operations это критично: **ценность стека начинается не в интерфейсе, а в связке событий, идентификаторов и правил передачи данных**.

За 2026 год я бы не ставил на «ещё один красивый сервис». Я бы ставил на архитектуру, в которой можно быстро ответить на три вопроса:
— где у нас источник истины по лидам, сделкам и выручке;
— как мы стыкуем server-side события, CRM и продуктовую аналитику;
— кто владеет логикой атрибуции, если last-click уже не отражает реальный вклад каналов.

В одном проекте мы сократили время на ручную сверку кампаний и CRM примерно на 40% не потому, что купили более дорогую платформу. Мы просто убрали дублирующие источники, зафиксировали единый словарь событий и прописали правила для UTM, офлайн-конверсий и возврата статусов из CRM. После этого команда перестала спорить о цифрах и начала управлять воронкой.

Мой вывод простой: **маркетинговый стек надо проектировать как систему принятия решений, а не как набор лицензий**. Если инструмент не улучшает скорость ответа на вопрос «что влияет на выручку?», он декоративный. Если улучшает — даже скромный по интерфейсу сервис может быть полезнее дорогой платформы.

Для B2B это особенно заметно: когда RevOps становится общей зоной ответственности, выигрывает не тот, у кого больше дашбордов, а тот, у кого меньше разрывов между каналом, продажами и клиентским успехом.

— @MarTechStackRu