ByteDance анонсировала новую версию SeeDance версии 2.5

ByteDance готовит релиз Seedance 2.5 — видеогенератора нового уровня. Главное улучшение: модель сможет создавать 30-секундные видео за один прогон без склеек, вместо нынешних 15 секунд. Добавили локальный монтаж отдельных кадров, поддержку 3D-болванок для управления камерой, возможность использовать до 50 референсов и генерацию в 4К сразу. Закрытый бета-тест идёт сейчас, открытый релиз ожидается в начале июля. Технологически это шаг вперёд, но д…

➡️ Читайте на сайте: https://aff.top/blog/bytedance-anonsirovala-novuiu-versiiu-seedance-versii-2-5

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

Codex уничтожит твой SSD за год

Разработчик обнаружил критический баг в Codex CLI от OpenAI: агент непрерывно записывает логи в локальную SQLite-базу, перезаписывая за 21 день 37 ТБ данных. При таком темпе типичный SSD объёмом 1 ТБ (рассчитанный на 600 ТБ перезаписей) выходит из строя менее чем за год. OpenAI осведомлена о проблеме, но пока не исправляет её. Пользователям остаётся либо ждать обновления, либо переключиться на альтернативные CLI-инструменты без подобных недостат…

➡️ Читайте на сайте: https://aff.top/blog/codex-unichtozhit-tvoi-ssd-za-god

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

WebView vs PWA vs нативка: как не слить гемблу на неверной упаковке

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

PWA берут, когда нужен почти-app опыт без полноценной публикации. Плюс в том, что user получает иконку, быстрый возврат и меньше трения. Минус — ограниченная интеграция с железом и более слабый контроль над поведением клиента. Для гемблы это норм, если задача — прогрев и ретеншн, а не глубокая аппаратная логика.

Нативка нужна, когда важны стабильность, пуши, платежные сценарии, сложная аналитика и долгий life cycle. Но цена входа выше: дороже разработка, дольше итерации, больше точек для модерации и поддержки. На практике нативка оправдана не для каждого теста, а для тех воронок, где уже есть подтвержденный LTV и понятный повторный трафик.

Выбор простой: WebView — для скорости, PWA — для легкого app-ощущения, нативка — для масштаба и удержания. Если сомневаешься, стартуй с WebView, а потом переносишь только те механики, которые уже доказали деньги.

SIM-фарм под мобильные прокси: что закупать и как не получить блок

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

Выбирайте предоплаченные SIM с пакетным интернетом. Лучше работают тарифы суб-брендов крупных операторов или региональных МВНО — они дешевле на поддержание и реже попадают под общие фильтры рекламных кабинетов. На один паспорт вешать десятки карт рискованно: операторы и платформы отслеживают массовую привязку. Распределяйте регистрацию по разным данным.

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

Перед запуском закладывайте 20–30% SIM на замену. Карты умирают от верификаций операторов и триггеров антифрода платформ, это нормальный расход фарма, а не повод сворачивать линейку.

CDP ломается не на выборе вендора, а на грязных событиях и кривом identity graph

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

Перед запуском проверьте три вещи:
• единый нейминг событий и свойств, без дублей типа order_paid / purchase_success
• стабильный идентификатор: user_id, а не только cookie или device_id
• правила для anonymous-to-known: когда и как склеивать гостя с профилем

Частая ошибка — пытаться «активировать всё». В итоге в CDP летят сырые клики, техсобытия и бизнес-события в одной каше. Разведите слои: raw events для хранилища, curated events для CDP, а в activation отдавайте только те поля, которые реально нужны маркетингу и саппорту.

Ещё один грабль — отсутствие data contract. Если продукт поменял название свойства, а downstream-команды узнали об этом через сломанный сегмент, значит схемы нет. Нужны владельцы событий, список обязательных полей и проверка на пустые/аномальные значения.

CDP окупается не за счёт количества коннекторов, а когда у вас есть дисциплина в схеме, identity и quality checks.

CDP не спасает, если у вас ломается схема событий и identity

CDP чаще всего продают как «единый источник правды», но на практике она просто ускоряет то, что вы ей скормите. Если event names скачут, user_id теряется между вебом и app, а traits приходят в разном формате — в activation улетает мусор, только быстрее и дороже.

Проверяйте три слоя до покупки и до интеграции:
— ingestion: все ли источники реально доезжают, есть ли retry и дедупликация
— identity resolution: как склеиваются anonymous_id, email, phone, customer_id
— activation: куда и в каком виде уходят поля, кто отвечает за маппинг

Главная ошибка — начинать с «куда будем лить». Правильнее сначала зафиксировать минимальную event-схему: sign_up, login, purchase, add_to_cart, refund. У каждого события должны быть обязательные поля, типы значений и владельцы. Иначе через три месяца окажется, что одинаковое имя события используется для разных смыслов.

CDP нужна, когда у вас уже есть дисциплина в данных и понятные consumer-сценарии: сегментация, триггеры, reverse-ETL, suppression. Если команда не может договориться о naming convention и не умеет чистить дубль-профили, то платформа станет дорогим ретранслятором хаоса.

Сначала схема и правила качества, потом CDP. Иначе вы автоматизируете бардак, а не customer data.

Google ужесточает модерацию финансовой вертикали

Google ужесточает модерацию финансовых офферов в ЕС и ЕЭЗ, введя двухэтапную верификацию через G2 Risk Solutions и Google Ads. Проверка затронет 24 страны, включая Австрию, Польшу, Нидерланды и другие члены союза. На прохождение модерации отводится 30 дней — за это время некоторые связки успеют отработать до вступления требований в силу. Для арбитражников это означает необходимость подготовиться к усложнению процесса запуска финансовых кампаний …

➡️ Читайте на сайте: https://aff.top/blog/google-uzhestochaet-moderaciiu-finansovoi-vertikali

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

Data activation ломается не в CRM, а на стыке схемы, identity и правил выгрузки

Если у тебя события в трекинге есть, а в письма/пуши/ads уезжает мусор — проблема обычно не в канале, а в подготовке данных. Для activation нужны 3 слоя: • стабильные ключи пользователя • нормализованные события • явные правила, когда и куда отправлять.

Первый грабельный пункт — identity. Один и тот же человек может прийти с email, phone, cookie и external_id. Если не описать приоритеты склейки, CDP начнёт плодить дубли или перетягивать историю на неверный профиль. Второй — event schema: названия событий, обязательные поля, типы значений и допустимые пустоты должны быть зафиксированы заранее.

Третий — routing. Не надо отправлять все события во все инструменты. Для activation лучше держать отдельные сегменты: кто готов к офферу, кто в онбординге, кто в оттоке, кто уже получил коммуникацию. Иначе маркетинг быстро превращает автоматизацию в спам-машину.

Если строишь activation с нуля, сначала сделай один сценарий end-to-end: собрал событие → связал identity → проверил сегмент → отправил в один канал → замерил отклик. Когда этот цикл стабилен, масштабировать остальное уже не больно.

Fable 5 скоро вернётся в публичный доступ

В исходном коде Claude Code обнаружены упоминания о возвращении модели Fable 5 в публичный доступ с изменённой моделью распространения — её больше не потребуется покупать отдельно, вместо этого будет применяться недельный лимит как для других моделей. Если информация подтвердится, пользователи платных тарифов смогут использовать Fable 5 в рамках своих подписок. Причины снятия ограничений по национальной безопасности остаются неясными. Хотя это п…

➡️ Читайте на сайте: https://aff.top/blog/fable-5-skoro-vernetsia-v-publichnyi-dostup

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

CDP ломают не фичи, а грязная схема событий и дубли в identity

CDP покупают ради трёх вещей: собрать события из сайта, приложения и CRM; склеить одного человека из разных идентификаторов; раздать аудитории в email, push, ads и support. Если в одном месте user_id, в другом phone_hash, а в третьем вообще пусто — activation превращается в лотерею.

Перед внедрением проверьте базу:
— есть ли единый словарь событий и обязательных свойств
— как строится identity graph: email, phone, device_id, customer_id
— кто источник правды для профиля: CRM, billing или продуктовая БД
— как удаляются дубли и обрабатываются merge/unmerge
— что происходит с anonymous-пользователем до логина

Частая ошибка — начинать с дашбордов и сегментов, а не со схемы. В итоге маркетинг видит “новых”, продукт — “старых”, а CRM шлёт одно и то же письмо дважды. CDP тут не спасает: она лишь быстрее разнесёт мусор по всем каналам.

Если нужен рабочий старт, фиксируйте 10–15 ключевых событий, один identity-ключ как primary и правила на merge. Всё остальное можно достраивать потом; передавать в activation надо только те поля, в которых вы уверены.

Reverse-ETL ломается не в коннекторе, а в схеме: 5 правил, которые спасают активацию

Reverse-ETL нужен не для “лить данные в CRM”, а для синхронизации нормальных customer-объектов в каналы, где живёт маркетинг: email, ads, support, sales. Если в warehouse хаос, то в downstream он превращается в дубли, пустые поля и странные сегменты.

Первое правило — один ID на сущность, не три. Если у пользователя есть email, phone и internal_id, выберите главный ключ и зафиксируйте, как он маппится на каждый destination. Иначе при каждом изменении контакта вы получаете новый “человек” в CRM. Второе — отдельно храните события и атрибуты: события нужны для триггеров, атрибуты — для сегментов и персонализации.

Третье — не отправляйте сырые поля, которые маркетинг не умеет интерпретировать. Лучше подготовить в warehouse уже готовые флаги: `is_repeat_buyer`, `lifetime_value_bucket`, `last_purchase_channel`. Четвёртое — задайте правила дедупликации и приоритет источников: если CRM и сайт спорят, кто прав, победитель должен быть определён заранее.

Пятое — проверяйте обратную синхронизацию как продовый API: schema drift, пустые значения, задержка, rate limits и откаты. Самая дорогая ошибка в reverse-ETL — тихая: сегмент уехал, кампании пошли, а вы узнали об этом по падению CR.

Начинайте не с “какой инструмент выбрать”, а с контракта данных: что именно, в какой ключ, с какой частотой и по какому правилу обновляется. #reverseETL #cdp #tracking

CDP ломается не на интеграции, а на грязной схеме событий и identity

CDP почти всегда продают как «единый профиль клиента», но на практике там три узких места: ingestion, склейка identity и активация. Если в событии нет стабильного user_id, а device_id живёт отдельно, профиль распадается при первом же входе с другого устройства. Если названия событий гуляют, downstream-автоматизация начинает стрелять мимо сегментов.

Перед внедрением проверьте три вещи:
• кто владелец каждой сущности: user, account, anonymous, order
• какие идентификаторы обязательны в web, app, backend
• какие события можно слать только после валидации схемы

Вторая частая ошибка — тащить в CDP всё подряд. Лишние свойства, дубликаты и «пока пригодится» поля быстро убивают качество сегментов. Лучше 20 стабильных атрибутов, чем 200 мусорных. Иначе reverse-ETL начнёт залипать на пустых значениях, а CRM-команды будут чистить рассылки руками.

Третья зона боли — активация. Если сегмент строится на сырых событиях, а не на нормализованных сущностях, маркетинг получает разные списки в email, push и ads. Делайте один слой truth для ключевых полей: email, phone, consent, LTV, last_order_at. Всё остальное — вторично.

CDP полезна только там, где есть дисциплина по схеме и владельцам данных. Нет схемы — будет дорогой транспорт для хаоса.

Chat GPT-5.6 будут выдавать лишь избранным

США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.

➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym

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

Vk удалили из App store: что дальше?

Удаление VK из App Store заблокировало доступ для владельцев iPhone в России, но проблема решаема. Арбитражники теряют один канал, но не аудиторию — 20–30 млн пользователей iOS остались на месте. Вместо VK стоит переориентироваться на альтернативные источники: Telegram Ads с таргетингом на iOS, push-сети типа AdProfex, MTS Ads и Beeline Ads. VK может последовать примеру Max и запустить PWA-приложение для восстановления уведомлений. Главный вывод…

➡️ Читайте на сайте: https://aff.top/blog/vk-udalili-iz-app-store-chto-dalshe

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

Identity resolution ломается не в матчинге, а в грязной схеме событий и дублях ключей

Если у человека есть email, phone, device_id и customer_id, это ещё не identity. Это просто набор полей. Склеивание работает только когда вы заранее решили, какой ключ живёт дольше, где он рождается и кто имеет право его менять.

Правила, которые спасают стек:
— один primary key на профиль, остальные — secondary identifiers;
— событие может приходить без user_id, но не без стабильного anonymous_id;
— merge делаем только по детерминированным связкам, а не по “похожим” данным;
— после login/checkout нужен явный link между anonymous и known user, иначе история расползётся.

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

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

Сначала зафиксируйте правила идентичности, потом подключайте активацию. Иначе вы просто ускорите распространение мусора по всем системам.

Customer data ломается не в CDP, а в схеме: 6 правил, которые спасают активацию

Если customer data собирается как попало, любая CDP превращается в дорогой пересылщик мусора. Боль не в том, что у вас “мало данных”, а в том, что события называются по-разному, идентификаторы не склеиваются, а атрибуты живут без правил владения.

— Сначала фиксируйте единый набор ключей: user_id, anonymous_id, email, phone. Не придумывайте по 3 поля на один смысл.
— Разделяйте event properties и user traits: событие описывает действие, trait — пользователя.
— Для каждого события задайте обязательные поля и типы: если поле пустое или плавает по формату, downstream-активация будет ломаться.
— Введите версионирование схемы: удаление или переименование поля без миграции = тихая поломка сегментов и reverse-ETL.

Identity resolution почти всегда страдает в двух местах: guest-to-known merge и мультидевайс. Если не определить, когда anonymous_id должен сливаться с user_id, вы получите дубли в CRM, неверные аудитории и кривую атрибуцию. Лучше один раз описать правило merge, чем потом чистить ручные склейки.

Последний слой — ownership. У каждого поля должен быть владелец: кто добавляет, кто удаляет, кто отвечает за quality check. Без этого схема через месяц начинает жить своей жизнью, а маркетинг и аналитика спорят не о росте, а о том, какое поле “на самом деле правильное”.

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