Триггерные push-кампании: руководство по контекстным рабочим процессам

Наступила вторая неделя квартала, и ваша панель аналитики удержания показывает шесть активных «автоматизированных» триггеров, все в рабочем состоянии. Триггер брошенной корзины срабатывает для подписчиков, которые уже оплатили. Триггер возвращения клиента пересекается с оповещением о снижении цены для того же ушедшего клиента. Серия приветственных сообщений отправляет уведомления независимо от первого импульса к покупке. Запрос на отзыв после покупки поступает подписчикам, которые вчера вернули заказ.

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

Такова операционная реальность большинства систем удержания среднего бизнеса. Проблема не в стратегии. Стратегия в порядке. Проблема в архитектуре. Триггерное уведомление в 2024 году было одним сообщением, которое срабатывало по одному событию. В 2026 году этого примитива недостаточно. Путь должен запоминать, что сделал подписчик, разветвляться на основе этого и завершаться при конверсии.

Эта статья представляет архитектурное обоснование. Она определяет границу между широковещательными, триггерными и контекстными push-уведомлениями, рассматривает разницу между триггерами событий и триггерами аудитории, называет шесть типов узлов, которые превращают одиночный триггер в контекстный рабочий процесс, и предлагает три шаблона миграции, которые объединяют шесть автономных триггеров в три контекстных пути с общими критериями выхода и аналитикой по рабочему процессу.

Контекстные, триггерные, широковещательные: три примитива, а не один

Три примитива лежат в основе каждой программы push-уведомлений. Большинство команд объединяют их в одну категорию под названием «кампании», и именно здесь начинается архитектурная проблема.

Широковещательные. Одно и то же уведомление отправляется всей соответствующей аудитории по расписанию. Распродажа в полдень. Оповещение о новой коллекции в день запуска. Широковещательные сообщения — это правильный примитив для объявлений с ограниченным сроком действия, когда каждый получатель получает один и тот же полезный груз. Это неправильный примитив для всего, что зависит от состояния подписчика.

Триггерные. Одно уведомление срабатывает при срабатывании одного события. Подписчик бросает корзину, срабатывает уведомление о брошенной корзине. Подписчик просматривает страницу товара, срабатывает уведомление о просмотре. Подписчик совершает покупку, срабатывает уведомление после покупки. Триггер не имеет памяти. Он не знает, что произошло пять минут назад или что запланировано на следующий вторник. Каждый триггер — это конвейер, игнорирующий все остальные триггеры.

Контекстуальный. Рабочий процесс использует триггер как точку входа, а затем адаптируется к состоянию подписчика. Одно и то же событие брошенной корзины запускает многошаговое путешествие: часовое ожидание, первое напоминание, 24-часовое ожидание, решение, проверяющее, остается ли корзина открытой, второе напоминание со скидкой, 48-часовое ожидание, третье напоминание и правило выхода, которое отменяет рабочий процесс в тот момент, когда подписчик совершает покупку. Кампания — это рабочий процесс, а не триггер. Контекстуальные push-уведомления — это то, как работает триггерное сообщение, когда архитектура догоняет.

Три примитива четко соответствуют трем рабочим нагрузкам. Используйте эту таблицу при аудите вашего текущего стека.

Возможности	Рассылка	Триггерный	Контекстуальный
Состояние на подписчика	Нет	Нет	Да
Ветвление по поведению	Нет	Нет	Да
Критерии выхода	Нет	Нет	Да
Многоканальная маршрутизация в рамках одной кампании	Нет	Нет	Да
Встроенное A/B-тестирование (время отправки, текст, канал)	Нет	Нет	Да
Правильная рабочая нагрузка	Распродажи, анонсы запусков	Одноразовые транзакционные уведомления (низкий объем)	Путешествия по жизненному циклу (приветствие, брошенная корзина, возврат клиента, продление)

Большинству программ жизненного цикла требуется контекстуальность. Большинство команд используют триггеры. Этот разрыв — тема данной статьи. Рабочие процессы автоматизации маркетинга, которые реализуют контекстуальные путешествия, выглядят не как длинный список триггеров; они выглядят как небольшой набор многошаговых путешествий, составленных из общего словаря. Push-уведомления, которые вам действительно нужны, — это три контекстуальных путешествия, а не девять триггеров.

Триггеры событий и триггеры аудитории ведут себя очень по-разному

Прежде чем перейти к анатомии узлов, одно замечание по таксономии, которое почти каждая статья на эту тему делает неправильно. «Триггер» в рабочих процессах push-уведомлений — это не один примитив. Это два примитива, которые внешне выглядят одинаково, но ведут себя совершенно по-разному.

Событийные триггеры срабатывают для каждого подписчика при реальном событии. Поддерживаемые события в PushEngage Workflows включают PushEngage.Subscriber.Added, PushEngage.Subscriber.AddSegment, PushEngage.Subscriber.RemoveSegment, PushEngage.Subscriber.UpdateField, PushEngage.Subscriber.UpdateAttribute, PushEngage.Goal.Tracked и PushEngage.CustomEvent. Когда событие срабатывает, система оценивает активные рабочие процессы, проверяет критерии фильтра событий, проверяет правила выхода и ставит в очередь соответствующий рабочий процесс для этого подписчика. Разрыв между триггером и постановкой в очередь составляет секунды. Событийные триггеры — это правильный примитив для любой реактивной кампании: брошенная корзина, брошенный просмотр, последующие действия после покупки, приветствия при добавлении в сегмент. Push-кампании, запускаемые событиями, являются доминирующим случаем в электронной коммерции, онбординге SaaS и любой программе с сигналами в реальном времени.

Триггеры аудитории запускают фильтр в запланированное время. Фильтр выбирает подписчиков, соответствующих определенным критериям, таким как last_active > 30 days, loyalty_tier = gold или city = New York AND segments includes "vip". Планировщик извлекает соответствующие наборы подписчиков пакетами по 1000, распределяет выполнение на 15 секунд - 2 минуты и создает один экземпляр рабочего процесса для каждого подписчика. Триггеры аудитории — это правильный инструмент для повторного вовлечения, кампаний к дню рождения, географических акций и любых программ, где набор определяется атрибутом, а не событием.

Различия имеют значение с операционной точки зрения, а не только концептуальной:

Аспект	Триггер события	Триггер аудитории
Инициация	В реальном времени по событию подписчика	Запланировано через планировщик
Скорость	В течение нескольких секунд	Пакетная обработка, задержка 1-2 минуты
Выбор подписчика	Один подписчик на событие	Массовый выбор только в момент начала рабочего процесса
Новые подписчики после начала	Автоматически включаются при следующем событии	НЕ включаются автоматически после начала рабочего процесса
Изменение фильтра после начала	Н/П	Редактирование фильтра НЕ добавляет новых подписчиков
Данные события доступны	Да (для подстановки переменных)	Нет

Третья строка — это подвох. Рабочий процесс на основе аудитории выбирает набор подписчиков один раз, в начале рабочего процесса. Подписчики, которые становятся неактивными после начала рабочего процесса, не добавляются автоматически. Редактирование фильтра аудитории в активном рабочем процессе не привлекает новых кандидатов. Команда по удержанию, которая запускает рабочий процесс «вернись для подписчиков, неактивных более 30 дней» и запускает его на девяносто дней, будет видеть одну и ту же фиксированную когорту в течение всех девяноста дней, даже несмотря на то, что новые подписчики ежедневно пересекают 30-дневный порог.

Архитектурное решение заключается в дублировании рабочего процесса аудитории по расписанию, ежемесячно или еженедельно, чтобы каждая копия захватывала кандидатов, которые пересекли порог с момента последнего запуска. Это однострочное операционное примечание в документации и постоянный источник обращений в службу поддержки «почему этот подписчик не получил кампанию?» в командах, которые рассматривают триггеры аудитории как триггеры событий.

Шесть узлов, которые превращают триггер в контекстную кампанию

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

НАЧАЛО. Точка входа. Узел НАЧАЛО определяет триггер (на основе событий или аудитории) и критерии фильтрации. Рабочий процесс имеет ровно один узел НАЧАЛО. Точка входа определяет таксономию триггеров из предыдущего раздела и устанавливает контекст данных события, который могут считывать последующие узлы.

ОЖИДАНИЕ. Задержка. Узел WAIT удерживает подписчика в течение указанного периода времени (минуты, часы, дни) или до определенного времени в календаре. Ожидания позволяют рабочему процессу учитывать состояние подписчика и его часовой пояс. Рабочий процесс может ждать один час для напоминания о брошенной корзине, три дня для демонстрации функции в приветственной серии или до вторника 10 утра по местному времени подписчика для отправки в рабочее время. Ожидания также позволяют создавать многошаговую рассылку без отправки каждого сообщения в первые шестьдесят секунд.

РЕШЕНИЕ. Двустороннее ответвление. Узел DECISION проверяет фильтр событий или фильтр аудитории и направляет подписчика по пути ДА или по пути НЕТ. Совершил ли подписчик покупку? Находится ли он все еще в сегменте брошенных корзин? Изменился ли его уровень лояльности? Узлы Decision позволяют поведенческим push-уведомлениям перестать относиться ко всем подписчикам одинаково и начать адаптироваться к тому, что каждый подписчик фактически сделал. Поддерживаемые операторы включают: равно, не равно, в, не в, больше, меньше и существует, чего достаточно для выражения любой логики принятия решений, которая может понадобиться команде по удержанию клиентов.

РАЗДЕЛЕНИЕ_ПУТИ. Разделение на основе процентов для A/B-тестирования. Узел SPLIT_PATH направляет подписчиков по двум или более путям на основе настроенных процентов: 50/50 для двухстороннего теста, 33/33/34 для трехстороннего теста времени отправки, 90/10 для группы удержания. Система использует алгоритм балансировки нагрузки, который направляет каждого нового подписчика на наименее загруженный путь, что обеспечивает точность распределения даже при небольших размерах выборки. Как только тест достигнет статистической значимости, установите winner_edge_id, и рабочий процесс перенаправит 100% трафика на выигрышный вариант без перестройки рабочего процесса.

ДЕЙСТВИЕ. Сама работа. Узлы ACTION делают больше, чем просто отправляют push-уведомление. Workflows PushEngage поддерживает одиннадцать типов действий: SendPushNotification, AddSegment, RemoveSegment, UpdateField, UpdateAttribute, Update (комбинированное), HttpRequest, CustomEvent.Send, SendTriggerCampaignEvent, Workflow.Start и Workflow.Stop. Четыре наиболее распространенных в программах удержания: SendPushNotification, AddSegment (пометить подписчика как конвертированного, прошедшего онбординг или подверженного риску оттока), UpdateAttribute (увеличить счетчик лояльности или установить дату последней покупки) и HttpRequest (синхронизировать состояние с CRM, отправить оповещение в Slack для лида высокой ценности или вызвать нижестоящий сервис).

КОНЕЦ / ВЫХОД. Терминал. Узлы END и EXIT отмечают завершение рабочего процесса и обновляют аналитику. END — естественное завершение. EXIT обычно размещается на пути НЕТ решения, когда подписчик не проходит проверку, или на ответвлении, предназначенном для контрольной группы. Система также поддерживает критерии выхода на уровне рабочего процесса: audience_filter или trigger_event, которые отменяют активный рабочий процесс перед запуском каждого узла. Правило выхода срабатывает независимо от того, на каком узле в данный момент находится подписчик. Именно это останавливает срабатывание напоминаний рабочего процесса о брошенной корзине для подписчиков, которые уже совершили покупку.

Каждая контекстная кампания в этой статье состоит из этих шести частей. Шаблоны миграции ниже читаются быстро, как только словарь становится общим.

Три шаблона миграции: шесть автономных триггеров становятся тремя контекстными рабочими процессами

Большинство стеков удержания для среднего бизнеса имеют от четырех до восьми отдельных активных триггеров. Шаблон последователен: приветственное уведомление, подталкивание к первой покупке, брошенная корзина, брошенный просмотр, запрос отзыва после покупки, возврат, реактивация, потерянный VIP. Каждый из них является отдельным триггером со своим текстом, своим владельцем и своей аналитикой. Ни один из них не знает о других. Три одинаковых контекстных рабочих процесса могут принести тот же доход при одной трети занимаемого места.

Шаблон 1 — Консолидация онбординга

Объедините приветственную серию и подталкивание к первой покупке в один рабочий процесс с решением о статусе покупки.

• НАЧАЛО: Событие PushEngage.Subscriber.Added
• Тип запуска: Одиночный (90-дневная пауза после завершения)
• Поток: ЖДАТЬ 1 день → ДЕЙСТВИЕ отправить приветственное уведомление → ЖДАТЬ 3 дня → РЕШЕНИЕ: совершил ли подписчик покупку? → путь ДА: ДЕЙСТВИЕ отправить благодарность + ДЕЙСТВИЕ AddSegment в customers + КОНЕЦ → путь НЕТ: ДЕЙСТВИЕ отправить скидку 10% на первую покупку → ЖДАТЬ 4 дня → РЕШЕНИЕ: совершил ли подписчик покупку? → путь ДА: ДЕЙСТВИЕ отправить благодарность + КОНЕЦ → путь НЕТ: ДЕЙСТВИЕ отправить финальное подталкивание + КОНЕЦ
• Критерии выхода: Нет на уровне рабочего процесса; ветви решений обрабатывают конвертированного подписчика
• Заменяет: Триггер приветствия + триггер первой покупки (2 триггера → 1 рабочий процесс)

Общее состояние — это вся суть. Третье уведомление срабатывает только для подписчиков, которые не совершили конверсию к четвертому дню. Триггер первой покупки в старой архитектуре срабатывал для каждого нового подписчика, включая тех, кто совершил покупку в своей первой сессии. Рабочий процесс перестает их беспокоить.

Шаблон 2 — Цепочка «от корзины до отзыва»

Объедините восстановление после брошенной корзины и запрос отзыва после покупки в один рабочий процесс с передачей управления по цепочке рабочих процессов.

• НАЧАЛО: Пользовательское событие cart_abandoned
• Тип запуска: Множественный параллельный (каждая брошенная корзина — это свой экземпляр)
• Поток: ЖДАТЬ 1 час → ДЕЙСТВИЕ напоминание №1 → ЖДАТЬ 24 часа → РЕШЕНИЕ: корзина все еще брошена? → путь ДА: ДЕЙСТВИЕ напоминание №2 со скидкой 10% → ЖДАТЬ 48 часов → РЕШЕНИЕ: корзина все еще брошена? → путь ДА: ДЕЙСТВИЕ финальное напоминание со скидкой 20% → КОНЕЦ
• Критерии выхода (уровень рабочего процесса): Goal.Tracked = purchase совпадает с cart_id из триггерного события. В момент покупки подписчиком рабочий процесс отменяется.
• Передача: При выходе из-за покупки система запускает PushEngage.Workflow.Start, нацеленный на рабочий процесс запроса отзыва. Рабочий процесс отзыва запускается только для подписчиков, которые фактически совершили покупку. Путь выхода из-за непокупки полностью пропускает передачу.
• Заменяет: Триггер корзины + триггер пост-покупки + тикет поддержки от запросов на отзыв, попадающий к подписчикам, которые никогда не покупали (3 проблемы → 1 рабочий процесс)

Связывание через Workflow.Start — это архитектурное решение для прогрессии жизненного цикла. Вместо того чтобы два триггера срабатывали независимо и пересекались на одних и тех же подписчиках, выход из рабочего процесса корзины при покупке запускает рабочий процесс отзыва. Отзыв срабатывает только для конвертированных подписчиков. Корзина никогда не срабатывает после конверсии. Передача обеспечивается движком.

Шаблон 3 — Консолидация повторного вовлечения

Объедините кампании win-back, реактивации и lapsed-VIP в один рабочий процесс с триггером аудитории и тремя ветвями принятия решений.

• НАЧАЛО: Фильтр аудитории last_active > 30 days
• Тип выполнения: Одиночный (одна попытка повторного вовлечения на подписчика за 90-дневный период)
• Поток: РЕШЕНИЕ: уровень лояльности? → Ветка Gold: ДЕЙСТВИЕ отправить «мы скучаем, VIP» с предложением 20% → Ветка Silver: ДЕЙСТВИЕ отправить «мы скучаем» с предложением 10% → Ветка без уровня: ДЕЙСТВИЕ отправить стандартное «мы скучаем» с предложением бесплатной доставки → ЖДАТЬ 5 дней → РЕШЕНИЕ (по ветке): подписчик взаимодействовал или посетил сайт? → Путь ДА: ДЕЙСТВИЕ AddSegment в re-engaged + КОНЕЦ → Путь НЕТ: ДЕЙСТВИЕ отправить «последний шанс» с более выгодным предложением + КОНЕЦ
• Критерии выхода (уровень рабочего процесса): Фильтр аудитории last_active < 7 days. Подписчик стал активным самостоятельно, и работа рабочего процесса завершена.
• Заменяет: Триггер win-back + триггер реактивации + триггер lapsed-VIP (3 триггера → 1 рабочий процесс)
• Операционная заметка: Согласно подводному камню триггера аудитории в предыдущем разделе, этот рабочий процесс не включает автоматически подписчиков, которые пересекают 30-дневный порог после запуска рабочего процесса. Дублируйте рабочий процесс ежемесячно, чтобы каждая копия захватывала новых кандидатов. Один длительно работающий рабочий процесс аудитории здесь является неправильным примитивом.

После этих трех миграций команда удержания управляет тремя контекстуальными путешествиями вместо шести (или восьми) отдельных триггеров. Общий объем push-сообщений остается примерно тем же. Избыточное сообщение исчезает, потому что общие критерии выхода и ветви принятия решений останавливают рабочий процесс, когда состояние подписчика больше не соответствует. Аналитика фрагментируется с «шести панелей мониторинга, которые я не могу согласовать» до «трех воронков, которые я могу защитить». Так выглядят push-кампании, запускаемые событиями, когда они взрослеют.

Что контекстные рабочие процессы делают, а автономные триггеры не могут

Четыре возможности существуют внутри контекстного рабочего процесса и не могут быть скомпонованы между автономными триггерами. Каждая из них является реальным источником дохода или экономии.

Критерии выхода между рабочими процессами. Автономный триггер срабатывает при возникновении события, и точка. Внутри рабочего процесса правило выхода срабатывает независимо от того, на каком узле находится подписчик. Рабочий процесс отказа от корзины завершается при покупке. Рабочий процесс возврата клиента завершается при повторной активации. Рабочий процесс продления завершается при досрочном продлении. Триггер, которому никто не сказал остановиться, — это рабочий процесс, определяющий правило выхода.

Многоканальная маршрутизация в одном рабочем процессе. С отдельными одноканальными инструментами «отправить веб-push, перейти к электронной почте, эскалировать до WhatsApp» требуется три входа для поставщика, два механизма сегментации и как минимум один поток Zapier. Внутри одного движка рабочего процесса это три узла ACTION с двумя узлами DECISION между ними, совместно использующие одну идентификацию подписчика и один набор критериев выхода. Для более подробного рассмотрения см. публикацию по оркестрации многоканальных push-уведомлений и электронной почты.

Тихие часы с резервным вариантом reschedule. Push-уведомления, которые должны были быть доставлены в 3 часа ночи по местному времени подписчика, будут задержаны до 8:01, если для тихих часов настроен reschedule в качестве резервного варианта. Альтернатива, skip, молча отбрасывает уведомление и не обновляет аналитику уведомлений для пропущенного действия. Для большинства команд по удержанию клиентов reschedule является правильным значением по умолчанию, поскольку пропущенная аналитика означает упущенную атрибуцию дохода. Контекстные push-уведомления, которые команда по удержанию клиентов действительно хочет отправлять, учитывают часовые пояса подписчиков, не исчезая из воронки.

Цепочка рабочих процессов. Действия Workflow.Start и Workflow.Stop делают прогрессию жизненного цикла реальной архитектурой. Завершается рабочий процесс приветствия, который запускает рабочий процесс взаимодействия. Рабочий процесс корзины завершается при покупке, что запускает рабочий процесс обзора. По сравнению с папкой триггеров, которые срабатывают независимо, это конечный автомат: граф рабочих процессов, каждый со своим условием входа, условием выхода и передачей на следующий этап. Триггеры не знают друг о друге. Рабочие процессы знают.

Аналитика по рабочему процессу: как читать воронку

Рабочий процесс, который вы не сможете защитить на следующем обзоре P&L, — это рабочий процесс, который будет закрыт. PushEngage Workflows отслеживает три показателя на каждом узле (queued_users, completed_users, exited_users) плюс общее количество для всего рабочего процесса: общее количество вошедших, активных в данный момент, завершенных и вышедших. Задача менеджера по удержанию клиентов — прочитать эту воронку и сообщить финансовому отделу, что произвела каждая строка.

Вот как выглядит аналитика на уровне узлов для цепочки «от корзины к обзору» из Шаблона 2 выше. Иллюстративные цифры, взятые из реалистичного списка из 200 000 подписчиков с ежемесячным показателем отказа от корзины 6%.

Узел	В очереди	Завершено	Выбыло	Примечания
НАЧАЛО (cart_abandoned)	0	12,400	320	320 подписчиков соответствовали критериям выхода при запуске рабочего процесса (совершили покупку между событием корзины и сканированием рабочего процесса)
WAIT 1 час	180	11,900	320	Нормальная глубина очереди
ДЕЙСТВИЕ: напоминание №1	0	11,900	0	Отправлено
ПОДОЖДАТЬ 24 часа	240	9,800	1,860	1 860 подписчиков совершили покупку после напоминания № 1 (выход по цели purchase)
РЕШЕНИЕ: корзина все еще брошена	0	9,800	0	Ветвь оценена
ДЕЙСТВИЕ: напоминание №2 (10%)	0	9,800	0	Отправлено
ОЖИДАНИЕ 48 часов	90	6,300	3,410	3 410 подписчиков совершили покупку после напоминания №2
ДЕЙСТВИЕ: финальное напоминание (20%)	0	6,300	0	Отправлено
КОНЕЦ	н/д	6,300	н/д	6 300 подписчиков не купили; рабочий процесс проверки не связан для них
Workflow.Start → рабочий процесс проверки	н/д	5,270	н/д	Сработало для 5 270 подписчиков (1 860 + 3 410), которые совершили покупку

5 270 последовательных передач — это новая метрика, которую предоставляет эта архитектура. Рабочий процесс корзины восстановил показатель корзины в 42,5% (5 270 из 12 400 вошли) и только эти 5 270 подписчиков получают рабочий процесс запроса на отзыв. Старая архитектура отправляла запрос на отзыв всем, кто когда-либо совершал покупку, включая подписчиков, которые никогда не бросали корзину, подписчиков, которые вернули заказ, и подписчиков, которые уже отправили отзыв. Исправление архитектуры незначительно. Экономия на чрезмерной рассылке велика.

Стоит знать два паттерна узких мест. Узел с высоким выходом (например, два узла WAIT выше) — это рабочий процесс, выполняющий свою работу: подписчики покупают во время окон ожидания, срабатывают критерии выхода, следующее напоминание никогда не отправляется. Обратный паттерн, высокие выходы на узлах действий в сочетании с низкими выходами на узлах ожидания, означает, что время выбрано неправильно, и ожидания следует сократить. Узел с высокой очередью означает задержку в часы тишины, долгое ожидание или задержку последующего опросника; проверьте настройки времени, прежде чем предполагать, что рабочий процесс сломан.

Для более глубокой обработки этих паттернов, специфичных для электронной коммерции, в сопутствующей статье о пяти рабочих процессах push-уведомлений для электронной коммерции рассматриваются корзина, просмотр, после покупки, приветствие и возврат как отдельные пути. Центр push-уведомлений для электронной коммерции охватывает более широкий спектр типов кампаний, последовательность восстановления брошенных корзин рассматривает настройку частоты для каждой платформы, а обзор автоматических push-уведомлений представляет старый список типов автоматизации наряду с этой архитектурой рабочего процесса.

Та же аналитическая модель работает во всех отраслях. SaaS имеет воронку продления и конверсию из пробной версии в платную. Издатели имеют воронку вовлеченности в статьи и повторный вход в архив. Путешествия имеют воронку бронирования и поток уведомлений о снижении цен. Поведенческие push-уведомления, которые команда SaaS использует для стимулирования перехода от пробной версии к платной, структурно идентичны тем, которые команда электронной коммерции использует для стимулирования перехода от корзины к покупке: один START по событию в реальном времени, три или четыре шага с ветвями решений, критерии выхода по конверсии, необязательная передача следующему рабочему процессу. Отрасль меняет названия триггеров и текст предложения. Архитектура остается.

Создайте это в PushEngage Workflows

Каждый из трех паттернов миграции выше напрямую соответствует компонентам PushEngage Workflows.

Паттерн	Используемые типы узлов	Типы используемых действий	Параметр рабочего процесса	Предлагаемая отправная точка шаблона
Консолидация онбординга	НАЧАЛО, ОЖИДАНИЕ, РЕШЕНИЕ, ДЕЙСТВИЕ, КОНЕЦ	SendPushNotification, AddSegment	Тип запуска: Одиночный	«Серия приветствий с веткой первой покупки»
Цепочка «от корзины к отзыву»	НАЧАЛО, ОЖИДАНИЕ, РЕШЕНИЕ, ДЕЙСТВИЕ, КОНЕЦ	SendPushNotification, Workflow.Start	Тип выполнения: Несколько параллельных; критерий выхода Goal.Tracked = purchase	«Эскалация брошенной корзины»
Консолидация повторного вовлечения	START (аудитория), DECISION, ACTION, WAIT, END	SendPushNotification, AddSegment	Тип выполнения: Одиночный; триггер аудитории; дублировать ежемесячно	«Повторное вовлечение с предложением по уровням»

Движок Workflows поставляется с 60+ готовыми шаблонами, охватывающими каждый из вышеперечисленных шаблонов миграции. Каждый шаблон — это отправная точка. Шаблоны устанавливаются менее чем за пять минут на Shopify, Shopify Plus, WooCommerce, BigCommerce и Magento внутри конструктора PushEngage Workflows, или на любом SaaS, издателе или туристическом стеке через JavaScript SDK и API событий.

Бесплатный план предоставляет вам 200 подписчиков, все каналы (веб-пуш, апп-пуш, WhatsApp и живой чат), а также полный движок Workflows с первого дня. Этого достаточно, чтобы перенести один из трех шаблонов из вашего текущего стека триггеров и доказать архитектуру перед запросом бюджета. Начните с бесплатного плана и запустите первый контекстный рабочий процесс менее чем за час.

Если вы вынесете из этой статьи что-то одно, то вот что: триггерная push-кампания — это больше не уведомление. Это рабочий процесс. Шесть отдельных триггеров, работающих изолированно, — это шесть конвейеров, нацеленных на один и тот же список подписчиков, каждый из которых не осведомлен о других.

Три контекстных рабочих процесса, работающих с общим состоянием, ветвями принятия решений, критериями выхода и последовательными передачами, — это одно путешествие на подписчика, разветвленное и ограниченное. Маркетинговые автоматизированные рабочие процессы, которые создают защищаемую воронку для каждого рабочего процесса и коэффициент повторных покупок, который накапливается, — это не более длинный список триггеров; это меньший, более четкий набор контекстных путешествий. Архитектура — это кампания. Триггер — это дверь.