Автоматизация push-уведомлений для eCommerce: 5 шаблонов рабочих процессов

Наступила третья пятница квартала, и вы смотрите на свою панель мониторинга удержания клиентов. Работает последовательность уведомлений о брошенных корзинах. Работает триггер уведомлений о просмотренных товарах. Работает запрос на отзыв после покупки. Работает уведомление о снижении цены. При каждой регистрации отправляются приветственные уведомления. Шесть «автоматизированных» push-уведомлений. Шесть триггеров, настроенных за последние восемнадцать месяцев. Ваш коэффициент повторных покупок перестал расти двенадцать месяцев назад.

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

Автоматизация push-уведомлений для электронной коммерции не должна работать так. Она должна работать как единая архитектура рабочего процесса: набор многоузловых путешествий с общими триггерами, общей логикой принятия решений и общими критериями выхода, работающих через веб-push, app-push, WhatsApp и live chat с единой идентификацией подписчика. Эта статья подробно описывает, как выглядит эта архитектура, предоставляет пять полных шаблонов рабочих процессов, которые вы можете использовать, и показывает, как читать воронку по каждому рабочему процессу, чтобы этот пункт можно было обосновать перед финансовым отделом.

Большинство «автоматизированных push-уведомлений» на самом деле не автоматизированы

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

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

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

Для команды по удержанию клиентов в сегменте среднего бизнеса это различие — разница между показателем повторных покупок, который растет экспоненциально, и показателем, который стагнирует. Шесть триггеров, работающих параллельно, создают шесть каналов шума. Пять рабочих процессов, работающих согласованно, создают одно путешествие для каждого подписчика, разветвленное и ограниченное. Большинство результатов поиска на первой странице по этому ключевому слову формулируют проблему как «какие уведомления отправлять» и отвечают списком из девяти, двенадцати или пятнадцати шаблонов. Это не тот вопрос. Вопрос в том, как составить путешествие.

Анатомия рабочего процесса push-уведомлений

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

START. Точка входа. Узел START определяет, как запускается рабочий процесс: либо событием подписчика (брошенная корзина, просмотренная страница, присоединение к сегменту, отслеживаемая цель покупки), либо фильтром аудитории, который выбирает подписчиков, соответствующих определенным критериям, в запланированное время. Рабочий процесс имеет ровно один START.

WAIT. Задержка. Узел WAIT удерживает подписчика в этой точке на указанное время (минуты, часы, дни) или до определенного календарного времени (вторник 10:00 по часовому поясу подписчика, 15 декабря 20:00 по времени сайта). Задержки позволяют рабочему процессу не быть разовой рассылкой.

DECISION. Двустороннее ветвление. Узел DECISION проверяет условие (совершил ли подписчик покупку, находится ли он все еще в сегменте бросивших корзину, имеет ли его уровень лояльности «золотой») и направляет его по пути ДА или по пути НЕТ. Решения позволяют рабочему процессу перестать относиться ко всем подписчикам одинаково.

SPLIT_PATH. Разветвление на основе процентов. Узлы SPLIT_PATH направляют подписчиков по нескольким путям на основе настроенных процентов: 50/50 для A/B-тестирования, 33/33/34 для трехстороннего тестирования времени отправки. Как только у вас появится победитель, вы переведете выигрышный путь на 100%, и рабочий процесс продолжит работать на проверенном варианте.

ACTION. Сама работа. Узлы ACTION отправляют push-уведомление, добавляют подписчика в сегмент, обновляют его атрибуты, запускают вебхук, запускают другой рабочий процесс или останавливают его. PushEngage Workflows поддерживает одиннадцать типов действий. Наиболее распространенными в электронной коммерции являются SendPushNotification, AddSegment, UpdateAttribute и HttpRequest.

END / EXIT. Терминал. Узлы END и EXIT завершают рабочий процесс и обновляют аналитику. END — это естественное завершение. EXIT обычно используется для досрочного завершения: по пути НЕТ узла Decision, когда подписчик не соответствует требованиям, или по ветке Split Path, предназначенной в качестве контрольной группы.

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

Пять шаблонов рабочих процессов для электронной коммерции

Это не «примеры». Это рабочие шаблоны. Каждый из них перечисляет триггер, тип запуска, последовательность узлов, критерии выхода и предполагаемую метрику удержания. Вы можете напрямую загрузить каждый из них в конструктор PushEngage Workflows, и он будет работать менее чем за час.

Шаблон 1 — Приветственная серия

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

Шаблон 2 — Брошенное просматривание

• Триггер (НАЧАЛО): Пользовательское событие page_view, отфильтрованное по страницам с деталями продукта, где подписчик не инициировал add_to_cart в течение 30 минут
• Тип запуска: Несколько параллельных (подписчик может просмотреть и бросить несколько продуктов за сеанс, и каждый из них получает свой экземпляр рабочего процесса)
• Поток: ЖДАТЬ 30 минут → РЕШЕНИЕ: все еще просматривает ли подписчик сайт? → Путь ДА: ВЫЙТИ (не прерывать активный сеанс) → Путь НЕТ: отправить напоминание с просмотренным продуктом → ЖДАТЬ 24 часа → РЕШЕНИЕ: добавил ли он в корзину? → Путь ДА: ВЫЙТИ (рабочий процесс брошенной корзины берет на себя дальнейшие действия) → Путь НЕТ: отправить второе касание с рекомендацией сопутствующих товаров → КОНЕЦ
• Критерии выхода: Цель add_to_cart (рабочий процесс корзины наследует путешествие) или цель purchase (дальнейшие сообщения не требуются)
• Метрика удержания: Коэффициент конверсии из просмотра в корзину для ранее просмотренных продуктов. В посте PushEngage о кампаниях по брошенному просмотру рассматривается работа с сегментацией, которую наследует этот шаблон.

Шаблон 3 — Эскалация брошенной корзины

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

Blueprint 4 — Запрос отзыва после покупки

• Триггер (НАЧАЛО): Событие PushEngage.Goal.Tracked, где goal_name = purchase
• Тип выполнения: Несколько последовательных (одно активное путешествие по запросу отзыва за раз для подписчика, но следующая покупка запускает новый экземпляр)
• Поток: ЖДАТЬ 7 дней (достаточно, чтобы получить продукт и сформировать мнение) → РАЗДЕЛИТЬ_ПУТЬ 50/50: утреннее отправление (9:00 по местному времени подписчика) против вечернего отправления (19:00 по местному времени подписчика) → уведомление с запросом отзыва → ДЕЙСТВИЕ: HTTP-запрос в CRM для регистрации отправки запроса отзыва → КОНЕЦ
• Тихие часы: с 22:00 до 8:00 по часовому поясу подписчика, резервное значение reschedule. Push-уведомления, которые должны были быть отправлены ночью, ждут до 8:01, а не отправляются. Настройка reschedule является правильной по умолчанию для этого рабочего процесса, поскольку skip бесшумно пропускает уведомления и исключает их из аналитики, чего большинство команд по удержанию клиентов не хотят.
• Критерии выхода: Цель review_submitted
• Метрика удержания: Коэффициент отправки отзывов по вариантам времени отправки. Разделение пути делает A/B-тестирование частью рабочего процесса, а не дополнением к отчету кампании.

Blueprint 5 — Возврат клиентов

• Триггер (НАЧАЛО): Фильтр аудитории last_active > 30 days
• Тип запуска: Однократный (одна попытка вернуть пользователя в течение 90-дневного периода)
• Поток: уведомление «Мы скучаем» → ЖДАТЬ 3 дня → РЕШЕНИЕ: взаимодействовал ли подписчик с уведомлением или посетил сайт? → путь ДА: добавить в сегмент re-engaged, отправить благодарность и скидку, КОНЕЦ → путь НЕТ: отправить более сильное предложение с большей скидкой → ЖДАТЬ 5 дней → РЕШЕНИЕ: все еще неактивен? → путь ДА: финальное уведомление «последний шанс» → КОНЕЦ
• Критерии выхода: Фильтр аудитории last_active < 7 days. Подписчик стал активным самостоятельно, и работа рабочего процесса завершена.
• Метрика удержания: Коэффициент реактивации через 60 дней после входа в рабочий процесс.

Несколько слов о триггере. Это единственный шаблон в данной статье, который использует триггер, основанный на аудитории, а не на событии. Триггеры аудитории в PushEngage Workflows обрабатывают соответствующий набор подписчиков пакетно только в момент запуска рабочего процесса. Подписчики, которые становятся неактивными после запуска рабочего процесса, не включаются автоматически, а редактирование фильтра аудитории в активном рабочем процессе не добавляет новых подписчиков. Если вам нужна программа повторного вовлечения, дублируйте рабочий процесс по расписанию (ежемесячно или ежеквартально), а не ожидайте, что один длительный рабочий процесс аудитории будет постоянно принимать новых кандидатов. Это реальный источник обращений в службу поддержки типа «почему этот подписчик не получил возврат?», когда команды неправильно понимают тип триггера.

Сегментация, A/B-тестирование и критерии выхода находятся внутри рабочего процесса

Доминирующий шаблон в результатах поиска на первой странице по этому ключевому слову — перечисление сегментации, A/B-тестирования и тихих часов как «лучших практик»: общие пункты в конце статьи, оторванные от кампании, которая их использует. Это неправильный подход. Это не лучшие практики, которые находятся рядом с рабочим процессом. Это и есть рабочий процесс.

Вот тот же набор концепций, представленных как лучшие практики и как узлы рабочего процесса:

Концепция	Формулировка лучших практик (неправильно)	Формулировка узлов рабочего процесса (правильно)
RFM-сегментация	«Сегментируйте свой список перед отправкой»	Узел РЕШЕНИЕ, который проверяет давность, частоту и сумму покупок, а затем направляет подписчиков с высоким RFM по другому пути, чем подписчиков с низким RFM. В посте PushEngage о сегментации описаны определения RFM-групп, которые используются этим узлом.
A/B тестирование	«Всегда A/B-тестируйте свой текст»	Узел РАЗДЕЛЕНИЕ_ПУТИ с процентным распределением 50/50, сбалансированной нагрузкой подписчиков по каждому пути и полем winner_edge_id, которое продвигает победителя до 100%, как только тест достигнет значимости
Тихие часы	«Не отправлять в 3 часа ночи»	Параметр на уровне рабочего процесса с start_at, end_at, timezone и настройкой fallback, которая либо skip (пропускает) отправку, либо reschedule (переносит) ее на одну минуту после окончания тихих часов
Критерии выхода	«Прекратите отправлять тем, кто купил»	Правило на уровне рабочего процесса, которое проверяет подписчика по фильтру аудитории или по триггерной цели перед каждым узлом и отменяет рабочий процесс, если совпадение найдено.

Разница имеет значение, потому что лучшие практики легко принять к сведению, но трудно применить. Узлы рабочего процесса обеспечиваются самим движком. РЕШЕНИЕ выполняется каждый раз. РАЗДЕЛЕНИЕ_ПУТИ балансирует каждого подписчика. Отступление в тихие часы срабатывает без необходимости кому-либо помнить о времени. Правило выхода отменяет рабочий процесс независимо от того, обращает ли владелец кампании на это внимание.

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

Многоканальная оркестровка: один рабочий процесс, четыре канала

Большинство платформ push-уведомлений — это одноканальные инструменты. Некоторые — двухканальные. Вопрос, на который они не могут дать хороший ответ, но который действительно нужно решить команде по удержанию клиентов среднего бизнеса: учитывая состояние подписчика, какой канал должен сработать? Веб-пуш, если он подписался. Электронная почта, если он отписался от веб-пушей. WhatsApp, если стоимость корзины превышает 200 долларов. Live-чат, если подписчик в данный момент находится на сайте.

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

• НАЧАЛО: событие cart_abandoned
• ОЖИДАНИЕ: 1 час
• УЗЕЛ РЕШЕНИЯ 1: подписан ли подписчик на веб-push?
  • Путь ДА: ДЕЙСТВИЕ, отправить напоминание по веб-push
  • Путь НЕТ: перейти к следующему решению
• ОЖИДАНИЕ: 30 минут после веб-push (или немедленно, если push не был отправлен)
• УЗЕЛ РЕШЕНИЯ 2: нажал ли подписчик на веб-push, или не подписан на веб-push?
  • Если веб-push был отправлен и на него нажали: ВЫХОД (позволить процессу корзины завершиться)
  • Если веб-push был отправлен и на него не нажали, или веб-push не был отправлен: продолжить
• УЗЕЛ РЕШЕНИЯ 3: стоимость корзины больше 200 долларов?
  • Путь ДА: ДЕЙСТВИЕ, отправить сообщение WhatsApp через действие SendPushNotification в канале WhatsApp
  • Путь НЕТ: ДЕЙСТВИЕ, отправить email через HTTP-запрос к вашему ESP
• ВЫХОД по цели purchase

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

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

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

Математика удержания: доход на рабочий процесс, на канал, на уведомление

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

Рабочие процессы PushEngage отслеживают три показателя в каждом узле:

• Пользователи в очереди: подписчики, ожидающие в данный момент на этом узле (обычно это ожидание или перенос на часы тишины)
• Завершенные пользователи: подписчики, прошедшие через этот узел
• Выбывшие пользователи: подписчики, покинувшие рабочий процесс на этом узле, либо потому, что критерии выхода совпали, либо потому, что они отписались

Вот как выглядят аналитические данные на уровне узлов для активного рабочего процесса отмены корзины (иллюстративные цифры, взятые из реалистичного списка из 200 000 подписчиков):

Узел	В очереди	Завершено	Выбыло	Примечания
НАЧАЛО (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
РЕШЕНИЕ: корзина все еще брошена	0	9,800	0	Все оставшиеся подписчики все еще имеют открытую корзину
ДЕЙСТВИЕ: напоминание №2 (скидка 10%)	0	9,800	0	Уведомление отправлено со скидкой
ОЖИДАНИЕ 48 часов	90	6,300	3,410	Еще 3 410 покупок привели к выходу
ДЕЙСТВИЕ: последнее напоминание (скидка 20%)	0	6,300	0	Финальное уведомление
КОНЕЦ	н/д	6,300	н/д	6 300 подписчиков не купили

В этой воронке 5 270 подписчиков (1 860 + 3 410) совершили покупку во время работы цепочки, что составляет 42,5% восстановленных корзин. Два ожидания (24 часа и 48 часов) являются узлами с наибольшим количеством выходов из воронки, что является ожидаемой закономерностью: решения о времени покупки принимаются в окнах ожидания, а не в окнах действий. Если ваша цепочка показывает обратную закономерность, с большим количеством выходов на узлах действий и малым количеством выходов на узлах ожидания, ваше время установлено неправильно, и окна ожидания следует сократить.

Математика удержания также должна учитывать затраты. Push-уведомления ничего не стоят за отправку после того, как подписчик дал согласие. Стоимость электронной почты зависит от вашего ESP, но при списке из 200 000 подписчиков с типичной настройкой Klaviyo или Bloomreach одна отправка брошенной корзины стоит несколько сотен долларов в виде оплачиваемого использования (применяются условия вашего контракта).

Автоматизация push-уведомлений о брошенной корзине с приоритетом push, которая восстанавливает корзины на 42%, может достичь того же количества восстановленного дохода, что и цепочка push и email на 38%, при значительно более низкой стоимости. Рассчитайте это для вашего собственного размера списка и контракта с ESP. Суть в том, что push, app push и WhatsApp не несут таких затрат за отправку, как email, и задача цепочки — использовать самый дешевый канал в первую очередь, когда это позволяет состояние подписчика.

Когда позиция в смете обоснована (эта цепочка восстановила корзин на сумму X при совокупной стоимости Y), разговор о бюджете короткий.

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

Каждый шаблон в этой статье напрямую сопоставляется с компонентами PushEngage Workflows. Вот сопоставление для пяти вышеуказанных шаблонов:

Шаблон	Используемые типы узлов	Типы используемых действий	Параметр рабочего процесса
Приветственная серия	НАЧАЛО, ОЖИДАНИЕ, РЕШЕНИЕ, ДЕЙСТВИЕ, КОНЕЦ	SendPushNotification, AddSegment	Тип запуска: Одиночный
Брошенные просмотры	START, WAIT, DECISION, ACTION, EXIT	SendPushNotification	Тип выполнения: Несколько параллельных
Эскалация брошенной корзины	НАЧАЛО, ОЖИДАНИЕ, РЕШЕНИЕ, ДЕЙСТВИЕ, КОНЕЦ	SendPushNotification	Тип запуска: Несколько параллельных; выход по цели purchase
Запрос отзыва после покупки	START, WAIT, SPLIT_PATH, ACTION, END	SendPushNotification, HttpRequest	Тип запуска: Несколько последовательных; тихие часы с 22:00 до 8:00, перенос времени выполнения при сбое
Возврат клиента	START, ACTION, WAIT, DECISION, END	SendPushNotification, AddSegment	Тип запуска: Одиночный; триггер на основе аудитории

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

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

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

Бесплатный план предоставляет вам 200 подписчиков, все четыре канала (веб-push, app-push, WhatsApp и live chat) и полный движок Workflows с первого дня. Этого достаточно, чтобы протестировать канал, прежде чем включать его в бюджет.

Что это меняет

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

Один СТАРТ, несколько ПАУЗ, несколько РЕШЕНИЙ, несколько ДЕЙСТВИЙ, один ВЫХОД. Шесть отдельных триггеров не могут этого сделать. Один движок рабочего процесса может. Математика удержания клиентов растет оттуда.

Начните с бесплатного плана, чтобы реализовать первый шаблон менее чем за час.