Карты на стол: у нас уже есть набор способов подписки и есть сервис рассылок, с помощью которого мы будем осваивать поступающие адреса.

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

А именно:

• информацию об источнике подписки (регистрация, заказ, pop-up-форма и т. д.);

• имя и город подписчика (как правило, вводятся при регистрации);

• дату последнего заказа и общее количество заказов (известны после оформления покупки).

Этого вполне достаточно, чтобы реализовать наш план e-mail маркетинга: наладить выпуск массовой рассылки и подключить базовые автоответчики.

 

Зачем нужна синхронизация

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

Конечно, вы можете ежедневно вручную переносить адреса из своей базы (таблички Excel, CMS или CRM-системы) в рассылочный сервис. Но как показывает практика, делать это даже раз в неделю довольно затруднительно.

А как быть с автоматическими письмами? Если массовая рассылка еще немного подождет, то welcome-серия, запрос отзыва и предложение скидки на вторую покупку должны отправляться точно по расписанию и не зависеть от того, как часто вы обновляете базу.

Появляется необходимость отправлять данные в сервис рассылок в режиме реального времени – именно для этого и нужна синхронизация.

 

Как синхронизироваться

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

Вам понятно, что здесь написано? Мне – не очень:-) И на этом этапе я предпочитаю звать на помощь веб-программиста.

Автоматическое взаимодействие с рассылочным сервисом осуществляется при помощи API (Application Programming Interface – интерфейс прикладного программирования; почитать подробное определение можно, например, в Википедии). Насколько я сам понимаю эту штуку с позиций маркетолога: API – набор готовых методов, позволяющих программно реализовать интеграцию/синхронизацию различных систем. В данном случае – рассылочного сервиса и вашей базы данных.

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

Если вы подобрали рассылочный сервис по всем правилам (см. подробности во второй главе), то API у него уже есть, как и подробная техническая документация, описывающая набор доступных методов.

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

 

Техническое задание на синхронизацию

 

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

Предлагаю вам следующую структуру ТЗ:

• общая постановка задачи;

• вспомогательные материалы;

• набор данных для синхронизации;

• описание событий, при которых она срабатывает;

• примеры реализации.

 

Постановка задачи

Коротко формулируем, какой результат мы хотим получить в итоге.

Например: синхронизировать базу данных интернет-магазина shop-example.ru и рассылочного сервиса email-service.com.

 

Вспомогательные материалы

Здесь мы предоставляем исполнителю все, что может понадобиться для работы:

• доступ к рассылочному сервису (логин/пароль);

• документацию API (ссылку на ресурс, где она размещена);

• ключ API (специальный код для подключения сайта к сервису);

• список рассылки (ссылку на базу данных в сервисе, куда отправлять данные).

База в сервисе должна быть надлежащим образом подготовлена: содержать столбцы для всех видов данных с ячейками определенного типа (текст, даты, числа).

 

Набор данных

На этом этапе перечисляем все данные о подписчиках, какие хотим заводить в сервис. Удобно снабдить их короткими комментариями – для чего нужен каждый вид данных и как мы собираемся его использовать:

Набор данных, который нам понадобится, предопределен нашим планом (конечно, можно добавить и что-нибудь от себя):

• e-mail;

• имя;

• город;

• источник подписки;

• дата последнего заказа;

• количество заказов.

 

События

Ядро нашего ТЗ – события, которые инициируют передачу данных в рассылочный сервис.

Нас интересуют:

• подписка на рассылку (любым способом);

• заказ товара;

• обновление профиля подписчика на сайте (если есть).

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

В ТЗ вносим не только события, но и описание, что происходит при каждом из них:

Регистрация на сайте – если галочка в чек-боксе подписки включена, то в рассылочный сервис отправляются данные:

e-mail – в столбец E-mail;

имя – в столбец Имя;

город – в столбец Город;

«Регистрация» – в столбец Источник подписки.

И т. д.

 

Примеры реализации

Для полного понимания задачи удобно каждое событие снабжать примером того, как будет выглядеть база данных в рассылочном сервисе при том или ином событии.

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

Конечно, при подготовке каждого пункта ТЗ есть нюансы. Например, когда отправлять в сервис данные о заказе: сразу после его совершения (что не очень точно) или только после смены статуса заказа на «Завершен» (что уже лучше)?

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

 

Внедрение по ТЗ

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

После того как синхронизация выполнена, нужно будет принять работу.

Объект тестирования в этом случае достаточно сложен – целая программа, выполняющая множество различных действий по условиям «если/то». Поэтому и тестирование будет непростым.

Рекомендую для начала набросать на бумаге чек-лист (план) тестирования и уже потом приступать к проверке, чтобы ничего не упустить. Примерный чек-лист выглядит так:

Тест форм подписки :

• Зашел ли e-mail в сервис?

• Зашли ли в сервис сведения о соответствующем источнике подписки?

• Что произойдет, если попытаться подписаться на тот же адрес еще раз?

• Что произойдет, если подписаться на тот же адрес через несколько разных источников?

Тест формы регистрации/заказа:

• Зашел ли e-mail в сервис, если галочка в чек-боксе на подписку включена?

• Зашли ли в сервис имя и город подписчика?

• Зашли ли сведения о соответствующем источнике подписки?

• Что будет, если отключить галочку в чек-боксе на подписку?

Тест заказов:

• Зашла ли в сервис дата последнего заказа?

• Обновилось ли количество заказов?

• Что, если статус заказа не поменяется на «Выполнен»?

Тест обновления профиля:

• Обновились ли данные в сервисе после обновления их в профиле на сайте?

Скорее всего, несмотря на подробное ТЗ, синхронизация не заработает как нужно с первого раза. Запаситесь терпением: не набрасывайтесь на программиста после первой выявленной ошибки с требованиями немедленно все исправить – пройдите весь чек-лист до конца, а по итогам составьте отчет об ошибках с отсылками к конкретным пунктам ТЗ. Так будет эффективнее.

Готовьтесь принимать работу во второй и в третий раз (провести несколько итераций тестирования), и только в том случае, если какое-то ваше требование не выполняется раз за разом без уважительной причины. Можно немного и побеситься:-)

Пример отчета об ошибках:

П. 1.2 не выполняется.

П. 1.4 выполняется частично (адрес заходит, имя и город не заходят).

Тестировал на ящике info@ shop-example. ru…

И т. д.

Возможно, составлять такие отчеты – не самое приятное занятие, но другого способа добиться надлежащего качества исполнения пока не придумано.

 

Готовые решения: за и против

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

Это большой соблазн: обойтись без многостраничного ТЗ, десятка часов работы программиста и пачки отчетов об ошибках. Тем не менее я все-таки сторонник «ручного» подхода. Ни разу еще мне не встречался готовый модуль интеграции с рассылочным сервисом, который хотя бы на 50 % удовлетворял потребностям e-mail маркетинга.

Как правило, модули хорошо справляются с импортом основной информации: e-mail и имени подписчика, но гораздо хуже – с дополнительными данными вроде сведений о заказе или источнике подписки. Однако именно дополнительные данные, отправленные в сервис в нужном порядке и в нужный момент времени, определяют эффективность синхронизации.

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

* * *

Немного переведем дух и оценим перспективы: вы сделали очередной шажок по плану e-mail маркетинга и на самом деле продвинулись уже довольно далеко.

Если работа по подготовленным заданиям (внедрение разных способов подписки и синхронизация с рассылочным сервисом) идет полным ходом, то совсем скоро ваш сайт «оденется» в новые красивые формы и начнет исправно снабжать вас e-mail адресами и всей необходимой дополнительной информацией.

Следующий шаг напрашивается сам собой (хотя можно заглянуть для верности в программу внедрения). Адреса есть, сервис рассылок «под всеми парами» – настала пора писать письма и готовиться к запуску регулярной массовой рассылки.