Практичный email [CRM] маркетинг

В прошлый раз мы раскладывали по шагам создание собственного Телеграм-бота. В этот — вернёмся к теме интеграции (синхронизации) базы данных и сервиса рассылок, которую начали рассматривать в одной из прошлых статей.

В ней мы поделили подготовку к интеграции на 2 этапа:

(1) Определение набора данных
(2) Описание событий, при которых эти данные передаются в сервис

С этапом (1) мы в тот раз разобрались. Теперь остаётся решить вторую половину «уравнения», чтобы затем уверенно приступать к практике интеграции.

 

Шаг 1: Составляем список действий на сайте

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

Поэтому первым делом открываем сайт, начиная прямо с его главной страницы, и двигаемся по разделам, фиксируя все такие действия, обычно связанные с заполнением форм на сайте.

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

Например, на главной странице мы видим форму обратного звонка и форму подписки в футере. Их и фиксируем в наших действиях:

• Заказ обратного звонка
• Подписка на рассылку

На странице контактов это может быть:

• Заполнение формы обратной связи

В интернет-магазине:

• Оформление заказа
• Подписка на товар не в наличии

Для b2b тематики:

• Скачивание прайса
• Запрос бесплатной консультации

Обращаем внимание на механики лидогенерации (получение контактных данных потенциальных клиентов), «сквозные» для всех страниц нашего сайта:

• Заполнение поп-ап формы с предложением скидки
• Прохождение квиза
• Скачивание полезного гайда

И так далее.

На выходе получаем список действий, которые тем объёмнее, чем больше и разветвлённее структура нашего сайта.

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

 

Шаг 2: Составляем список действий в базе данных

Под базой данных в этом случае я имею ввиду ту «изнаночную» часть, куда попадают данные после заполнения форм на сайте. Обычно это CMS сайта или CRM-система. Также это может быть система 1С, база данных MySQL, какое-то самописное решение и т.п.

Как правило, такая «админка» содержит доступ к множеству различных действий и операций, доступных её пользователям. Но нас интересуют только действия, связанные с изменением данных о клиенте. Например:

• Редактирование профиля клиента
• Перевод заказа клиента в следующий статус
• Фиксация оплаты заказа
• Смена этапа сделки с клиентом для сферы b2b

И т.п.

Если на сайте у нас набрался с десяток действий, то в базе данных их, скорее всего, добавится не более 3-5.

 

Шаг 3: Составляем список действий на внешних площадках

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

Для ВК, например, это может быть:

• Заполнение лид-формы

Для лэндинга мероприятия:

• Запрос программы
• Подписка на уведомление об изменении цены
• Регистрация

И так далее.

Количество действий, которое мы найдём в данном случае зависит от числа внешних площадок. Для «среднепотолочного» случая группы ВК, канала в Телеграме и пары лэндингов это может быть ещё где-то 3‑5 позиций.

 

Шаг 4: Объединяем списки и убираем лишнее

Следующий шаг — объединение собранных списков в один.

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

Использование может быть как прямое — отправка рассылок, — так и косвенное: добавление пользователей в сегменты, которые потом понадобятся для рассылок.

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

А вот действия типа «Оформил заявку/заказ» или «Скачал гайд/прайс» — это почти наверняка то, что нам нужно. Тут у нас планируются коммуникации, причём достаточно активные.

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

Итоговый список действий, таким образом, у нас подсократится. Это то, с чем мы будем работать дальше — те самые события, которые мы отобрали для интеграции.

 

Шаг 5: Добавляем данные

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

Если какие-то из данных у нас оказываются неохваченными, возвращаемся к предыдущим шагам, и находим для них недостающие события.

Держа наборы событий и данных перед глазами, мы «склеиваем» их, добавляя для каждого события задействованные в нём данные.

Например, заполнение формы подписки на сайте подразумевает передачу следующих данных:

• Email
• Имя
• Пометка об источнике подписки

При оформлении заказа у нас передаётся:

• Email
• Имя
• Состав заказа
• Адрес доставки
• Статус заказа

И так далее.

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

 

Формируем ТЗ на интеграцию

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

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

Вот, что может быть зафиксировано в ТЗ:

• Общая постановка задачи
• Доступы к сервисам / ключам АПИ
• Таблицы событий и данных
• Примечания, добавления в свободной форме

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

Однако прежде чем приступать к обсуждению интеграции, такое ТЗ на руках желательно иметь. Это сильно упростит нам коммуникацию на старте и быстрее выведет нас на путь практической реализации.

	[В следующий раз поговорим о том, как провести аудит форм подписки (лидогенерации) на своём проекте. Остаёмся на связи!]

— Ещё почитать —

Рисуем схему автоматических писем	Триггерные рассылки сервис vs. самостоятельно