№88 Построение эффективной базы данных для рассылок

Прошлый год мы с вами закончили исправлением ошибок в 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, ФИО, телефон,
– адрес,
– способ доставки и оплаты,
– информация о заказе (№, дата, состав, чек, статус),
– источник подписки.

Пропустим их через «сито» оптимизации:

Работа с данными интернет-магазина для email рассылок

Проведя такую работу, получаем итоговый набор данных:

Итоговый набор данных для email рассылок интернет-магазина

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

Поле (3) поможет настроить реактивационное письмо. По полям (3)-(7) можно проводить гибкую сегментацию по поведению подписчиков — вплоть до RFM.

С помощью поля (6) есть возможность запустить цепочку писем по программе лояльности (Вы заказали на общую сумму 50 000 рублей — держите «золотой» статус!). Информация по источникам подписки (8) поможет при их оптимизации, а также расчёте LTV — и так далее. Для начала неплохо!:)

 

Заключение

Организация базы данных для рассылок — дело индивидуальное, в котором нужно учитывать нюансы каждого конкретного проекта. Поэтому универсального решения здесь, к сожалению, нет.

Но есть набор принципов, руководствуясь которыми, можно создать вполне функциональную БД для рассылок:

→ хранение в рассылочном сервисе в едином списке,
→ 1 поле = 1 данное (за исключением групп),
→ единообразие и модерация,
→ оптимальное количество полей (зачем нам это нужно?),
→ типовые наборы данных (поведение, предпочтения и т.д.),
→ масштабируемость,
→ автоматизация.

Следуя этим принципам, можно как построить БД с нуля, так и постепенно переформатировать существующую базу для рассылок.

В конечном итоге, порядок с данными — это дополнительные возможности для рассылок, более оперативная и слаженная работа и, соответственно, большая отдача от email маркетинга.

В конце февраля разберёмся с практическим вопросом сегментации: как делать выборку «каждый N-й» и для чего она нужна? 

P.S. Вы находите материалы Email-practice полезными?
Тогда читайте мою книгу «E-mail маркетинг для интернет-магазина»!

Если вы ещё не подписались на мою рассылку — самое время это сделать. Я не только анонсирую свежие статьи блога, но и делюсь с подписчиками бонусной информацией, а также показываю отдельные приёмы email маркетинга на практике. До встречи в вашем
почтовом ящике 😉

 


Теги: