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