Прошлый год мы с вами закончили исправлением ошибок в email. 2018-й начнём со структуры базы данных (БД) для рассылки.
Правильно выстроенная структура позволяет формировать больше сегментов, настраивать больше триггеров, глубже персонализировать письма — в общем, получать больше от email маркетинга.
Кроме того, приведение данных в порядок автоматически подтягивает и другие процессы — например, сбор информации о подписчиках через анкеты и формы — а также помогает генерировать новые идеи для писем.
Только сразу оговорюсь: я ни в коем случае не являюсь техническим специалистом в области баз данных. Всё, о чём пойдёт речь дальше, будет касаться преимущественно маркетинговых штук, почерпнутых из умных книжек и собственного опыта.
Где хранить
Начнём с вопроса, где хранить данные для рассылок: email-адреса, имена, даты и прочие сведения, которые пригождаются в работе с подписчиками.
Предлагаю простой выход — хранить данные в рассылочном сервисе.
Там они будут «ближе» всего к рассылкам, а с помощью функционала сервиса их удобно просматривать, сегментировать, готовить на их основе кампании и собирать статистику.
Понятное дело, рассылочный сервис может быть не единственным местом для хранения. Например, данные могут также аккумулироваться в CMS, CRM, а также других местах типа табличек Excel при необходимости.
Если по какой-то причине хранение данных в сервисе недопустимо — что ж, собирать и обрабатывать их можно в собственной защищённой БД. В этом случае принципы для их организации останутся теми же.
Единый список
Данные удобно хранить в одном списке.
Это актуально не для всех сервисов, но тем не менее для части их них — таких как MailChimp или Юнисендер — где есть возможность создавать разные списки контактов.
Преимущества здесь в следующем: работая с единым списком, проще контролировать частоту писем, отписку, вести измерения показателей эффективности, а также непосредственно отправлять рассылки.
Если подписчики разнесены по разным спискам, и возникает необходимость провести кампанию по всем сразу, то письмо приходится копировать и отправлять несколько раз — по первому списку, по второму и так далее — причём иногда счёт доходит до десятка и более:
Мало того, что это потом приходится как-то обсчитывать, «вынимая» данные из разных отчётов. Но могут возникнуть и сопутствующие проблемы — например, пересечение списков.
Если контакт находится сразу в нескольких списках, соответственно, он может получить сразу несколько одинаковых писем:
Если же он решит отписаться от рассылки, то вполне возможно отпишется от одного списка, но останется в других — и продолжит благополучно получать письма после отписки 👿
В дальнейшем критерии, по которым мы делим подписчиков на списки, могут меняться. Тогда нам придётся заводить новые списки, а затем «перетасовывать» между ними данные, с риском наделать ошибок и дубликатов.
В конечном итоге это приведёт к целом полотнищу списков, часть из которых практически не используется, а по другим рассылки уходят слишком часто. Управлять при этом периодичностью рассылок, следить за более-менее равномерным охватом аудитории, измерять темпы роста и убыли базы (которые нужны, к примеру, для оценки эффективности источников подписки), становится тогда задачей нетривиальной.
Стоит ли говорить, что работа с единым списком снимает большую часть подобных проблем. И к тому же, добавляет гибкости: когда понадобится внедрить ещё один критерий сегментации, к данным достаточно будет присоединить дополнительное поле или завести новую группу в уже существующем.
Содержание полей
Если с местом и способом хранения информации мы определились, важно вооружиться ещё несколькими принципами, которые касаются непосредственно содержания полей базы данных для рассылки.
• 1 поле = 1 значение
Правило вполне понятное, если применить его на практике. Предположим, у нас есть форма заявки на услугу с одним полем для записи ФИО, и мы без изменения передаём эти данные в базу:
Когда нам понадобится использовать персонализацию — скажем, в теме письма — мы соорудим такую конструкцию:
{{Fname}}, приходи к нам на мастер-класс!
А наши подписчики увидят следующее:
Иванов Иван Иванович, приходи к нам…
Петров Пётр Петрович, приходи к нам…
И тема стала длиннее, и звучит как-то не по-русски.
Единственный нюанс в этой рекомендации: она не касается групп (под группами понимаю то же, что и groups в MailChimp). Если данные разбиты на отдельные независимые группы, то вполне могут входить в состав одного поля.
Например, у нас есть поле «Виды рассылок», содержащее группы по разным типам писем: новостной дайджест, информация от партнёров, специальные предложения. При условии, что пользователь выберет сразу несколько типов, почему бы не включить его одновременно в несколько разных групп, если это имеет для нас практический смысл:
• Заполняем единообразно
Другой пример: нам нужно сделать рассылку по Санкт-Петербургу. При этом данные о городе в нашей базе введены вразнобой: Санкт-Петербург, СПб, Петербург, …
Мы формируем сегмент, задав условие:
Город = Санкт-Петербург
проводим рассылку и, разумеется упускаем часть подписчиков, у которых данные введены иным образом.
Или нам приходится сооружать какой-то монстр-сегмент с условиями:
Город = Санкт-Петербург
Город = СПб
Город = СПБ
Город = Петербург
Город = Питер
…
и всё равно не факт, что получится охватить все варианты написания.
Отсюда вытекает следующее правило:
• Модерируем
Чтобы избегать некорректного заполнения полей или написания вразнобой, данные в полях, которые пользователь вбивает с клавиатуры, должны проходить периодическую проверку и исправление:
Серёга → Сергей
СПб → Санкт-Петербург
Disigner → Дизайнер
Если некоторые поля заполняют сотрудники в CRM, тем более стоит задавать стандарты и контролировать их исполнение.
При большом потоке данных модерация вручную проблематична. В таком случае стоит позаботиться о автоматизации: используя в формах больше списков и вариантов автозаполнения + внедряя вспомогательные решения (исправление имён, определение пола по имени и т.д.):
Количество полей
С количеством полей базы данных для рассылки стоит соблюдать разумную экономию.
Например, тот же MailChimp позволяет добавить не более 30 полей. В Юнисендере полей может быть сколько угодно, но это сделает сегментацию в базе громоздкой и трудноуправляемой:
Поэтому предлагаю следующий критерий, который определит — добавлять или не добавлять информацию в базу: зачем нам это нужно?
Если ответа на этот вопрос нет или он звучит невнятно (на всякий случай, потом, может быть, пригодится), то от внесения параметра в БД лучше отказаться.
Простой пример — отчество.
Моя сфера — финансовые услуги, и я собираюсь величать подписчиков по отчеству?
Иван Иванович, познакомьтесь с новым инструментом
Тогда окей, отчество пригодится.
У меня магазин гаджетов и преимущественно молодёжная аудитория? Тогда не факт, что и фамилия нужна:)
Иван, скорее! Новый iPhone уже в продаже!
Уменьшить количество полей поможет и чёткое понимание, как будет отправляться то или иное письмо. К примеру, номер заказа, адрес доставки, способ оплаты и т.д. нужны по большому счёту только для транзакционных сообщений. Они у нас отправляются через CMS или специализированный сервис. Тогда передавать их в базы данных для массовой рассылки и триггерных писем нет необходимости.
Аналогично с товарными рекомендациями и содержанием корзины: собираемся использовать RetailRocket или другое подобное решение? В таком случае, и этот набор параметров нам здесь не пригодится.
Виды данных
Наконец мы подобрались к самому интересному: какие данные вообще следует собирать о подписчике помимо email?
С проверочным вопросом наперевес (зачем нам это?) приступаем к организации полей в базе:
– Персональная информация:
ФИО, сфера деятельности, название компании, должность и т.д.
– Демография:
ДР (возраст), пол.
– География:
страна, область (субъект), город.
– Предпочтения:
виды и частота рассылок, интересующие продукты и т.д.
– Поведение:
количество транзакций, средний чек, дата последней транзакции, общая сумма и т.д.
– «Техническая» информация:
источник подписки, вспомогательные даты, статусы и т.д.
– Дополнительная информация:
всё, что не попало в приведённую выше классификацию (например, количество накопленных на счёте бонусных баллов).
Часть данных предоставит нам рассылочный сервис: дата подписки, активность в рассылках, IP, доступность email-адреса и т.д. — отнесём это к «технической» информации, которую собирать не нужно, поскольку она копится в базе и без нашей помощи.
Упростить понимание, какие данные и для чего нужны, поможет составление на начальном этапе плана email маркетинга. | |
Масштабируемость
Ещё один принцип, который стоит соблюдать при разработке структуры БД — это её масштабируемость.
Время идёт, ситуация меняется, нам приходят новые идеи и перед нами ставятся новые задачи. Если в начале проекта нам было достаточно набора данных Х, то через год уже может понадобиться Y.
Т.о. базу необходимо проектировать с прицелом на перестройку и добавление новых полей.
• Делаем поля универсальными
Например, мы заводим поле «Источник подписки», куда группами можем вносить различные источники: поп-ап, футер, главная страница.
Если у нас появятся новые способы подписки — например, мы соорудим лэндинг или повесим на сайт новую форму — нам достаточно будет включить в «Источник» соответствующие группы: лэндинг, заявка на расчёт и т.д.
Число полей при этом не изменится.
• Оставляем запас
В том же MailChimp, где действует ограничение в 30 полей, мы может сознательно сократить количество передаваемых данных. Чтобы задействовать, скажем, 15 полей, а ещё 15 оставить про запас.
Например, из связки ФИО «выкинем» фамилию и отчество — высвободим 2 поля. На сайте спрашиваем телефон, но отправлять смс-ки не собираемся? Тогда и телефон в БД не пригодится — ещё + 1 поле в резерв.
И так далее.
Автоматизация
Передавать данные в базу желательно, конечно, в автоматическом режиме. Это и избавит от рутинного труда, и уменьшит возможные ошибки, и позволит настраивать триггерные письма (например, отправлять welcome email сразу после подписки).
Для автоматизации у большинства рассылочных сервисов предусмотрено API (Application Programming Interface — интерфейс прикладного программирования).
Остаётся определить набор данных, который нам нужен — с учётом всех принципов — события, при которых мы хотим их передавать, и «упаковать» всё в техническое задание для программиста.
Подробнее, как писать такие ТЗ (с примером): №35 Синхронизация базы данных с рассылочным сервисом. |
|
БД для рассылки интернет-магазина
Теперь попробуем применить всё вышесказанное на практике, занявшись построением базы данных для рассылки условного интернет-магазина Internet-Shop-Example.com.
Дано: сайт с формами заказа, регистрации и подписки в футере или через поп-ап окно. Исходный набор данных, который мы можем получить:
– email, ФИО, телефон,
– адрес,
– способ доставки и оплаты,
– информация о заказе (№, дата, состав, чек, статус),
– источник подписки.
Пропустим их через «сито» оптимизации:
Проведя такую работу, получаем итоговый набор данных:
Из исходного многообразия мы получили меньше десятка полей, причём с широкими возможностями для сегментации, настройки триггеров, подстановки динамического контента и ведения статистики.
Поле (3) поможет настроить реактивационное письмо. По полям (3)-(7) можно проводить гибкую сегментацию по поведению подписчиков — вплоть до RFM.
С помощью поля (6) есть возможность запустить цепочку писем по программе лояльности (Вы заказали на общую сумму 50 000 рублей — держите «золотой» статус!). Информация по источникам подписки (8) поможет при их оптимизации, а также расчёте LTV — и так далее. Для начала неплохо!:)
Заключение
Организация базы данных для рассылки — дело индивидуальное, в котором нужно учитывать нюансы каждого конкретного проекта. Поэтому универсального решения здесь, к сожалению, нет.
Но есть набор принципов, руководствуясь которыми, можно создать вполне функциональную БД для рассылок:
→ хранение в рассылочном сервисе в едином списке,
→ 1 поле = 1 данное (за исключением групп),
→ единообразие и модерация,
→ оптимальное количество полей (зачем нам это нужно?),
→ типовые наборы данных (поведение, предпочтения и т.д.),
→ масштабируемость,
→ автоматизация.
Следуя этим принципам, можно как построить БД с нуля, так и постепенно переформатировать существующую базу для рассылок.
В конечном итоге, порядок с данными — это дополнительные возможности для рассылок, более оперативная и слаженная работа и, соответственно, большая отдача от email маркетинга.
В конце февраля разберёмся с практическим вопросом сегментации: как делать выборку «каждый N-й» и для чего она нужна? | |
P.S. Вы находите материалы Email-practice полезными?
Тогда читайте мою книгу «E-mail маркетинг для интернет-магазина»!
Если вы ещё не подписались на мою рассылку — самое время это сделать. Я не только анонсирую свежие статьи блога, но и делюсь с подписчиками бонусной информацией, а также показываю отдельные приёмы email маркетинга на практике. До встречи в вашем
почтовом ящике 😉