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

Startup Partner Program от HubSpot: как lifecycle-логика превращает “партнёров” в стабильный канал лидов

HubSpot — пример того, как B2B-компании в 2026 всё чаще строят рост не только через новые запросы (информационный SEO и “всем понятные” страницы), а через собственные экосистемы: партнёрства, обучение, совместные сценарии коммуникаций и контроль качества в воронке.

Задача
При запуске Startup Partner Program HubSpot нужно было решить типичную проблему партнёрских программ:
— партнёры заявляются, но не всегда доводят стартап до активации;
— материалы есть, а жизненный цикл “после регистрации” теряется;
— продажи и маркетинг получают разрозненные сигналы: где реально созрел потенциальный клиент, а где просто “контакт ради отчёта”.

Решение
Логика программы была выстроена как lifecycle-цепочка, а не как разовый набор PDF/страниц:
— селекция партнёров и понятные условия входа в программу (чтобы снизить “шум” на старте);
— структурированные шаги для стартапов: от ознакомления с продуктом к первичным сценариям использования;
— обучающие материалы и поддержка, которые помогают командам партнёров вести клиента к ключевым действиям (то есть к моменту, когда ценность становится очевидной);
— мониторинг прогресса через события в воронке (не только “кликнул/оставил форму”, а “дошёл ли до активации”).

Важно: в таких программах маркетинг перестаёт отвечать только за верх воронки. Реально начинает работать RevOps-модель — потому что успех зависит от согласованности действий маркетинга, продаж и customer success: где именно “партнёр” передаёт клиента, и какие признаки говорят, что он готов.

Конкретный результат
В открытых материалах HubSpot по Startup Partner Program основное внимание — на механике и охвате программы, но без публикации подробных чисел по приросту выручки/конверсий (в кейсах HubSpot чаще дают качественные результаты и описание процесса, а не таблицы метрик). Поэтому здесь корректнее говорить не “сколько процентов выросло”, а о том, какую проблему программа системно закрывала: повышение качества партнёрских прививок в жизненном цикле и доведение стартапа до активации за счёт стандартизированных шагов и сопровождения.

Урок для читателя (как применить в CRM/email/lifecycle)
1) Партнёрская программа — это тоже lifecycle. Рассматривайте её как “путь пользователя”, где партнёр играет роль канала на конкретном этапе.
2) Метрики должны быть событийными. Вместо “лид получен” измеряйте прогресс к активации: выполнено ли ключевое действие, дошёл ли клиент до времени-to-value, не завис ли на этапе обучения.
3) Шаблонизируйте передачу ответственности. В RevOps-смысле важно заранее определить: что делает маркетинг, что — продажи, что — customer success, и какие события служат триггерами передачи.
4) Делайте контент не про объём, а про контекст. В zero-click эпоху решает не “ещё один урок”, а точные подсказки под стадию: что нужно именно сейчас стартапу, чтобы увидеть ценность.

Если хотите, в следующем посте разберу, какие события и сегменты обычно ложатся в такую партнёрскую lifecycle-схему для B2B: от регистрации в программе до первой измеримой выгоды (activation).

— @LifecycleToolsRuPro

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

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

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

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

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

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

Braze против Iterable: где заканчивается маркетинговая платформа и начинается разработка

Мы регулярно видим, как команды выбирают между Braze и Iterable на этапе, когда у них уже есть 200-500 тысяч активных пользователей. И почти всегда выбор делают по неправильным критериям: смотрят на шаблоны писем, считают коннекторы к push-провайдерам или сравнивают демо-аккаунты. Это всё вторично.

Реальная развилка — в соотношении маркетинговой логики и инженерных ресурсов.

**Braze сильнее там, где у компании есть выделенная команда разработки на Liquid и собственные data-инженеры под ETL (извлечение, преобразование и загрузку данных).** Платформа изначально проектировалась под сценарии со сложной оркестрацией каналов, глубокой кастомизацией событий и кастомными атрибутами. Если у вас десятки триггерных цепочек, нестандартные сегменты в реальном времени и потребность в A/B-тестах на уровне отдельных блоков письма — Braze раскрывается. Но эта же гибкость превращается в издержки: каждый нетривиальный сценарий требует разработчика, и через полгода маркетинговая команда оказывается в постоянной очереди на спринт.

**Iterable выигрывает в командах, где маркетологи хотят сами собирать сложные воркфлоу (автоматизированные цепочки коммуникаций) без заявок в бэклог.** Визуальный конструктор логичнее, условия читаются с первого взгляда, а к Crux Data Engine — их встроенной системе сегментации — можно подойти без понимания SQL. Минус — при росте объёмов и появлении нестандартных интеграций платформа начинает требовать всё больше обходных решений.

**Customer.io занимает промежуточную нишу и часто оказывается лучшим выбором для продуктовых команд на стадии роста.** Если вы уже живёте в событийной модели (event-based, когда поведение пользователя описывается цепочкой действий) и не хотите перегружать стек — стоит смотреть туда.

Наше наблюдение из практики внедрений: команды, которые выбирали Braze «на вырост», через год использовали 40-50% его возможностей и при этом тратили на сопровождение в 1,5-2 раза больше, чем планировали. Команды, которые выбирали Iterable, реже упирались в потолок, но чаще жаловались на качество документации и скорость поддержки в критических инцидентах.

Поэтому вопрос не «какая платформа объективно лучше», а **сколько инженерных часов в месяц вы готовы закладывать на lifecycle-маркетинг.** Если ноль — Iterable. Если есть выделенный разработчик — Braze. Если команда продуктовая и событийная — Customer.io.

А у вас какая диспозиция ресурсов?

— @LifecycleToolsRuPro

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

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

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

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

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

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

Как выбрать lifecycle-платформу: чек-лист для CRM-команды

Если вы сравниваете Braze, Iterable и Customer.io, не начинайте с списка функций. Сначала проверьте, что именно платформа должна закрывать в вашей lifecycle-логике: retention, онбординг, реактивацию, триггерные цепочки и управление частотой касаний.

— Зафиксируйте сценарии, а не «хотелки».
Опишите 5–7 основных цепочек: welcome, брошенная корзина, winback, post-purchase, NPS, продление подписки.
Для каждой цепочки отдельно отметьте, какие данные нужны, какой канал критичен и где сейчас ломается отправка.

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

— Проверьте оркестрацию каналов.
Email уже редко живёт в одиночку: нужны push, in-app, SMS, webhooks, иногда WhatsApp.
Сравнивайте не количество каналов в презентации, а как платформа держит последовательность сообщений и исключения между каналами.

— Посмотрите на работу с экспериментами.
В 2026 году выигрывает не тот, кто чаще отправляет, а кто быстрее проверяет гипотезы.
Нужны A/B-тесты, holdout-группы, контроль частоты и возможность измерять инкрементальность, а не только клики.

— Оцените требования к команде.
Braze обычно сильнее в сложных enterprise-сценариях, Iterable — в гибкости маркетинговой оркестрации, Customer.io — в более лёгком старте и скорости внедрения.
Но реальный выбор зависит от того, есть ли у вас аналитик, CRM-менеджер, разработчик и кто будет поддерживать систему.

— Проверьте, как платформа дружит с RevOps.
Маркетинг больше не живёт отдельно от sales и customer success.
Важно, чтобы lifecycle-инструмент отдавал данные в сквозную аналитику и не превращался в отдельный остров.

Когда это пригодится: перед выбором новой платформы, миграцией с текущего решения или пересборкой lifecycle-стека под retention и LTV.

— @LifecycleToolsRuPro

Braze всё ещё стоит дороже, чем Iterable, и иногда это всё ещё оправдано

После трёх лет сравнений у меня ощущение: **вы платите за Braze не фичи, а за страховку от шторма**. Когда у вас миллион MAU (ежемесячных активных пользователей) и пять разных команд, которые хотят трогать одни и те же события, — зрелый orchestration layer окупается. Iterable и Customer.io в этом плане подвозят, но на масштабе начинают требовать ручной склейки.

Тонкий момент: в 2026-м разница в «железе» сжимается, а разница в **цене владения** — растёт. У Braze по-прежнему дорогой onboarding и контракты, привязанные к объёму отправок. У Customer.io — дешевле вход, но больше работы вашей инженерной команды. Iterable — где-то посередине, если не лезть в сложные кейсы predictive.

Моё мнение: для команд до 500к MAU Braze — это переплата за бренд. После — вопрос не в возможностях, а в том, готовы ли вы платить за то, чтобы меньше думать о платформе и больше — о людях внутри неё.

— @LifecycleToolsRuPro

Как выбрать платформу для lifecycle-маркетинга: чек-лист по Braze, Iterable и Customer.io

Выбор между Braze, Iterable и Customer.io — это не про «кто круче», а про архитектуру вашей команды и зрелость данных. Перед пилотом пройдитесь по семи точкам решения.

— Определите источник правды для событий. Braze и Iterable требуют чистого CDP (customer data platform) или event-stream на входе. Customer.io терпимее к «грязным» данным за счёт встроенной сегментации, но платит за это скоростью при росте базы выше 1 млн профилей.

— Посчитайте стоимость не на MAU (monthly active users), а на отправленный канал. Iterable часто дешевле при email-heavy стратегии. Braze дороже, но включает in-app и push «из коробки» без интегратора. Customer.io выигрывает у обоих при старте с 50–200 тыс. контактов.

— Проверьте latency (задержку) триггеров. Если нужны реакции в реальном времени (брошенная корзина за 15 минут, отмена подписки → немедленное предложение) — тестируйте замер. Braze стабильнее, Iterable гибче, но требует настройки webhook-цепочек.

— Сопоставьте редактор контента с навыками команды. Liquid (язык шаблонов) есть у всех трёх, но визуальный конструктор Braze экономит время маркетолога без разработчика. Iterable — компромисс. Customer.io — минимум визуала, максимум контроля в коде.

— Зафиксируйте требования к data residency (размещение данных) и compliance. Для B2B и финтеха критично, где физически хранятся PII (персональные данные). Уточняйте регион до подписания, а не после.

— Заложите бюджет на миграцию. Перенос шаблонов, сегментов, suppressions (списков подавления рассылки) и историй доставляемости занимает 6–10 недель. Это не «переключили тумблер».

— Назначьте владельца платформы внутри. Без выделенного человека (не подрядчика) любая из трёх систем деградирует за полгода: дубли сегментов, мёртвые триггеры, утечки бюджета на неэффективные каналы.

Пригодится: при выборе новой платформы, аудите текущего стека и подготовке к питчу перед руководством.

— @LifecycleToolsRuPro