Anthropic готовит к запуску Claude Money

Anthropic анонсировала Claude Money — ИИ-сервис для управления личными финансами и автоматизации платежей. Инструмент позволяет подключать банковские карты для анализа расходов, планирования бюджета и проведения транзакций. Это переход от консультационных моделей к полноценным финансовым агентам. Внедрение технологии позволит пользователям делегировать нейросети рутинные задачи, включая оплату токенов и подписок на необходимые рабочие сервисы.

➡️ Читайте на сайте: https://aff.top/blog/anthropic-gotovit-k-zapusku-claude-money

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

Meta ограничивает расходы на токены для сотрудников

Meta ввела внутренние лимиты на использование ИИ из-за резкого роста расходов: в 2026 году только на сотрудников заложены миллиарды долларов, а общий бюджет на ИИ-инфраструктуру оценивается в 130–145 млрд. Вывод простой: даже у Big Tech ИИ перестал быть бесплатной игрушкой и требует жёсткого контроля затрат.

➡️ Читайте на сайте: https://aff.top/blog/meta-ogranichivaet-raskhody-na-tokeny-dlia-sotrudnikov

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

Server-side не спасает плохую разметку

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

Если на сайте хаос в событиях, дубли, разные названия одних и тех же действий, пустые параметры и сломанная ecommerce-структура, серверный слой это не исправит. Он лишь аккуратно перенесёт этот хаос из браузера в сервер. В лучшем случае вы получите более стабильную отправку. В худшем — более стабильную путаницу.

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

И вот здесь начинается зрелость. Потому что в 2026 году, когда last-click ещё жив, но уже явно теряет вес, выигрывает не тот, кто «собрал больше пикселей», а тот, кто выстроил first-party-архитектуру (данные первой стороны) и умеет доказывать вклад каналов через server-side, MMM (маркетинговое моделирование) и incrementality (инкрементальность).

Из практики: почти в каждом втором проекте после первого аудита мы находим 15–30% лишних или дублирующих событий. И это не техническая мелочь — это прямой удар по атрибуции, ретаргетингу и обучению рекламных систем.

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

— @ServerSideTrackingRuPro

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

На Anthropic, OpenAI, Google и SpaceXAI подали в суд из-за ИИ

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

➡️ Читайте на сайте: https://aff.top/blog/na-anthropic-openai-google-i-spacexai-podali-v-sud-iz-za-ii

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

Google ads начал показывать расходы конкурентов

Google Ads запустил Peer Spending — инструмент, который сравнивает расходы аккаунта с рекламодателями из той же ниши без раскрытия чужих данных. Он показывает, тратите вы больше, меньше или примерно на уровне конкурентов на уровне кампаний и групп объявлений. Для арбитража это скорее ориентир по бенчмаркам, чем инструмент прямого усиления залива.

➡️ Читайте на сайте: https://aff.top/blog/google-ads-nachal-pokazyvat-raskhody-konkurentov

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

Минфин РФ планирует выпустить собственный стейблкоин

Власти РФ обсуждают запуск рублёвого стейблкоина: сейчас решают, как его обеспечить, какие операции разрешить и будет ли на него спрос. Основной кейс — международные переводы, а не использование физлицами. Если проект доведут до запуска, он может стать частью новой криптоинфраструктуры и альтернативой токенам, привязанным к дружественным валютам.

➡️ Читайте на сайте: https://aff.top/blog/minfin-rf-planiruet-vypustit-sobstvennyi-steiblkoin

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