Deliverability-тест триггеров: как быстро понять, что у вас ломается между форматом письма и реальным доменом
Если вы запускаете триггеры, а письма «иногда не доходят» — почти всегда проблема не в контенте, а в связке: событие → шаблон → отправляющий домен → настройки маршрутизации → репутация. Ниже — практичный способ за 1 неделю локализовать, где именно течёт.
1) Сверьте, какой домен реально используется в триггере
— Возьмите 10 последних отправок из нужного триггера (в интерфейсе ESP/CRM или логах).
— Для каждой найдите фактический From-domain (домен письма) и Return-Path (если виден).
— Сравните с тем, что настроено в DNS/SPF/DKIM/DMARC под этот домен.
Цель: доказать, что письмо уходит «с того домена», который вы обслуживаете и защищаете. В 2026 это частая ошибка из-за динамических подстановок/нескольких брендов в одном аккаунте.
2) Разделите «почему не дошло» на 2 очереди: hard-bounce и silence
— В тех же 10 отправках выпишите статусы:
— hard-bounce (жёсткий отказ: не существует адреса)
— soft-bounce (временная проблема)
— delivered, но нет открытий/кликов (это может быть silence)
— deferred/queued (задержки)
— Если в вашем триггере много hard-bounce — это не про deliverability-тюнинг, а про качество базы и логику исключений (suppression, актуализация, re-engagement).
Цель: отделить технические отказы от «доставили, но пользователю не отобразилось/попало не туда».
3) Сделайте мини-эксперимент “один триггер — два домена/два шаблона”
На этой неделе достаточно одного контролируемого A/B без сложной статистики.
— Выберите один триггер (например, welcome 0–1 день или post-purchase follow-up).
— Подготовьте 2 варианта отправки:
— вариант A: текущий отправляющий домен/шаблон
— вариант B: тот же текст, но шаблон, где нет рискованных элементов (сложные редиректы, нестандартные link-обёртки, лишние изображения, подозрительные CTA-URL), и/или другой отправляющий домен, если он у вас уже прогрет для транзакционных писем
— Ограничьте экспозицию: 200–500 адресов на вариант или меньший сегмент, если у вас меньше трафика. Важно: одинаковое поведение по списку (один сегмент, один триггер).
4) Проведите “лог-диагностику” на уровне SMTP-цепочки
Если у вас есть доступ к message-logs/trace:
— Для доставленных и проблемных отправок посмотрите, где меняется маршрут (иногда это происходит после редиректов через трекинг/маршрутизаторы).
— Сверьте, есть ли согласованность доменов в цепочке: SPF/DKIM pass, DMARC alignment (когда письма приходят “без согласованности”, провайдеры всё чаще режут отображение).
Цель: поймать несоответствия, которые алгоритмы провайдера считают “подозрением”, даже если у вас формально есть SPF/DKIM.
5) Обновите suppression-логику именно для триггеров, а не только для рассылок
Типовая ловушка: broadcast вы «чистите», а триггеры продолжают писать тем, кто уже hard-bounce/complaint.
— Добавьте в исключения для триггеров:
— hard-bounce адреса
— недавние complaint (жалобы) с вашим окном (например, 30–90 дней)
— адреса с persistently failing (если это есть в ESP)
— Проверьте, что исключения применяются до фактической отправки, а не постфактум.
Цель: остановить “автопилот по плохим адресам”.
6) Зафиксируйте критерии “когда откатываем”
Чтобы не тратить недели на догадки:
— Если в варианте B улучшение по delivered ≥ 3–5 п.п. (или снижение hard-bounce/soft-bounce) за ваш объём — оставляйте вариант.
— Если improved silence (Delivered тот же, но письма хуже открываются) — проблема скорее в контентной/репутационной зоне (верстка, ссылки, частота, сигналы вовлечения), но не в DNS-цепочке.
Цель: решение на этой неделе, а не “ещё подождём”.
7) Привяжите это к RevOps-логике
В 2026 триггеры — часть общей ответственности за выручку: доставляемость влияет на воронку, а не только на “технические показатели”.
— Зафиксируйте в отчёте: какой триггер, какие статусы доставляемости, какой сегмент, какая цель (активация, удержание, повторные покупки).
— Если триггер относится к retention, связывайте доставляемость с метрикой “выполнили ключевое действие
— @EmailMarketingCraftPro
Если вы запускаете триггеры, а письма «иногда не доходят» — почти всегда проблема не в контенте, а в связке: событие → шаблон → отправляющий домен → настройки маршрутизации → репутация. Ниже — практичный способ за 1 неделю локализовать, где именно течёт.
1) Сверьте, какой домен реально используется в триггере
— Возьмите 10 последних отправок из нужного триггера (в интерфейсе ESP/CRM или логах).
— Для каждой найдите фактический From-domain (домен письма) и Return-Path (если виден).
— Сравните с тем, что настроено в DNS/SPF/DKIM/DMARC под этот домен.
Цель: доказать, что письмо уходит «с того домена», который вы обслуживаете и защищаете. В 2026 это частая ошибка из-за динамических подстановок/нескольких брендов в одном аккаунте.
2) Разделите «почему не дошло» на 2 очереди: hard-bounce и silence
— В тех же 10 отправках выпишите статусы:
— hard-bounce (жёсткий отказ: не существует адреса)
— soft-bounce (временная проблема)
— delivered, но нет открытий/кликов (это может быть silence)
— deferred/queued (задержки)
— Если в вашем триггере много hard-bounce — это не про deliverability-тюнинг, а про качество базы и логику исключений (suppression, актуализация, re-engagement).
Цель: отделить технические отказы от «доставили, но пользователю не отобразилось/попало не туда».
3) Сделайте мини-эксперимент “один триггер — два домена/два шаблона”
На этой неделе достаточно одного контролируемого A/B без сложной статистики.
— Выберите один триггер (например, welcome 0–1 день или post-purchase follow-up).
— Подготовьте 2 варианта отправки:
— вариант A: текущий отправляющий домен/шаблон
— вариант B: тот же текст, но шаблон, где нет рискованных элементов (сложные редиректы, нестандартные link-обёртки, лишние изображения, подозрительные CTA-URL), и/или другой отправляющий домен, если он у вас уже прогрет для транзакционных писем
— Ограничьте экспозицию: 200–500 адресов на вариант или меньший сегмент, если у вас меньше трафика. Важно: одинаковое поведение по списку (один сегмент, один триггер).
4) Проведите “лог-диагностику” на уровне SMTP-цепочки
Если у вас есть доступ к message-logs/trace:
— Для доставленных и проблемных отправок посмотрите, где меняется маршрут (иногда это происходит после редиректов через трекинг/маршрутизаторы).
— Сверьте, есть ли согласованность доменов в цепочке: SPF/DKIM pass, DMARC alignment (когда письма приходят “без согласованности”, провайдеры всё чаще режут отображение).
Цель: поймать несоответствия, которые алгоритмы провайдера считают “подозрением”, даже если у вас формально есть SPF/DKIM.
5) Обновите suppression-логику именно для триггеров, а не только для рассылок
Типовая ловушка: broadcast вы «чистите», а триггеры продолжают писать тем, кто уже hard-bounce/complaint.
— Добавьте в исключения для триггеров:
— hard-bounce адреса
— недавние complaint (жалобы) с вашим окном (например, 30–90 дней)
— адреса с persistently failing (если это есть в ESP)
— Проверьте, что исключения применяются до фактической отправки, а не постфактум.
Цель: остановить “автопилот по плохим адресам”.
6) Зафиксируйте критерии “когда откатываем”
Чтобы не тратить недели на догадки:
— Если в варианте B улучшение по delivered ≥ 3–5 п.п. (или снижение hard-bounce/soft-bounce) за ваш объём — оставляйте вариант.
— Если improved silence (Delivered тот же, но письма хуже открываются) — проблема скорее в контентной/репутационной зоне (верстка, ссылки, частота, сигналы вовлечения), но не в DNS-цепочке.
Цель: решение на этой неделе, а не “ещё подождём”.
7) Привяжите это к RevOps-логике
В 2026 триггеры — часть общей ответственности за выручку: доставляемость влияет на воронку, а не только на “технические показатели”.
— Зафиксируйте в отчёте: какой триггер, какие статусы доставляемости, какой сегмент, какая цель (активация, удержание, повторные покупки).
— Если триггер относится к retention, связывайте доставляемость с метрикой “выполнили ключевое действие
— @EmailMarketingCraftPro
Broadcast vs Triggered: не путайте тактический огонь со стратегическим
Broadcast (массовая рассылка) — это отправка одного и того же сообщения сразу всем контактам из сегмента в заданное время. Нет привязки к действию пользователя. Цель — донести новость, промо, дайджест. Сегментация возможна, но время и содержание диктует отправитель.
Triggered (триггерная рассылка) — запускается действием или бездействием подписчика: регистрация, корзина, 30 дней молчания, переход по ссылке. У каждого контакта свой сценарий и время отправки.
Главное отличие: broadcast — про календарь и редакционный план, triggered — про поведение и жизненный цикл. Они не взаимозаменяемы, а дополняют друг друга.
Типичная ошибка: называть broadcast'ом автоматическую серию, которая стартует после подписки. Это именно triggered. Другая крайность — пытаться заменить триггеры массовками: «отправим приветственное письмо всем новым подписчикам раз в неделю». Это убивает актуальность: человек уже мог купить или уйти в отписку.
Пример. У вас распродажа курток. Broadcast — одно письмо всем, кто подходит по сегменту (климат, пол, история покупок), в четверг в 12:00. Triggered — сценарий на брошенную корзину: если человек добавил куртку, но не купил за 2 часа — летит письмо с её фото, размерной сеткой и отсчётом скидки. Первое — охват, второе — дожим.
В 2026 году broadcast начинает сильнее давить на deliverability при низком Engagement Rate, поэтому без частотных лимитов и пре-сегментации по вовлечённости делать массовки рискованно. Triggered же остаётся якорем для LTV и retention, особенно в B2B (каскад касаний после лид-магнита) и e-com (автоматизация по снижению чека).
— @EmailMarketingCraftPro
Broadcast (массовая рассылка) — это отправка одного и того же сообщения сразу всем контактам из сегмента в заданное время. Нет привязки к действию пользователя. Цель — донести новость, промо, дайджест. Сегментация возможна, но время и содержание диктует отправитель.
Triggered (триггерная рассылка) — запускается действием или бездействием подписчика: регистрация, корзина, 30 дней молчания, переход по ссылке. У каждого контакта свой сценарий и время отправки.
Главное отличие: broadcast — про календарь и редакционный план, triggered — про поведение и жизненный цикл. Они не взаимозаменяемы, а дополняют друг друга.
Типичная ошибка: называть broadcast'ом автоматическую серию, которая стартует после подписки. Это именно triggered. Другая крайность — пытаться заменить триггеры массовками: «отправим приветственное письмо всем новым подписчикам раз в неделю». Это убивает актуальность: человек уже мог купить или уйти в отписку.
Пример. У вас распродажа курток. Broadcast — одно письмо всем, кто подходит по сегменту (климат, пол, история покупок), в четверг в 12:00. Triggered — сценарий на брошенную корзину: если человек добавил куртку, но не купил за 2 часа — летит письмо с её фото, размерной сеткой и отсчётом скидки. Первое — охват, второе — дожим.
В 2026 году broadcast начинает сильнее давить на deliverability при низком Engagement Rate, поэтому без частотных лимитов и пре-сегментации по вовлечённости делать массовки рискованно. Triggered же остаётся якорем для LTV и retention, особенно в B2B (каскад касаний после лид-магнита) и e-com (автоматизация по снижению чека).
— @EmailMarketingCraftPro
Триггерная цепочка, которая не раздражает: как собрать lifecycle без «ещё одной рассылки в день»
В этом разборе хочу разобрать одну штуку, которая ломается у большинства команд в первые полгода работы с триггерами. Команда начинает строить lifecycle-коммуникации, запускает welcome-цепочку, добавляет брошенную корзину, реактивацию, день рождения — и через три месяца у каждого пользователя в inbox лежит по пять писем в неделю. Открываемось падает, отписки растут, продукт начинает выглядеть как человек, который не умеет делать паузы в разговоре. Проблема не в триггерах как таковых — она в отсутствии оркестрации между ними.
Если посмотреть на зрелые CRM-команды, видно одну и ту же эволюцию. Сначала карта коммуникаций — это набор независимых потоков, каждый со своим триггером и своей целью. Потом приходит понимание, что потоков быть не должно — должна быть одна непрерывная история про клиента, в которой у каждого письма есть место в сценарии. Это и есть оркестрация: ты решаешь, что в конкретный момент времени клиент получит самое важное, а остальные потоки молчат.
Дальше — про то, как этого добиться на практике.
**Единая точка входа вместо разрозненных потоков**
Самая частая архитектурная ошибка — когда каждая цепочка живёт в своём CDP-сегменте и запускается по своему событию. Welcome видит регистрацию, брошенная корзина видит свой checkout_start, реактивация видит своё «не открывал 60 дней». Они между собой не договариваются. Результат предсказуем: пользователь, который только что получил welcome-письмо с подборкой товаров, через час ловит триггер «вы бросили корзину» — хотя он её и не бросал, просто зарегистрировался через форму с товарной страницы.
Решение — единая точка входа в коммуникацию, по сути state-машина (модель с конечным числом состояний и переходов между ними). Клиент находится в одном из N состояний lifecycle: новичок, активный, риск оттока, реактивированный, лояльный. Каждое письмо — это не запуск новой цепочки, а переход между состояниями или реакция на событие внутри текущего состояния. Если в состоянии «новичок» произошло событие, относящееся к «риску оттока», система сначала решает — уместно ли менять состояние сейчас, или новичку важнее получить свою онбординговую серию. Тот же подход описывают в гайдах по lifecycle-маркетингу крупные платформы вроде Iterable и Braze, и он хорошо ложится на реальные кейсы.
Один показательный пример — работа сервиса доставки «Самокат» в период запуска подписки. Когда человек одновременно попадал в welcome-серию подписки и в поток реактивации по старой скидочной механике, отписки с обоих потоков шли плотно. После того как команда ввела понятие «текущая приоритетная тема» для каждого клиента и запретила потокам перебивать друг друга в течение 72 часов, совокупная unsubscribe rate (процент отписок от рассылки) упала почти вдвое, а open rate (процент открытий) по онбордингу вырос. Маленькая архитектурная правда, большие последствия.
**Тишина как инструмент**
Второй кусок — про расчёт частоты. Многие команды до сих пор думают категорией «сколько писем в неделю нормально». Это плохая категория. Нормально — это столько, сколько клиент дал повод получить, плюс одна служебная сверху. Не больше.
Повод — это конкретное событие: покупка, смена статуса, полезное обновление по его заказу, новая подборка по его интересам. Служебная — транзакционная или одна soft-sell (мягкая продажа) на онбординговой фазе, где человек ещё не до конца понял ценность продукта. Всё остальное — это коммуникационный шум, который постепенно учит пользователя игнорировать отправителя. Один из самых дорогих активов email-маркетинга — внимание подписчика, и оно расходуется буквально с каждым письмом.
Здесь хорошо работает правило «48 часов между любыми двумя письмами одной тематики
— @EmailMarketingCraftPro
В этом разборе хочу разобрать одну штуку, которая ломается у большинства команд в первые полгода работы с триггерами. Команда начинает строить lifecycle-коммуникации, запускает welcome-цепочку, добавляет брошенную корзину, реактивацию, день рождения — и через три месяца у каждого пользователя в inbox лежит по пять писем в неделю. Открываемось падает, отписки растут, продукт начинает выглядеть как человек, который не умеет делать паузы в разговоре. Проблема не в триггерах как таковых — она в отсутствии оркестрации между ними.
Если посмотреть на зрелые CRM-команды, видно одну и ту же эволюцию. Сначала карта коммуникаций — это набор независимых потоков, каждый со своим триггером и своей целью. Потом приходит понимание, что потоков быть не должно — должна быть одна непрерывная история про клиента, в которой у каждого письма есть место в сценарии. Это и есть оркестрация: ты решаешь, что в конкретный момент времени клиент получит самое важное, а остальные потоки молчат.
Дальше — про то, как этого добиться на практике.
**Единая точка входа вместо разрозненных потоков**
Самая частая архитектурная ошибка — когда каждая цепочка живёт в своём CDP-сегменте и запускается по своему событию. Welcome видит регистрацию, брошенная корзина видит свой checkout_start, реактивация видит своё «не открывал 60 дней». Они между собой не договариваются. Результат предсказуем: пользователь, который только что получил welcome-письмо с подборкой товаров, через час ловит триггер «вы бросили корзину» — хотя он её и не бросал, просто зарегистрировался через форму с товарной страницы.
Решение — единая точка входа в коммуникацию, по сути state-машина (модель с конечным числом состояний и переходов между ними). Клиент находится в одном из N состояний lifecycle: новичок, активный, риск оттока, реактивированный, лояльный. Каждое письмо — это не запуск новой цепочки, а переход между состояниями или реакция на событие внутри текущего состояния. Если в состоянии «новичок» произошло событие, относящееся к «риску оттока», система сначала решает — уместно ли менять состояние сейчас, или новичку важнее получить свою онбординговую серию. Тот же подход описывают в гайдах по lifecycle-маркетингу крупные платформы вроде Iterable и Braze, и он хорошо ложится на реальные кейсы.
Один показательный пример — работа сервиса доставки «Самокат» в период запуска подписки. Когда человек одновременно попадал в welcome-серию подписки и в поток реактивации по старой скидочной механике, отписки с обоих потоков шли плотно. После того как команда ввела понятие «текущая приоритетная тема» для каждого клиента и запретила потокам перебивать друг друга в течение 72 часов, совокупная unsubscribe rate (процент отписок от рассылки) упала почти вдвое, а open rate (процент открытий) по онбордингу вырос. Маленькая архитектурная правда, большие последствия.
**Тишина как инструмент**
Второй кусок — про расчёт частоты. Многие команды до сих пор думают категорией «сколько писем в неделю нормально». Это плохая категория. Нормально — это столько, сколько клиент дал повод получить, плюс одна служебная сверху. Не больше.
Повод — это конкретное событие: покупка, смена статуса, полезное обновление по его заказу, новая подборка по его интересам. Служебная — транзакционная или одна soft-sell (мягкая продажа) на онбординговой фазе, где человек ещё не до конца понял ценность продукта. Всё остальное — это коммуникационный шум, который постепенно учит пользователя игнорировать отправителя. Один из самых дорогих активов email-маркетинга — внимание подписчика, и оно расходуется буквально с каждым письмом.
Здесь хорошо работает правило «48 часов между любыми двумя письмами одной тематики
— @EmailMarketingCraftPro
Триггер не спасает плохую сегментацию
В CRM до сих пор любят спорить про частоту и время отправки, как будто это главный рычаг. На практике триггерный сценарий либо попадает в потребность, либо нет. Если сегмент собран грубо, письмо уходит «в момент», но мимо ожидания, и дальше уже неважно, какой у него subject и какая у него deliverability. В 2026 это особенно заметно: денег меньше, retention важнее первой реакции, а автоматизация без точной логики лишь ускоряет ошибку.
— @EmailMarketingCraftPro
В CRM до сих пор любят спорить про частоту и время отправки, как будто это главный рычаг. На практике триггерный сценарий либо попадает в потребность, либо нет. Если сегмент собран грубо, письмо уходит «в момент», но мимо ожидания, и дальше уже неважно, какой у него subject и какая у него deliverability. В 2026 это особенно заметно: денег меньше, retention важнее первой реакции, а автоматизация без точной логики лишь ускоряет ошибку.
— @EmailMarketingCraftPro
Триггер “все ждут рассылку” — ловушка
Самая частая проблема в lifecycle-письмах, которую я вижу в CRM: триггер включают только как “событие → письмо”. А дальше — тишина и метрики. В 2026 на фоне AI-обзоров и privacy-first атрибуции это особенно больно: вы не просто отправляете, вы создаёте ожидание и цепляете доставляемость. Мой критерий: у каждого триггера должна быть причина “почему именно сейчас” для конкретного сегмента, иначе это просто массовый broadcast под видом персонализации.
— @EmailMarketingCraftPro
Самая частая проблема в lifecycle-письмах, которую я вижу в CRM: триггер включают только как “событие → письмо”. А дальше — тишина и метрики. В 2026 на фоне AI-обзоров и privacy-first атрибуции это особенно больно: вы не просто отправляете, вы создаёте ожидание и цепляете доставляемость. Мой критерий: у каждого триггера должна быть причина “почему именно сейчас” для конкретного сегмента, иначе это просто массовый broadcast под видом персонализации.
— @EmailMarketingCraftPro
Как собрать триггер «брошенный просмотр» без лишних писем
Если у вас есть каталоги, статьи, вебинары или карточки товаров, триггер по просмотру часто даёт быстрый прирост к повторным визитам. Но только если не слать письмо на каждый чих. Ниже схема, которую можно собрать за неделю.
1. Определите, что считать просмотром
— Для e-com: карточка товара, категория, поиск внутри сайта.
— Для B2B: кейс, тарифы, страница продукта, форма заявки без отправки.
— Для контента: статья из ключевого кластера, вебинар, демо-страница.
2. Поставьте фильтр «сигнал есть, намерение сильное»
Не запускайте письмо после любого просмотра. Нужны условия:
— человек не купил и не оставил заявку;
— на странице провёл достаточно времени;
— смотрел 2+ страницы одного сценария за сессию;
— не получал этот триггер последние 7–14 дней.
3. Разделите сценарии по намерению
Одна и та же логика не работает для всех.
— Высокое намерение: тарифы, корзина, демо — письмо через 1–3 часа.
— Среднее: категория, кейс, статья — письмо через 12–24 часа.
— Низкое: общий блог — лучше не триггер, а догрев через broadcast (массовую рассылку).
4. Соберите письмо вокруг следующего шага
Не повторяйте просмотр. Дайте действие:
— вернуться к выбранному товару;
— сравнить 2–3 решения;
— скачать чек-лист;
— записаться на демо;
— посмотреть кейс по той же отрасли.
Тема письма должна быть конкретной, без «Вы забыли…».
5. Ограничьте частоту и конфликт с другими цепочками
Если у человека уже идёт welcome, реактивация или post-purchase, триггер по просмотру может мешать. Заведите приоритеты:
— критические сервисные письма выше;
— транзакционные выше маркетинговых;
— триггер просмотра не чаще 1 раза в 7 дней на один сценарий.
6. Проверьте доставляемость
Слишком резкий всплеск триггеров бьёт по репутации домена.
— запускайте на 10–20% базы;
— следите за жалобами и отписками;
— убирайте слабые сегменты с низким engagement;
— не дублируйте триггер одним и тем же пользователям через broadcast.
Через неделю у вас уже будет рабочая версия: один сильный сценарий, одно письмо, одна метрика успеха — переход в целевое действие. Потом масштабируйте на другие страницы.
— @EmailMarketingCraftPro
Если у вас есть каталоги, статьи, вебинары или карточки товаров, триггер по просмотру часто даёт быстрый прирост к повторным визитам. Но только если не слать письмо на каждый чих. Ниже схема, которую можно собрать за неделю.
1. Определите, что считать просмотром
— Для e-com: карточка товара, категория, поиск внутри сайта.
— Для B2B: кейс, тарифы, страница продукта, форма заявки без отправки.
— Для контента: статья из ключевого кластера, вебинар, демо-страница.
2. Поставьте фильтр «сигнал есть, намерение сильное»
Не запускайте письмо после любого просмотра. Нужны условия:
— человек не купил и не оставил заявку;
— на странице провёл достаточно времени;
— смотрел 2+ страницы одного сценария за сессию;
— не получал этот триггер последние 7–14 дней.
3. Разделите сценарии по намерению
Одна и та же логика не работает для всех.
— Высокое намерение: тарифы, корзина, демо — письмо через 1–3 часа.
— Среднее: категория, кейс, статья — письмо через 12–24 часа.
— Низкое: общий блог — лучше не триггер, а догрев через broadcast (массовую рассылку).
4. Соберите письмо вокруг следующего шага
Не повторяйте просмотр. Дайте действие:
— вернуться к выбранному товару;
— сравнить 2–3 решения;
— скачать чек-лист;
— записаться на демо;
— посмотреть кейс по той же отрасли.
Тема письма должна быть конкретной, без «Вы забыли…».
5. Ограничьте частоту и конфликт с другими цепочками
Если у человека уже идёт welcome, реактивация или post-purchase, триггер по просмотру может мешать. Заведите приоритеты:
— критические сервисные письма выше;
— транзакционные выше маркетинговых;
— триггер просмотра не чаще 1 раза в 7 дней на один сценарий.
6. Проверьте доставляемость
Слишком резкий всплеск триггеров бьёт по репутации домена.
— запускайте на 10–20% базы;
— следите за жалобами и отписками;
— убирайте слабые сегменты с низким engagement;
— не дублируйте триггер одним и тем же пользователям через broadcast.
Через неделю у вас уже будет рабочая версия: один сильный сценарий, одно письмо, одна метрика успеха — переход в целевое действие. Потом масштабируйте на другие страницы.
— @EmailMarketingCraftPro
Почему триггеры перестают «спасать» retention
Я вижу это всё чаще: CRM-команда запускает десяток триггеров, а выручка от них растёт слабее, чем сам список автоматизаций. Причина обычно не в «плохом триггере», а в том, что триггеры начинают жить отдельно от broadcast-рассылок, продуктовых сценариев и deliverability.
В 2026 это особенно заметно. Средний чек в e-com проседает, и одна допродажа уже не тащит экономику. Значит, триггер должен не просто напоминать о корзине или брошенном просмотре, а подхватывать весь цикл: первую покупку, повтор, реактивацию, снижение частоты. Если сценарий закрывает только узкий момент, он быстро выгорает.
Из практики: в одном проекте мы сократили количество триггеров почти на треть, но добавили связки между ними и регулярными рассылками. Не «автоматизация сама по себе», а логика: что человек уже получил в broadcast, какой сигнал ему ушёл из продукта, и не перегружаем ли мы его письмами. В результате open rate не был главным победителем, а вот доля выручки с автоматических цепочек выросла заметно — за счёт меньшего дубляжа и лучшего тайминга.
Мой вывод простой: **триггер в 2026 — это не письмо по событию, а часть архитектуры отношения с клиентом**.
Что я проверяю первым:
— есть ли у триггера сосед по broadcast, который говорит с той же аудиторией;
— не бьём ли мы по одной и той же боли двумя разными письмами;
— есть ли у сценария точка выхода, а не только точка входа;
— влияет ли письмо на повторную покупку или только на открытие.
Если автоматизация не связана с общей lifecycle-логикой, она начинает «шуметь». А шум сегодня быстро убивает и доставляемость, и внимание подписчика.
— @EmailMarketingCraftPro
Я вижу это всё чаще: CRM-команда запускает десяток триггеров, а выручка от них растёт слабее, чем сам список автоматизаций. Причина обычно не в «плохом триггере», а в том, что триггеры начинают жить отдельно от broadcast-рассылок, продуктовых сценариев и deliverability.
В 2026 это особенно заметно. Средний чек в e-com проседает, и одна допродажа уже не тащит экономику. Значит, триггер должен не просто напоминать о корзине или брошенном просмотре, а подхватывать весь цикл: первую покупку, повтор, реактивацию, снижение частоты. Если сценарий закрывает только узкий момент, он быстро выгорает.
Из практики: в одном проекте мы сократили количество триггеров почти на треть, но добавили связки между ними и регулярными рассылками. Не «автоматизация сама по себе», а логика: что человек уже получил в broadcast, какой сигнал ему ушёл из продукта, и не перегружаем ли мы его письмами. В результате open rate не был главным победителем, а вот доля выручки с автоматических цепочек выросла заметно — за счёт меньшего дубляжа и лучшего тайминга.
Мой вывод простой: **триггер в 2026 — это не письмо по событию, а часть архитектуры отношения с клиентом**.
Что я проверяю первым:
— есть ли у триггера сосед по broadcast, который говорит с той же аудиторией;
— не бьём ли мы по одной и той же боли двумя разными письмами;
— есть ли у сценария точка выхода, а не только точка входа;
— влияет ли письмо на повторную покупку или только на открытие.
Если автоматизация не связана с общей lifecycle-логикой, она начинает «шуметь». А шум сегодня быстро убивает и доставляемость, и внимание подписчика.
— @EmailMarketingCraftPro
Forwarded from Потрачено! Клуб спящих бизнесменов!
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 aff.top — вся индустрия арбитража в одном месте
🧠 Блог про арбитраж и ИИ — как нейросети меняют залив и антифрод
🚨 База спамеров — ежедневно собираем спамеров и ведём рейтинг
🛠 70+ инструментов — от клоаки до антифрод-чека
🎬 1000+ видео — весь YouTube про трафик в одной ленте
👤 2400+ персон — байеры и фаундеры с контактами напрямую
Без регистрации, без платных «премиумов».
👇 Подписывайся на канал
🧠 Блог про арбитраж и ИИ — как нейросети меняют залив и антифрод
🚨 База спамеров — ежедневно собираем спамеров и ведём рейтинг
🛠 70+ инструментов — от клоаки до антифрод-чека
🎬 1000+ видео — весь YouTube про трафик в одной ленте
👤 2400+ персон — байеры и фаундеры с контактами напрямую
Без регистрации, без платных «премиумов».
👇 Подписывайся на канал
Лайфцикл-триггеры без “сценариев на 200 сообщений”: как я режу сложность и поднимаю deliverability
В 2026 я всё чаще вижу одну и ту же проблему в командах CRM: триггеры превращаются в многоэтажные “сценарии-лаборатории”. Маркетинг старается закрыть весь путь клиента — и в итоге получает две ошибки сразу: задержку реакции и шум для почты. Почтовым провайдерам не важна ваша красота Journey. Им важны стабильность объёма, предсказуемость паттернов отправок и то, как читают именно ваши письма.
Мой принцип сейчас простой: **триггер — это не автоматизация “всё обо всём”, а управляемая единица нагрузки на отправку и на репутацию**. Поэтому я режу сложность так:
— Один триггер = одно обещание (одно “зачем” письма)
— В цепочке оставляю 1 основную отправку + 1 “страховочную” (если не было реакции)
— Тайминги делаю не “по учебнику”, а по поведению сегмента (окно активности важнее календаря)
Почему это работает (практическое наблюдение из проектов по B2B и e-com, где мы чинили и поведение, и доставляемость одновременно): когда цепочки сокращаются с 5–7 касаний до 2–3, у нас обычно падает доля жалоб и растёт доля “прохождений” по доменной репутации уже в первые 2–4 недели. А ключевой эффект — снижается вероятность, что часть аудитории начнёт получать письма “не в свой момент” и начнёт игнорировать. Игнор — это самый тихий убийца deliverability в privacy-first мире, где атрибуция и так поддавлена, и вы не можете себе позволить терять читаемость.
Как я проектирую триггеры, чтобы они были устойчивыми:
1) Сначала определяю “вход” — не событие ради события, а момент с понятной ценностью. Например: “пользователь дошёл до ключевого шага” или “сервис сгенерировал результат, который можно объяснить”.
2) Затем задаю лимит отправок на человека в сутки/неделю. Не красивое ограничение в платформе, а реальный guardrail для объёма.
3) Проверяю сегмент на историческую реакцию: если open/click в этом сегменте низкий, я не “усиливаю копирайтинг”, я меняю логику касания (или паузу), иначе вы просто ускоряете деградацию репутации.
Важный нюанс для CRM-маркетинга 2026: когда лидогенерация “старая” проседает, триггеры становятся частью RevOps (общей ответственности маркетинга, продаж и customer success за выручку). И там побеждает не тот, у кого больше сообщений, а тот, кто быстрее и точнее попадает в следующий шаг клиента — и делает это без раскачки репутации отправителя.
Если хотите быстро проверить, насколько вы “перегрузили” систему: выгрузите топ-5 триггеров по числу отправок и топ-5 по жалобам/непрочтениям. Часто оказывается, что самые массивные сценарии и есть источники деградации. Я бы начал оптимизацию именно с них — не с тем писем, а с объёма и частотной дисциплины.
— @EmailMarketingCraftPro
В 2026 я всё чаще вижу одну и ту же проблему в командах CRM: триггеры превращаются в многоэтажные “сценарии-лаборатории”. Маркетинг старается закрыть весь путь клиента — и в итоге получает две ошибки сразу: задержку реакции и шум для почты. Почтовым провайдерам не важна ваша красота Journey. Им важны стабильность объёма, предсказуемость паттернов отправок и то, как читают именно ваши письма.
Мой принцип сейчас простой: **триггер — это не автоматизация “всё обо всём”, а управляемая единица нагрузки на отправку и на репутацию**. Поэтому я режу сложность так:
— Один триггер = одно обещание (одно “зачем” письма)
— В цепочке оставляю 1 основную отправку + 1 “страховочную” (если не было реакции)
— Тайминги делаю не “по учебнику”, а по поведению сегмента (окно активности важнее календаря)
Почему это работает (практическое наблюдение из проектов по B2B и e-com, где мы чинили и поведение, и доставляемость одновременно): когда цепочки сокращаются с 5–7 касаний до 2–3, у нас обычно падает доля жалоб и растёт доля “прохождений” по доменной репутации уже в первые 2–4 недели. А ключевой эффект — снижается вероятность, что часть аудитории начнёт получать письма “не в свой момент” и начнёт игнорировать. Игнор — это самый тихий убийца deliverability в privacy-first мире, где атрибуция и так поддавлена, и вы не можете себе позволить терять читаемость.
Как я проектирую триггеры, чтобы они были устойчивыми:
1) Сначала определяю “вход” — не событие ради события, а момент с понятной ценностью. Например: “пользователь дошёл до ключевого шага” или “сервис сгенерировал результат, который можно объяснить”.
2) Затем задаю лимит отправок на человека в сутки/неделю. Не красивое ограничение в платформе, а реальный guardrail для объёма.
3) Проверяю сегмент на историческую реакцию: если open/click в этом сегменте низкий, я не “усиливаю копирайтинг”, я меняю логику касания (или паузу), иначе вы просто ускоряете деградацию репутации.
Важный нюанс для CRM-маркетинга 2026: когда лидогенерация “старая” проседает, триггеры становятся частью RevOps (общей ответственности маркетинга, продаж и customer success за выручку). И там побеждает не тот, у кого больше сообщений, а тот, кто быстрее и точнее попадает в следующий шаг клиента — и делает это без раскачки репутации отправителя.
Если хотите быстро проверить, насколько вы “перегрузили” систему: выгрузите топ-5 триггеров по числу отправок и топ-5 по жалобам/непрочтениям. Часто оказывается, что самые массивные сценарии и есть источники деградации. Я бы начал оптимизацию именно с них — не с тем писем, а с объёма и частотной дисциплины.
— @EmailMarketingCraftPro
This media is not supported in your browser
VIEW IN TELEGRAM
Алиса AI будет конкурировать с Google AI Studio
Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…
➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio
🧠 Ещё больше инсайтов → в канале AFF.top
Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…
➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
В Zennoposter добавили ИИ-помощник
Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…
➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik
🧠 Ещё больше инсайтов → в канале AFF.top
Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…
➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik
🧠 Ещё больше инсайтов → в канале AFF.top
Брошенная корзина перестала быть главным триггером по выручке
В одном проекте (fashion, ~120k подписчиков) разобрал вклад триггеров в повторные покупки за последние 60 дней. Брошенная корзина всё ещё лидирует по количеству срабатываний, но по доле в выручке уступила двум вещам:
— Триггер на возврат в категорию, где клиент уже покупал («Вы смотрели ботинки, но в этот раз — новая модель в той же категории»)
— Серия из трёх писем после доставки: отзыв → апсейл по сопутствующим → ранний доступ к распродаже
Первый триггер даёт ~18% повторных заказов за 14 дней, второй — ~12% в окне 21 день. Классическая брошенка — ~9%.
Картина для меня новая: lifecycle (пожизненный цикл клиента) всё больше опирается на историю покупок, а не на последнее действие в сессии. Получается, что данные о прошлых заказах ценнее сигнала «человек не дожал вводную».
Интересно, у вас похожая картина или порядок другой? Особенно — в B2B и подписных моделях, где корзины формально нет вообще.
— @EmailMarketingCraftPro
В одном проекте (fashion, ~120k подписчиков) разобрал вклад триггеров в повторные покупки за последние 60 дней. Брошенная корзина всё ещё лидирует по количеству срабатываний, но по доле в выручке уступила двум вещам:
— Триггер на возврат в категорию, где клиент уже покупал («Вы смотрели ботинки, но в этот раз — новая модель в той же категории»)
— Серия из трёх писем после доставки: отзыв → апсейл по сопутствующим → ранний доступ к распродаже
Первый триггер даёт ~18% повторных заказов за 14 дней, второй — ~12% в окне 21 день. Классическая брошенка — ~9%.
Картина для меня новая: lifecycle (пожизненный цикл клиента) всё больше опирается на историю покупок, а не на последнее действие в сессии. Получается, что данные о прошлых заказах ценнее сигнала «человек не дожал вводную».
Интересно, у вас похожая картина или порядок другой? Особенно — в B2B и подписных моделях, где корзины формально нет вообще.
— @EmailMarketingCraftPro
This media is not supported in your browser
VIEW IN TELEGRAM
Новую Google reCapcha прошли статичной картинкой
Google выпустил обновленную reCAPTCHA, требующую движений рук для прохождения, но система оказалась уязвима к обходу. Достаточно транслировать статичное изображение с нужным жестом через виртуальную камеру с помощью простого Python-скрипта, чтобы нейросеть пропустила пользователя. Это создает серьёзный риск для сайтов: защита от ботов, позиционировавшаяся как прорыв, на деле не работает. Баг остается актуальным и позволяет спамерам легко автомат…
➡️ Читайте на сайте: https://aff.top/blog/novuiu-google-recapcha-proshli-statichnoi-kartinkoi
🧠 Ещё больше инсайтов → в канале AFF.top
Google выпустил обновленную reCAPTCHA, требующую движений рук для прохождения, но система оказалась уязвима к обходу. Достаточно транслировать статичное изображение с нужным жестом через виртуальную камеру с помощью простого Python-скрипта, чтобы нейросеть пропустила пользователя. Это создает серьёзный риск для сайтов: защита от ботов, позиционировавшаяся как прорыв, на деле не работает. Баг остается актуальным и позволяет спамерам легко автомат…
➡️ Читайте на сайте: https://aff.top/blog/novuiu-google-recapcha-proshli-statichnoi-kartinkoi
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
DeepSeek представит последнюю версию v4
DeepSeek выпустит v4 в середине июля с новой моделью ценообразования API: токены подорожают в 2 раза в часы пиковой нагрузки (09:00–12:00 и 14:00–18:00 по пекинскому времени). Компания планирует уведомлять пользователей по почте за 24 часа до изменения тарифов. Проблема с ошибками «server busy» останется, но обойдётся дороже — это может существенно повлиять на экономику проектов, которые активно используют API DeepSeek для автоматизации и масшта…
➡️ Читайте на сайте: https://aff.top/blog/deepseek-predstavit-posledniuiu-versiiu-v4
🧠 Ещё больше инсайтов → в канале AFF.top
DeepSeek выпустит v4 в середине июля с новой моделью ценообразования API: токены подорожают в 2 раза в часы пиковой нагрузки (09:00–12:00 и 14:00–18:00 по пекинскому времени). Компания планирует уведомлять пользователей по почте за 24 часа до изменения тарифов. Проблема с ошибками «server busy» останется, но обойдётся дороже — это может существенно повлиять на экономику проектов, которые активно используют API DeepSeek для автоматизации и масшта…
➡️ Читайте на сайте: https://aff.top/blog/deepseek-predstavit-posledniuiu-versiiu-v4
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Anthropic выпустили Sonnet 5
30 июня вышла Claude Sonnet 5 — новая версия позиционируется как самая агентная в линейке и приближается к флагманской Opus 4.8. Модель лучше справляется со сложными многоуровневыми задачами, устойчива к вредоносным запросам и не генерирует эксплойты. Sonnet 5 доступна на Free-тарифе, но тестирование показало скромные улучшения: хотя работает лучше Sonnet 4.6, её обгоняют конкуренты, включая китайские модели, которые дешевле через API при лучшей…
➡️ Читайте на сайте: https://aff.top/blog/anthropic-vypustili-sonnet-5
🧠 Ещё больше инсайтов → в канале AFF.top
30 июня вышла Claude Sonnet 5 — новая версия позиционируется как самая агентная в линейке и приближается к флагманской Opus 4.8. Модель лучше справляется со сложными многоуровневыми задачами, устойчива к вредоносным запросам и не генерирует эксплойты. Sonnet 5 доступна на Free-тарифе, но тестирование показало скромные улучшения: хотя работает лучше Sonnet 4.6, её обгоняют конкуренты, включая китайские модели, которые дешевле через API при лучшей…
➡️ Читайте на сайте: https://aff.top/blog/anthropic-vypustili-sonnet-5
🧠 Ещё больше инсайтов → в канале AFF.top
Триггеры по лидам теряют смысл, когда MQL перестаёт быть центром вселенной
Раньше мы цепляли триггерные цепочки на каждый шаг от MQL до сделки и считали это воронкой. Но в модели RevOps (общая ответственность за выручку) эта логика ломается — sales и customer success теперь равноправные участники с бюджетом и KPI. Email-маркетолог перестаёт быть «генератором лидов» и превращается в «держателя коммуникации на всём жизненном цикле». Логика триггера *«скачал PDF — получи серию писем»* уступает *«клиент перешёл в этап квалификации — получай контент от CS»*. Меняется не только сценарий, а сама роль email в системе. Приходится переучивать и себя, и платформу рассылок.
— @EmailMarketingCraftPro
Раньше мы цепляли триггерные цепочки на каждый шаг от MQL до сделки и считали это воронкой. Но в модели RevOps (общая ответственность за выручку) эта логика ломается — sales и customer success теперь равноправные участники с бюджетом и KPI. Email-маркетолог перестаёт быть «генератором лидов» и превращается в «держателя коммуникации на всём жизненном цикле». Логика триггера *«скачал PDF — получи серию писем»* уступает *«клиент перешёл в этап квалификации — получай контент от CS»*. Меняется не только сценарий, а сама роль email в системе. Приходится переучивать и себя, и платформу рассылок.
— @EmailMarketingCraftPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Clickstar прекращает работу
Clickstar закрывается. Легендарная пуш-сеть прекращает закуп трафика с 1 августа, полная остановка — 20 августа.
Сетка работала почти 8 лет и была одним из лучших источников качественного трафика на Россию и СНГ. Сейчас пуш-трафик стал слишком ботовым из-за гугловских банов на скрипты сбора.
Что это означает для арбитражников — разбираемся в ста…
➡️ Читайте на сайте: https://aff.top/blog/clickstar-prekraschaet-rabotu
🧠 Ещё больше инсайтов → в канале AFF.top
Clickstar закрывается. Легендарная пуш-сеть прекращает закуп трафика с 1 августа, полная остановка — 20 августа.
Сетка работала почти 8 лет и была одним из лучших источников качественного трафика на Россию и СНГ. Сейчас пуш-трафик стал слишком ботовым из-за гугловских банов на скрипты сбора.
Что это означает для арбитражников — разбираемся в ста…
➡️ Читайте на сайте: https://aff.top/blog/clickstar-prekraschaet-rabotu
🧠 Ещё больше инсайтов → в канале AFF.top
Как автоматизация и AI помогают не терять лидов в CRM-цепочках
HubSpot делает ставку на автоматизацию маркетинга и AI в кампаниях: идея простая — не собирать всё руками, а запускать цепочки, которые сами подхватывают нужный контакт в нужный момент.
Задача здесь типовая для CRM-маркетолога: не дать базе «остыть» между событием и следующим касанием. Когда лид пришёл, открыл письмо, вернулся на сайт или не завершил действие, ручная отправка почти всегда запаздывает. В 2026 году это особенно заметно: у пользователя меньше терпения, а у команды — больше каналов и больше шума.
Что делает HubSpot:
— строит автоматизированные кампании;
— подключает AI, чтобы быстрее собирать и адаптировать коммуникации;
— переводит маркетинг из режима «отправить всем» в режим «показать нужное сообщение по триггеру».
Смысл не в том, чтобы просто экономить время. Автоматизация в email и lifecycle — это способ удержать контекст. Если человек уже проявил интерес, письмо должно прийти не «когда освободится маркетолог», а сразу после действия: регистрация, брошенный шаг, повторный визит, неактивность, переход в следующий этап воронки.
**Практический вывод для CRM-команды:** начните не с красивых рассылок, а с карты событий. Где контакт чаще всего теряется? Где ручные касания не успевают? Обычно именно там и лежит быстрый прирост эффективности: welcome-цепочка, триггер после просмотра продукта, реактивация, допродажа после покупки.
Урок простой: в email-маркетинге сейчас выигрывает не тот, кто делает больше отправок, а тот, кто лучше связывает событие, сегмент и следующий шаг. AI здесь полезен не как «магия», а как ускоритель — для сборки, вариаций и масштабирования уже продуманной логики.
— @EmailMarketingCraftPro
HubSpot делает ставку на автоматизацию маркетинга и AI в кампаниях: идея простая — не собирать всё руками, а запускать цепочки, которые сами подхватывают нужный контакт в нужный момент.
Задача здесь типовая для CRM-маркетолога: не дать базе «остыть» между событием и следующим касанием. Когда лид пришёл, открыл письмо, вернулся на сайт или не завершил действие, ручная отправка почти всегда запаздывает. В 2026 году это особенно заметно: у пользователя меньше терпения, а у команды — больше каналов и больше шума.
Что делает HubSpot:
— строит автоматизированные кампании;
— подключает AI, чтобы быстрее собирать и адаптировать коммуникации;
— переводит маркетинг из режима «отправить всем» в режим «показать нужное сообщение по триггеру».
Смысл не в том, чтобы просто экономить время. Автоматизация в email и lifecycle — это способ удержать контекст. Если человек уже проявил интерес, письмо должно прийти не «когда освободится маркетолог», а сразу после действия: регистрация, брошенный шаг, повторный визит, неактивность, переход в следующий этап воронки.
**Практический вывод для CRM-команды:** начните не с красивых рассылок, а с карты событий. Где контакт чаще всего теряется? Где ручные касания не успевают? Обычно именно там и лежит быстрый прирост эффективности: welcome-цепочка, триггер после просмотра продукта, реактивация, допродажа после покупки.
Урок простой: в email-маркетинге сейчас выигрывает не тот, кто делает больше отправок, а тот, кто лучше связывает событие, сегмент и следующий шаг. AI здесь полезен не как «магия», а как ускоритель — для сборки, вариаций и масштабирования уже продуманной логики.
— @EmailMarketingCraftPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Facebook запретил рекламу онлайн-казино Mr Vegas
Британский ASA запретил рекламу казино Mr Vegas из-за «слишком милых» мультяшных животных в креативах — регулятор счёл, что такой стиль привлекает детей, в том числе через Facebook. Рекламодатель запустил кампанию в феврале, бан вышел в июле. Логика регулятора вызывает вопросы: дети неплатёжеспособны, а таргетировать их на гемблинг бессмысленно.
➡️ Читайте на сайте: https://aff.top/blog/facebook-zapretil-reklamu-onlain-kazino-mr-vegas
🧠 Ещё больше инсайтов → в канале AFF.top
Британский ASA запретил рекламу казино Mr Vegas из-за «слишком милых» мультяшных животных в креативах — регулятор счёл, что такой стиль привлекает детей, в том числе через Facebook. Рекламодатель запустил кампанию в феврале, бан вышел в июле. Логика регулятора вызывает вопросы: дети неплатёжеспособны, а таргетировать их на гемблинг бессмысленно.
➡️ Читайте на сайте: https://aff.top/blog/facebook-zapretil-reklamu-onlain-kazino-mr-vegas
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
В Whatsapp скамят пользователей с помощью поддельных никнеймов
WhatsApp запустил никнеймы — и почти сразу начался скам. Мошенники регистрируют имена, похожие на бренды, звёзд и политиков, с минимальными опечатками.
Индия, где 500 млн пользователей WhatsApp, потребовала от Meta объяснений за 3 дня. Meta говорит, что точные совпадения заблокированы — но одна буква в другом месте защиту не триггерит.
Похоже, п…
➡️ Читайте на сайте: https://aff.top/blog/v-whatsapp-skamiat-polzovatelei-s-pomoschiu-poddelnykh-nikneimov
🧠 Ещё больше инсайтов → в канале AFF.top
WhatsApp запустил никнеймы — и почти сразу начался скам. Мошенники регистрируют имена, похожие на бренды, звёзд и политиков, с минимальными опечатками.
Индия, где 500 млн пользователей WhatsApp, потребовала от Meta объяснений за 3 дня. Meta говорит, что точные совпадения заблокированы — но одна буква в другом месте защиту не триггерит.
Похоже, п…
➡️ Читайте на сайте: https://aff.top/blog/v-whatsapp-skamiat-polzovatelei-s-pomoschiu-poddelnykh-nikneimov
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Вышел ZCode - аналог Claude code
Вышел ZCode — десктопный аналог Claude Code от разработчиков GLM-5.2. Работает с API от Anthropic, поддерживает SSH-деплой на сервер, в том числе Linux.
Вместо пошаговых скриптов — система целеполагания Goal: закидываешь сложный промт, агент сам разбивает задачу и выполняет. Плюс управление через Telegram-бота.
Но главная фича — мультиагентность…
➡️ Читайте на сайте: https://aff.top/blog/vyshel-zcode-analog-claude-code
🧠 Ещё больше инсайтов → в канале AFF.top
Вышел ZCode — десктопный аналог Claude Code от разработчиков GLM-5.2. Работает с API от Anthropic, поддерживает SSH-деплой на сервер, в том числе Linux.
Вместо пошаговых скриптов — система целеполагания Goal: закидываешь сложный промт, агент сам разбивает задачу и выполняет. Плюс управление через Telegram-бота.
Но главная фича — мультиагентность…
➡️ Читайте на сайте: https://aff.top/blog/vyshel-zcode-analog-claude-code
🧠 Ещё больше инсайтов → в канале AFF.top