E-mail маркетинг для интернет‑магазина. Инструкция по внедрению - [14]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Набор данных

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

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

• e-mail;

• имя;

• город;

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

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

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

События

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

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

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

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

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

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

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

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

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

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

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

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

И т. д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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