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

It is the second week of the quarter and your retention dashboard shows six “automated” triggers running, all green. The cart-abandonment trigger keeps firing at subscribers who already paid. The win-back overlaps with the price-drop alert for the same lapsed customer. The welcome series ships notifications independently of the first-purchase nudge. The post-purchase review request lands on subscribers who returned the order yesterday.

Each of the six triggered push campaigns is a pipeline pointing at the same subscriber list, each pretending the other five do not exist. The repeat-purchase rate stopped moving twelve months ago and nobody on the team can attribute revenue per trigger because the triggers do not share state.

This is the operational reality in most mid-market retention stacks. The problem is not strategy. The strategy is fine. The problem is architecture. A triggered notification in 2024 was a single message that fired on a single event. In 2026, that primitive is not enough. The journey has to remember what the subscriber did, branch on it, and exit when they convert.

This article makes the architectural case. It defines the boundary between broadcast, triggered, and contextual push notifications, walks through the difference between event triggers and audience triggers, names the six node types that turn a single trigger into a contextual workflow, and ships three migration patterns that consolidate six standalone triggers into three contextual journeys with shared exit criteria and per-workflow analytics.

Contextual, triggered, broadcast: three primitives, not one

Three primitives sit underneath every push notification program. Most teams collapse them into one bucket called “campaigns,” which is where the architecture problem starts.

Broadcast. The same notification goes to the entire matching audience, scheduled. Flash sale at noon. New collection alert on launch day. Broadcast is the right primitive for time-bounded announcements where every recipient gets the same payload. It is the wrong primitive for anything that depends on subscriber state.

Triggered. A single notification fires when a single event fires. Subscriber abandons a cart, the cart-abandonment notification fires. Subscriber views a product page, the browse notification fires. Subscriber purchases, the post-purchase notification fires. The trigger has no memory. It does not know what happened five minutes ago or what is scheduled for next Tuesday. Each trigger is a pipeline ignorant of every other trigger.

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

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

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

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

Event triggers and audience triggers behave very differently

Прежде чем перейти к анатомии узлов, одно замечание по таксономии, которое почти каждая статья на эту тему делает неправильно. «Триггер» в рабочих процессах 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-дневный порог.

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

The six nodes that turn a trigger into a contextual campaign

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

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

ОЖИДАНИЕ. Задержка. Узел 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. The terminal. END and EXIT nodes mark the workflow complete and update analytics. END is the natural conclusion. EXIT is typically placed on the NO path of a decision when the subscriber does not qualify, or on a split-path branch designed as a control group. The system also supports workflow-level exit criteria: an audience_filter or trigger_event that cancels the active workflow before each node runs. The exit rule fires regardless of which node the subscriber currently sits at. This is what stops the cart-abandonment workflow from firing reminders to subscribers who already bought.

Every contextual campaign in this article is composed from these six pieces. The migration patterns below read fast once the vocabulary is shared.

Three migration patterns: six standalone triggers become three contextual workflows

Most mid-market retention stacks have between four and eight standalone triggers running. The pattern is consistent: welcome notification, first-purchase nudge, cart abandonment, browse abandonment, post-purchase review request, win-back, reactivation, lapsed-VIP. Each of these is a separate trigger with its own copy, its own owner, and its own analytics. None of them know about each other. The same three contextual workflows can ship the same revenue with one-third the surface area.

Pattern 1 — Onboarding consolidation

Collapse the welcome series and the first-purchase nudge into one workflow with a decision on purchase status.

• START: Event PushEngage.Subscriber.Added
• Run type: Single (90-day cooldown after completion)
• Flow: WAIT 1 day → ACTION send welcome notification → WAIT 3 days → DECISION: has the subscriber purchased? → YES path: ACTION send thank-you + ACTION AddSegment to customers + END → NO path: ACTION send first-purchase 10% discount → WAIT 4 days → DECISION: has the subscriber purchased? → YES path: ACTION send thank-you + END → NO path: ACTION send final nudge + END
• Exit criteria: None at workflow level; the decision branches handle the converted subscriber
• Replaces: Welcome trigger + first-purchase trigger (2 triggers → 1 workflow)

The shared state is the entire point. The third notification only fires for subscribers who have not converted by day four. The first-purchase trigger in the old architecture fired for every new subscriber, including the ones who bought in their first session. The workflow stops bothering them.

Pattern 2 — Cart-to-review chain

Collapse cart-abandonment recovery and post-purchase review request into one workflow with a workflow-chaining handoff.

• START: Custom event cart_abandoned
• Run type: Multiple Parallel (each abandoned cart is its own instance)
• Flow: WAIT 1 hour → ACTION reminder #1 → WAIT 24 hours → DECISION: cart still abandoned? → YES path: ACTION reminder #2 with 10% → WAIT 48 hours → DECISION: cart still abandoned? → YES path: ACTION final reminder with 20% → END
• Критерии выхода (уровень рабочего процесса): Goal.Tracked = purchase совпадает с cart_id из триггерного события. В момент покупки подписчиком рабочий процесс отменяется.
• Передача: При выходе из-за покупки система запускает PushEngage.Workflow.Start, нацеленный на рабочий процесс запроса отзыва. Рабочий процесс отзыва запускается только для подписчиков, которые фактически совершили покупку. Путь выхода из-за непокупки полностью пропускает передачу.
• Заменяет: Триггер корзины + триггер пост-покупки + тикет поддержки от запросов на отзыв, попадающий к подписчикам, которые никогда не покупали (3 проблемы → 1 рабочий процесс)

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

Pattern 3 — Re-engagement consolidation

Объедините кампании 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-кампании, запускаемые событиями, когда они взрослеют.

What contextual workflows do that standalone triggers cannot

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

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

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

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

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

Per-workflow analytics: how to read the funnel

Рабочий процесс, который вы не сможете защитить на следующем обзоре 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 с первого дня. Этого достаточно, чтобы перенести один из трех шаблонов из вашего текущего стека триггеров и доказать архитектуру перед запросом бюджета. Начните с бесплатного плана и запустите первый контекстный рабочий процесс менее чем за час.

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

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