E-mail маркетинг для интернет?магазина. Инструкция по внедрению - Алексей Ефимов Страница 12

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

* * *

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

Подготовьте задачи программисту и дизайнеру по базовым методам подписки и будьте готовы отвечать на их вопросы. Добавьте несколько дополнительных способов на свое усмотрение после того, как внедрены основные. Если у вас есть активность в офлайн, собирайте e-mail адреса и там.

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

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

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

А именно:

• информацию об источнике подписки (регистрация, заказ, 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 (специальный код для подключения сайта к сервису);

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

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

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