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

Claude Cowork, Claude Design объединили в один Claude

➡️ Читайте на сайте: https://aff.top/blog/claude-cowork-claude-design-obedinili-v-odin-claude

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

ITP в Safari режет не весь трекинг, а только предсказуемые костыли

Если у вас живут только client-side cookies, Safari быстро срежет окно хранения и начнёт обнулять часть связки между визитом и конверсией. В итоге ломается не «атрибуция вообще», а конкретно long-tail: возврат через несколько дней, повторный визит, post-click цепочки.

Что обычно остаётся работать лучше:
— first-party cookies на своём домене, если они нужны строго для сессии и short-lived логики
— server-side сбор событий через sGTM, когда браузер меньше участвует в передаче
— `event_id` для дедупликации Pixel + CAPI
— нормализованные `fbp` / `fbc`, если они реально были собраны до обрезки окна

Что чаще всего падает:
— reliance на third-party cookies
— длинные цепочки редиректов и лишние домены
— поздняя отправка конверсии без server-side резервного канала
— хранение user data только в браузере без server-side backup

Анти-кейс типичный: пиксель стоит, CAPI тоже стоит, а `event_id` у событий не совпадает или генерится заново на сервере. В Safari это выглядит как потерянные конверсии, хотя проблема не в ITP, а в отсутствии стабильной дедупликации.

Вывод простой: в Safari выигрывает не тот, кто «обошёл» ограничение, а тот, кто сократил зависимость от браузера и оставил минимальный, прозрачный first-party стек.

Microsoft планирует вставлять рекламу в игры

➡️ Читайте на сайте: https://aff.top/blog/microsoft-planiruet-vstavliat-reklamu-v-igry

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

Session stitching ломается не из-за пикселя, а из-за разъезда идентификаторов между клиентом и сервером

Когда browser-событие и server-событие живут в разных сессиях, вы получаете дубли, провалы в атрибуции и странные расхождения между GA4, CAPI и BI. Обычно проблема не в «потере данных», а в том, что не совпали ключи: event_id, session_id, client_id, fbp/fbc.

Что должно совпадать:
— event_id: один и тот же для Pixel и CAPI, иначе дедупликация не сработает
— session_id: прокиньте его из client-side в sGTM и дальше в backend
— client_id / user_pseudo_id: нужен как стабильный мост для аналитики
— timestamp: сервер не должен «уезжать» сильно дальше окна сессии

Практика простая: client-side генерирует event_id и session_id, кладёт их в first-party cookie или dataLayer, а сервер забирает и ретранслирует без пересборки. Если на сервере вы создаёте новые идентификаторы, stitching превращается в угадайку. Для GA4 отдельно проверьте, что session_start не плодится повторно при server hit.

Финальный чек: одно событие — один event_id, одна сессия — один session_id, и одинаковая логика на всех точках отправки. Если это соблюдено, дедупликация и отчёты перестают спорить между собой.

TikTok Events API ломается не на подписи, а на типовых полях и их валидации

У TikTok Events API чаще всего падает не транспорт, а качество payload: event_name есть, а match data пустая или собрана в другом формате. В итоге запрос проходит, но атрибуция и дедупликация работают хуже, чем могли бы.

Базовый набор, который стоит проверить первым:
— event_name: строго из ожидаемого списка, без локальных переименований
— event_time: Unix time в секундах, не в миллисекундах
— event_id: один и тот же для Pixel и server event
— user: email, phone, external_id, ip, user_agent, ttclid
— properties: value, currency, contents, content_type, order_id

Самые частые ошибки валидации:
— email и phone уходят без нормализации до SHA-256: нужны lowercase, trim, E.164 для телефона
— event_time отправляют с часовым поясом или в ms
— contents передают строкой вместо массива объектов
— currency приходит в нижнем регистре или без ISO-кода
— event_id генерируется заново на клиенте и сервере, поэтому dedup не сходится

Если строите server-side маршрут, валидируйте payload до отправки: пустой user object лучше отбрасывать, чем слать «почти валидные» события. Иначе API примет запрос, а match_keys останутся бесполезными для оптимизации.

Правило простое: сначала привести типы и формат полей к одной схеме, потом уже смотреть на EMQ, дедуп и ROAS.