У любой организации, которая принимает платежи от клиентов, рано или поздно возникает вопрос: что делать с уведомлениями об оплате?
Простая техническая отбивка или чек от платёжного сервиса закрывают юридическую составляющую процесса, но не решают маркетинговые задачи компании. Однако из каждого такого события — оплаты товара, подписки или пожертвования — можно сделать персонализированный повод для коммуникации, согласовать следующий контакт с менеджером, напомнить о дополнительной услуге или, в случае благотворительности, аккуратно предложить поддержку на регулярной основе.
Транзакционные письма по статистике показывают один из самых высоких open rate (OR, открываемость писем) и click‑through/conversion rate (CR, коэффициент конверсии), поэтому превращать их из «служебных» в осознанные маркетинговые сценарии выгодно практически в любой сфере.
Меня зовут Овчинникова Анна, я бизнес‑консультант в компании CleverData. В этой статье я расскажу, как мы в CleverData построили такой сценарий для фонда «Хранители детства» и помогли от ручных писем перейти к персонализированным коммуникация��. Впрочем, советы из этой статьи можно применять и коммерческим компаниям и некоммерческим организациям.
Какую задачу мы решали
Перед нашим партнером, фондом «Хранители детства», который уже много лет помогает подросткам из детских домов, приёмных и кризисных семей, а также молодёжи с ограниченными возможностями здоровья, — стояла задача агрегировать все данные по донорам в одной платформе и выстроить более тонкую, персональную коммуникацию с каждым из них.
Мы предложили им свою помощь и внедрили платформу клиентских данных (CDP) CleverData Join. Нам нужно было собрать данные о пожертвованиях, автоматизировать отправку писем и перевести коммуникацию в простой в использовании рассыльщик, который является одним из модулей платформы.
В CleverData мы сопровождаем фонд не только технически, но и методологически: помогаем формулировать бизнес‑требования, проектировать цепочки писем, настраивать сегментацию и коммуникационные сценарии.
В этой статье я расскажу, как мы настроили триггерную email‑коммуникацию по пожертвованиям на сайте, используя данные о платежах из платёжного сервиса и данные фонда. Надеюсь, эти советы пригодятся и вам в коммерческом или некоммерческом проекте.
Общая архитектура: событие платежа → сценарии в режиме реального времени
В этом кейсе процесс выглядит следующим образом: донор оформляет пожертвование на сайте фонда через платёжный сервис, который отправляет уведомление о транзакции, а CDP платформа CleverData Join, получив это событие, запускает соответствующую триггерную кампанию — благодарственное письмо или сценарий обработки ошибки, в зависимости от статуса платежа.
Технически вся интеграция строится вокруг универсального HTTP эндпоинта приёма событий в CleverData Join: мы один раз настраиваем маппинг для формата уведомлений платежной системы и дальше принимаем их вебхуки как есть, без написания отдельного сервиса под конкретную структуру JSON.
Проще говоря, в CleverData Join есть один универсальный «вход» для событий от внешних систем — специальный HTTP‑адрес. Любой сервис может отправлять туда свои уведомления о платежах. Чтобы эти уведомления превратились в понятные для платформы события, мы один раз настраиваем маппинг: говорим системе: «вот это поле в уведомлении — сумма, вот это — статус, вот это — email, вот это — дата». После этого платежный сервис продолжает слать свои стандартные уведомления, а CDP сама каждый такой запрос «переводит» во внутренний формат и кладёт данные в нужные атрибуты профиля и события. Главное: нам не нужно заказывать у разработчиков отдельный микросервис, который будет разбирать JSON от платежной системы и складывать данные в CDP. Мы настраиваем схему соответствия полей в интерфейсе — и дальше маркетинг может строить сегменты и триггерные сценарии уже на этих данных.
Настройка триггерных сценариев в модуле коммуникаций с клиентами (Campaign Manager)
Что особенного было предусмотрено для этой кампании в настройке:
триггерные сценарии запускаются при получении платежа на основе настроенного сегмента в реальном времени.
внутри сценариев настроены фильтры по типу платежа: первый/ повторный, рекуррентный (регулярный) /разовый, успешный/отклонённый.
от ветки сценария зависит, какой шаблон письма уйдёт донору и с каким текстом.
в письмах реализована динамическая персонализация: при сумме пожертвования выше 200 рублей в тексте письма дополнительно указывается размер перевода, что позволяет подчеркнуть значимость вклада и выразить более персональную благодарность от фонда; подстановка суммы выполняется с использованием Jinja выражений.
Для каждого сценария существует ряд необходимых полей на этапе создания: имя и описание сценария, сегменты для отправки, условия запуска и остановки сценария, режим прохождения, выбор контактов и установка переменной контекста для отправки сообщений.
Использование сегментов реального времени позволило нам выстроить три логики взаимодействия с пользователями: для новых доноров, для повторных донатов и для обработки неуспешных платежей.
Сегментация для триггерных сценариев
Для того чтобы письма были отправлены определённым донорам, необходимо заранее создать сегменты. В CleverData Join сегменты создаются в отдельном модуле «Аудитория». Для этих цепочек необходимо создать сегменты реального времени (RT-сегменты).
Для каждого сегмента:
задаём понятное название и описание (например, «Ошибочный платёж»);
в блоке «Критерии» используем выбор событий клиентского пути (Customer Journey) и в качестве источника событий выбираем платежный сервис;
настраиваем расписание «В реальном времени», чтобы попадание в сегмент происходило сразу после события.
И далее для каждого триггерного сценария мы добавляем свои критерии.
Сегмент «Ошибочный платёж» используется в сценарии обработки отклонённых платежей.
В сегменте прописываем следующее условие: «включать людей, у которых сработало событие от платежного сервиса со статусом платежа = Declined». Сегмент работает в режиме реального времени: как только платежная система присылает сообщение (вебхук) с информацией о неуспешном платеже, профиль попадает в сегмент «Ошибочный платёж» и дальше передаётся в соответствующий триггерный сценарий с ветками по причинам отказа.
Связка сегментов и кампаний
Дальше RT-сегменты используются как входные условия для триггерных сценариев. Описанный выше сегмент «Ошибочный платёж» подключается к сценарию обработчика ошибок, где есть ветки по причинам отклонения платежа (нет средств, истёк срок карты, другая ошибка) и свои шаблоны писем.
Итого, в модуле Аудитория маркетолог настраивает сегменты через визуальный интерфейс, а рассылочный модуль «подхватывает» уже собранную аудиторию и запускает нужную цепочку.
Теперь давайте вместе разберем настройки каждой кампании.
Сценарий 1: успешное новое пожертвование — первый платёж и «возвращённые» доноры.
Триггерный сценарий срабатывает на первое успешное пожертвование донора.
Сначала мы:
- проверяем факт пожертвования (успешный платёж);
- записываем в контекст (аналог переменных в рамках одного прохождения сценария) интервал рекуррентных платежей, который потом используем для определения вернувшихся доноров.
Контекст сценария в CDJ — это набор пар «ключ-значение», который хранится отдельно для каждого профиля и прохождения и может содержать значения атрибутов профиля, событий, вычисленные величины. В нашем случае туда мы записываем интервал регулярности платежа, дату последней оплаты и email донора, на который ему будет отправлено письмо.
Далее нам необходимо разделить ветки — на первый платёж (рекуррентный и разовый) и доноров, которые вернулись к помощи фонду после перерыва.
Возвращенные доноры
Сначала проверяем, что человек в принципе является жертвователем (у него был хотя бы один платёж в истории взаимодействия с кампанией).
На следующей развилке сценария мы смотрим на давность предыдущего платежа:
если с прошлого раза прошло более 37 дней (месяц рекуррентного периода + неделя), считаем донора «возвращённым»;
иначе — это первый платёж или регулярное пожертвование без значительного перерыва.
Таким образом, для «возвращённых» доноров запускается отдельный шаблон: мы благодарим донора за возвращение к поддержке фонда и прилагаем ссылку на страницу, где можно изменить тип и сумму пожертвования.
Вторая ветка – первое пожертвование донора: однократное или рекуррентное (автосписание)
В случае однократного пожертвования мы отправляем письмо «Благодарим за ваше первое пожертвование!», в тексте объясняем ценность помощи фонду и мягко предлагаем оформить регулярную поддержку, добавляя кнопку «Стать постоянным донором».
Для рекуррентного пожертвования используем другой шаблон, в котором делаем акцент на ценности регулярной поддержки фонда.
Все эти ветки реализованы как последовательность узлов (по истории платежей и интервалам) и нескольких email-узлов с разными шаблонами.
Сценарий 2: успешное повторное пожертвование
Цель этой кампании — поблагодарить регулярных доноров и аккуратно работать с суммой перевода.
Условия входа в сценарий:
Сценарий использует сегмент реального времени (Real-Time), который фиксирует повторный платёж.
Дополнительно в начале сценария из контекста RT-события мы сохраняем email донора в контекст сценария, чтобы гарантированно отправлять письмо именно на тот адрес, по которому прошёл платёж.
Структура сценария в Campaign Manager:
RT-вход по событию платежа;
узел фильтра «успешное повторное пожертвование»;
узел сохранения email в контекст;
узел «Отправка email» c выбранным шаблоном и параметрами отправителя;
финальная проверка сценария на ошибки (валидаторы CDJ не пропустят пустое поле отправителя, неверный шаблон, ошибки в динамических параметрах и т.п.).
Просмотр письма перед отправкой на тестовый сегмент без персонализации:
Сценарий 3: обработка отклонённого платежа с разными причинами отказа
Третий сценарий кампании предназначен для обработки неуспешных транзакций и включает несколько веток, каждая из которых учитывает конкретную причину отказа, переданную платежной системой.
Логика входа:
Сценарий запускается по RT-событию платежа с признаком неуспешной операции.
В событии из платежного сервиса есть:
атрибут «успешно/неуспешно»;
атрибут с кодом или текстом причины (недостаточно средств, карта просрочена, другая ошибка).
Ветка 1: недостаточно средств
Эта ветка активируется, если в атрибуте причины отказа содержится код/сообщение о нехватке средств на карте.
В письме поясняем донору, что платёж не прошёл из-за недостатка средств, и предлагаем варианты решения проблемы:
Ветка 2: истёк срок действия карты
Здесь на входе условие проверяет соответствующий код/сообщение.
В письме сообщаем донору, что платёж не прошёл из-за истечения срока карты, и предлагаем обновить данные карты, привязать новую для автосписаний или разово перевести пожертвование.
Ветка 3: другая причина
Все прочие ошибки попадают в третью ветку коммуникации.
Таким образом, один сценарий позволяет обработать основные причины отмены платежа, а вся вариативность логики и сообщений сосредоточена в условиях, основанных на атрибутах события, и в текстах шаблонов.
Что удобно и маркетологу, и разработчику
С точки зрения маркетинга:
все ветки и услови�� создаются визуально в Campaign Manager: фильтры по атрибутам профиля, события, интервалам времени и контексту;
бизнес-логика «повторное пожертвование», «перерыв > 37 дней», «рекуррент/разовый» задается в сценариях и шаблонах, а не в коде.
С точки зрения разработки и эксплуатации:
интеграция с платежной системой реализована через универсальный эндпоинт, конфигурируемый маппингом;
новые ветки и триггеры можно добавлять без изменения интеграционного слоя, маркетологу достаточно расширить сценарий и шаблоны;
существующие метрики позволяют мониторить доставку событий и корректность интеграции.
В этой статье я разобрала один из базовых сценариев — кампанию вокруг платежей, но сама логика построения цепочки легко переносится на любые транзакционные события: оплату заказа, продление подписки, запись на услугу, подтверждение брони и т.п. По этой схеме можно собирать и другие важные для компаний коммуникации — от сервисных уведомлений до сложных постпродажных цепочек.
Для фонда «Хранители детства» это не просто техническая автоматизация, а рабочий инструмент для долгосрочных отношений с донорами: несколько связанных триггерных сценариев вокруг платежа помогают учитывать историю пожертвований, корректно реагировать на ошибки и поддерживать вовлечённость людей, которые помогают фонду.
И мы в CleverData с радостью поддерживаем фонд «Хранители детства», который дает подросткам из уязвимых групп больше возможностей для обучения, выбора профессии и самостоятельной жизни. И это правда важно.
