Google стал помечать креативы, созданные ИИ

Google объявил, что начнёт помечать рекламные креативы, созданные нейросетями. Причина — ИИ-баннеры и видео стали слишком похожи на настоящие.

Формат и заметность маркировки будут зависеть от законов конкретного региона: где-то предупреждение появится прямо на креативе, где-то — в его информации.

Что это значит для арбитражников и когда правила …

➡️ Читайте на сайте: https://aff.top/blog/google-stal-pomechat-kreativy-sozdannye-ii

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

Компания Meta выпустила Muse Spark 1.1

Meta выпустила Muse Spark 1.1 почти одновременно с новой ChatGPT-5.6. Это мультимодальный агент, который сам дробит задачу на подзадачи и распределяет их между субагентами.

Стоимость тоже заметно ниже топовых западных моделей: $1.25 за миллион входных токенов и $4.25 за миллион выходных.

Но главный вопрос — насколько она реально сильна на фоне к…

➡️ Читайте на сайте: https://aff.top/blog/kompaniia-meta-vypustila-muse-spark-1-1

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

Customer data ломается не в CDP, а на стыке событий, CRM и ручных костылей

Если у вас есть только page_view и покупка, это не customer data, а следы движения. Для нормальной работы нужны три слоя: поведение, идентичность и атрибуты профиля. Иначе сегменты будут «прыгать», а триггеры — слать одно и то же в пустоту.

Базовый минимум для D2C:
— стабильный user_id и отдельный anonymous_id до логина;
— события с понятными именами и одинаковыми свойствами;
— единый источник правды для email, phone, consent и статуса клиента.

Главная ошибка — смешивать «что сделал пользователь» и «что мы про него знаем» в одном событии. Так ломается дедупликация, attribution и reverse-ETL. Второй провал — менять схему без версионирования: сегодня поле `plan`, завтра `subscription_type`, и половина отчетов тихо пустеет. Третий — тащить в CDP мусор из CRM без нормализации: пробелы, разные телефоны, дубли, пустые значения.

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

Чем раньше вы опишете схему данных и правила матчингa, тем меньше будет «магии» в маркетинге и пожаров в аналитике.

Sanctions screening ломается не на санкциях, а на грязных данных и слабых правилах

Если screening срабатывает «на всё подряд», команда быстро уходит в ручные разборы, а реальные риски теряются в шуме. Если же пороги слишком мягкие, в kyc-процессе остаются обходные сценарии и токсичные связи.

Что обычно проверяют перед запуском:
• транслитерации и альтернативные написания имени;
• совпадения по стране, городу, дате рождения и документам;
• связи по бенефициарам, адресам и устройствам;
• совпадения с high-risk jurisdictions, но без слепого бан-логики.

Отдельно важны false positives: их нужно не только считать, но и объяснять. Если analyst не понимает, почему алерт возник, он не сможет быстро отличить мусорный матч от реального риска. Для anti_fraud это особенно критично: screening без контекста часто конфликтует с chargebacks-сигналами и даёт ложную уверенность.

Хорошая схема — разделять причины алерта, уровень уверенности и действие: пропуск, усиленная проверка, ручной review, отказ. Тогда AML и sanctions_screening работают как фильтр, а не как хаотичный стоп-кран.

Identity resolution ломают не ID-шники, а грязные правила склейки событий и людей

В CDP identity resolution — это не «угадать, кто есть кто», а аккуратно собрать один профиль из кусков: anonymous_id, user_id, email, phone, device_id. Если правило слишком агрессивное, вы склеите разных людей в один профиль и испортите сегменты, триггеры и атрибуцию.

Базовый набор правил обычно такой:
— сначала deterministic match: login, email, phone;
— потом приоритет источника: CRM > app > web > ad click;
— отдельно хранить identity graph, а не переписывать сырой event stream;
— не склеивать по имени, городу или IP как по основному ключу.

Самая дорогая ошибка — backfill без контроля. Когда вы догружаете историю, старые anonymous события внезапно «переезжают» к новому user_id, и ретеншн, LTV и цепочки welcome-сценариев начинают врать. Поэтому для каждого правила нужен флаг confidence и журнал: почему профиль был объединён, когда, по какому ключу.

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

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

Российские букмекеры увеличили закуп трафика с мобильных приложений

Российские букмекеры в 1 квартале 2026 года заметно нарастили закупку трафика из мобильных приложений. На фоне ужесточения регулирования они смещают бюджеты в новые каналы, где ещё есть живой трафик.

По данным UMG, доля in-app-рекламы выросла с 3-4% до 5-6% при объёме рынка около 10 млрд рублей. Но это может быть только начало — в блоге разбираем…

➡️ Читайте на сайте: https://aff.top/blog/rossiiskie-bukmekery-uvelichili-zakup-trafika-s-mobilnykh-prilozhenii

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

Mia Khalifa стала амбпссадором 1win

Mia Khalifa снова засветилась рядом с 1win: в Instagram она показала цепочку с логотипом бренда и статус «VIP 1win».

Параллельно всплыла история с ее ставкой на Испанию на ЧМ — по данным поста, выигрыш мог составить 200к$.

Официального подтверждения амбассадорства пока нет, но для арбитражников это уже повод для новых креативов. Что именно здесь…

➡️ Читайте на сайте: https://aff.top/blog/mia-khalifa-stala-ambpssadorom-1win

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

Короткий домен Telegram перестал работать

Telegram лишился домена t.me: он разделегирован и больше не работает на уровне регистратора. Платформа срочно переезжает на telegram.me, а владельцам крупных каналов стоит обновить публичные ссылки. Сроки восстановления неизвестны, и есть риск, что t.me не вернётся вовсе на фоне давления на Telegram.

➡️ Читайте на сайте: https://aff.top/blog/korotkii-domen-telegram-perestal-rabotat

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

MT-Bench: релиз года для тех, кто хочет сравнивать llm без магии и ручного шаманства

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

Если используешь его как model_comparison, держи три правила:
— сравнивай только на одинаковых промптах и одинаковом формате ответа;
— не смешивай MT-Bench с задачами на код или знания: это про диалог, а не про всё на свете;
— смотри не только на средний балл, но и на провалы по отдельным категориям: иногда модель красивая в общем зачёте и очень нервная в длинных ответах.

Ещё один вечный баг: люди читают результат как «победитель лучший везде». Нет. MT-Bench хорошо ловит качество ассистента, но плохо заменяет benchmarks для reasoning, code, factuality и safety. Нормальная практика — собирать стек из нескольких evals, а не молиться на один таблоидный рейтинг.

Используй MT-Bench как фильтр, а не как приговор: если модель там сильна, это хороший знак для chat-UX, но финальный вердикт всё равно дают остальные evals. Может, конечно, ни хуя не взлетит именно в твоём кейсе — и это не баг, а обычная жизнь llm.

Youtube тестирует поиск с AI

YouTube начал тестировать Ask YouTube — поиск с ИИ, где можно задавать вопросы обычным языком и получать не список ссылок, а готовую подборку видео и фрагментов.

Фича уже доступна в США и работает на сложные запросы: если нужно, ИИ уточняет вопрос и подсказывает следующий шаг.

Что это значит для поиска на YouTube и когда новинка дойдёт до других…

➡️ Читайте на сайте: https://aff.top/blog/youtube-testiruet-poisk-s-ai

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

Customer data ломается не в сборе, а на стыке ID, событий и прав доступа

Если у вас в CRM, CDP и рекламных кабинетах разные customer_id, дальше начинается зоопарк: дубли, кривой attribution и сегменты, которые нельзя активировать без ручной чистки. Базовое правило: один человек — один master ID, а все внешние ключи должны быть лишь связями.

Схема без боли обычно держится на 3 слоях:
— raw events: как пришло, без «улучшений»;
— normalized profile: почистили email, phone, country, consent;
— activation-ready: только те поля, которые можно безопасно лить в email, push, ads.

Ошибки, которые потом дорого чинить:
— хранить PII в каждом событии, а не в профиле;
— менять названия полей без версионирования;
— смешивать product events и marketing events в одном потоке;
— не фиксировать источник и timestamp на уровне события.

Для customer data важнее не «собрать всё», а заранее решить, что вы сможете удалить, склеить и переотправить. Если этого нет, reverse-ETL превращается в доставку мусора в ещё один инструмент.

Начните с карты идентификаторов и списка обязательных полей для активации. Всё остальное можно нарастить позже.

Z.ai анонсировала новую GLM-5.5

Z.ai готовит релиз флагманской GLM-5.5: модель обещают показать в августе 2026 года.

Главная интрига — рост до 1 трлн параметров при том же контекстном окне в 1 млн токенов. Новинка снова будет заточена под код и агентные задачи.

Почему версия сразу 5.5, без 5.3 и 5.4, и что это может означать для рынка — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/z-ai-anonsirovala-novuiu-glm-5-5

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

Telegram запустил собственный сервер для ботов

Telegram запустил собственный сервер для ботов и мани-приложений: теперь backend можно размещать прямо внутри инфраструктуры мессенджера.

Сервер работает на JavaScript/TypeScript, через вебхуки, и позволяет подключать SQL-базу для сбора контактов без посредников.

Пока неясны цена и ограничения — что именно уже можно тестировать, а где скрыт подв…

➡️ Читайте на сайте: https://aff.top/blog/telegram-zapustil-sobstvennyi-server-dlia-botov

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

Identity resolution ломают не event'ы, а слабые правила склейки профиля

Если у вас один и тот же человек живёт как guest, email-user и app-user — CDP не “угадает” его магически. Склейка держится на источниках идентификатора и приоритетах: login_id, email_hash, phone_hash, device_id, cookie_id. Без этого один заказ уходит в один профиль, возврат — в другой, а LTV и сегменты начинают врать.

Что обычно должно быть в правилах:
— какой ID считается первичным;
— какие связи разрешены: deterministic только, или ещё probabilistic;
— как долго живёт anonymous-профиль;
— что делать при конфликте: merge, overwrite, keep both.

Самая дорогая ошибка — склеивать по любому совпадению. Один общий email на семью, один девайс у менеджера, пересечение по телефону в CRM — и вы получаете “суперпрофиль” из чужих покупок, писем и отказов. После этого ретаргет бьёт мимо, а триггеры в lifecycle-цепочках начинают сыпать не тем людям.

Проверка простая: берёте 20 реальных кейсов и вручную смотрите цепочку идентификаторов от первого визита до оплаты. Если в логике есть дыры, сначала чините схему событий и правила merge, а уже потом настраивайте activation в CRM и ads. Иначе любая CDP будет просто красивым слоем поверх мусора.

Google картинки станут конкурентом Pinterest

Google Картинки начали превращать в полноценную платформу с персональной лентой по прошлым запросам — по сути, в аналог Pinterest.

Во вкладке For you уже тестируют подборки, а ещё обещают коллекции и генерацию изображений во встроенной Nano Banana.

Как это будет работать и когда новинка дойдёт до других стран — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/google-kartinki-stanut-konkurentom-pinterest

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

Customer Data ломается не в CDP, а в моменте, когда у событий нет хозяина и схемы

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

Рабочий минимум для D2C:
— один владелец за каждую сущность: user, order, product, subscription;
— стабильный event name и обязательные поля;
— отдельные правила для anonymous_id и user_id;
— версионирование схемы, даже если это простой changelog;
— проверка null/empty/duplicate до отправки в warehouse и маркетинг-инструменты.

Самая дорогая ошибка — смешать raw-ивенты и бизнес-атрибуты в одном поле. Тогда «заказ» превращается в мусорный контейнер, а reverse-ETL начинает лить в CRM то, что нельзя использовать для сегментации или триггеров.

Если нет data dictionary и списка обязательных полей, сначала делайте их, потом интеграции. Иначе любая автоматизация будет ускорять не рост, а беспорядок.

Россияне не смогут покупать стейблкоины

Россиянам могут закрыть доступ к покупке стейблкоинов: в новой версии закона их приравняли к иностранным активам.

Купить такие токены смогут только квалифицированные инвесторы — например, с активами от 24 млн рублей или доходом от 12 млн в год.

Что это значит для обычных пользователей и когда правило заработает — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/rossiiane-ne-smogut-pokupat-steiblkoiny

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

Reverse-ETL ломается не в коннекторе, а в схеме: 4 места, где теряются деньги

Reverse-ETL — это не «залить аудитории в CRM». Это доставка уже собранных данных из DWH в рабочие системы: CRM, ads, helpdesk, email, product. Если в базе грязь, дубли и неясный ключ пользователя, активировать нечего: сегменты плывут, статусы не совпадают, а команды начинают спорить не о росте, а о том, «у кого правда».

Проверьте 4 вещи до запуска:
— единый ключ идентичности: user_id, email, phone — но один главный, остальные как fallback;
— правила дедупликации: что делать с несколькими событиями, несколькими лидами и merged-профилями;
— freshness SLA: какие поля можно отправлять раз в час, а какие должны обновляться почти сразу;
— идемпотентность: повторная отправка не должна создавать новый лид, сделку или подписку.

Самая частая ошибка — слать в downstream сырые события вместо готовых атрибутов. CRM не любит event-stream, ей нужен понятный профиль: стадия, флаг, сумма, сегмент, причина отказа. Для ads-активации наоборот важны стабильные аудитории и предсказуемый refresh, иначе вы каждый раз обучаете алгоритм на новой каше.

Еще один грабль — маппинг полей без владельца. Пока никто не отвечает за соответствие «source → target», через пару месяцев в одной системе будет last_purchase, в другой last_order_date, а в третьей пусто. Назначайте владельца на каждый критичный атрибут и логируйте ошибки доставки, а не только успехи.

Начинайте reverse-ETL не с «куда лить», а с одного сценария, где есть понятный выигрыш: триггер в CRM, suppression list, возврат неактивных, handoff в саппорт. Когда один маршрут стабилен, масштабировать проще, чем чинить пять полуразобранных.

Customer data ломается не в BI, а на входе: 5 правил, которые спасают схему

Если customer data собрать как попало, дальше уже не поможет ни CDP, ни reverse-ETL. Боль обычно одна и та же: событие назвали по-разному в web и app, часть свойств приходит пустой, а user_id живёт отдельно от email и phone. В итоге сегменты кривые, атрибуция шумит, а активация льёт не туда.

• Делайте одну базовую схему событий: просмотр, add_to_cart, checkout, purchase. Не плодите синонимы.
• Для каждого события фиксируйте обязательные поля: user_id, anonymous_id, timestamp, source, device, currency.
• Отдельно храните identity-ключи и не смешивайте их в одном поле.
• Валидируйте типы: цена — число, дата — дата, статус — enum, а не строка “ok”.
• Все кастомные свойства — через список разрешённых полей, иначе зоопарк вернётся через месяц.

Для customer data важнее не объём, а предсказуемость. Если аналитик не может по схеме понять, что придёт в payload, маркетинг не сможет нормально сегментировать аудиторию, а CDP начнёт разносить мусор по CRM и рекламным кабинетам. Это особенно заметно, когда один и тот же человек приходит с web, app и офлайна.

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