Набор данных, который нам понадобится, предопределен нашим планом (конечно, можно добавить и что-нибудь от себя):
• 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) прилагается, рекомендую непременно изучить его как следует и опробовать в деле. Но если он не предоставляет нужных возможностей, возвращайтесь к ТЗ на синхронизацию или займитесь доработкой существующего решения – в зависимости от того, что посоветует программист.
