API-интеграция: как определить набор данных для обмена — Практичный email маркетинг
>
В прошлый раз мы экспериментировали с квизом, как мощным источником новых подписок. Сегодня будем говорить о такой теме, как API-интеграция (синхронизация) базы данных своего сайта и сервиса, используемого для рассылок.
Этот этап закономерно вытекает из предыдущего — сбора контактов тем или иным способом. Ведь когда мы собрали данные о подписчиках, их нужно передавать дальше «по цепочке», чтобы в конце концов отправить по ним рассылку.
Как мы уже рассматривали ранее (см. Синхронизация базы данных…), обмен данными складывается из двух основных составляющих — определения набора данных и описания событий, при которых эти данные передаются в сервис.
| На эту тему также есть хорошая статья от Юлии Повх в блоге Юнисендер — Интеграция с сервисом рассылок: как написать ТЗ. |
Сосредоточимся на первом «слагаемом» данного процесса — определении набора данных — и попробуем разбить его на отдельные шаги для упрощения задачи.
—
Шаг 1: Составляем список писем
Как правило, данные о подписчиках нам нужны, чтобы отправлять по ним коммуникации — email-рассылки. Соответственно, от тех писем, которые мы собираемся отправлять, и будет зависеть необходимый набор данных. Поэтому первое, чем нам нужно заняться, это составить список таких писем (в основном, автоматических).
Если подходить к делу совсем «глобально», то процесс будет выглядеть так:
• Постановка целей email-маркетинга
• Разработка плана по достижению этих целей
• Определение сегментов базы и писем для них
Однако на практике часто всё происходит не так основательно, и мы сразу начинаем с писем, которые хотим отправлять — исходя из наших идей, опыта, лучших практик, а также статей-подборок из разряда «топ-10 писем для интернет-магазина» ))
Поэтому предположим, что подобный список мы составим без труда. Например, в каком-то таком виде:
• Бонус за подписку
• Брошенная корзина
• Welcome-серия
• Запрос отзыва
• Реактивация
• … … …
Если в нём наберётся 10-20 позиций, значит, работа проделана качественно.
—
Шаг 2: Определяем данные
Собранные письма сами подскажут, какие данные требуются для их отправки.
Например, для welcome-серии нам достаточно email-адреса пользователя и факта его подписки. Для более «продвинутых» сценариев типа брошенной корзины понадобится уже больше: не только email и факт добавления товаров в корзину без заказа, но и информация о каждом из этих товаров + возможно, дополнительные параметры, такие как индивидуальный промокод на скидку и т.п.
В подобном духе нам нужно пройтись по всем запланированным письмам, выписывая рядом необходимые параметры для их отправки, пока хотя бы в общем виде. Удобно делать это в таблице, где в одном столбце будет список писем, а в другом — набор данных для них:
С определением данных для некоторых писем могут возникнуть трудности. Например, какие данные передавать о товарах для брошенных корзин и других подобных сообщений?
| Лёгкого способа решить эту проблему нет, если мы подступаемся к ней впервые. Но есть вспомогательный метод, который может прояснить ситуацию. |
Попробуем «собрать» интересующее нас письмо — ту же брошенную корзину — в том виде, как будто её уже получил реальный пользователь, с товарами и ссылками. Не обязательно делать это «начисто» или даже задействовать html-шаблон письма. Вполне достаточно набросать контент прямо в Гугл-доке на скорую руку:
Такое «упражнение» само собой начнёт выводить нас на необходимые данные. Что нужно, чтобы подставить в письмо карточку товара? — его название, фото и ссылка. А будем ли мы указывать цену на товар, скидку при наличии и число остатков на складе? Хороший вопрос.
Вообще, поскольку нас ничто не сдерживает и мы «рисуем письмо на бумаге», можем включить в него и эти параметры тоже:
Пока мы исходим из «программы максимум», чтобы получить представление о наиболее полном наборе данных, которые могут понадобится. Впоследствии, скорее всего, нам придётся его сократить. Но вычёркивать параметры из списка несложно, а вот недосчитаться какой-то важной переменной уже в ходе внедрения настоящего письма гораздо неприятнее.
| См. также Как добавлять динамический контент в рассылки, где похожий метод описан подробнее. |
Таким способом мы проходим по тем письмам, которые вызывают у нас сложности. Если таких писем, скажем, 10, работа предстоит немаленькая, но она поможет хорошо собрать необходимые данные.
—
Шаг 3: Уточняем данные
Итак, теперь у нас есть таблица с письмами и данными, которые в них будут использоваться:
В принципе, на текущем этапе мы можем уже исключить письма, оставить только данные, а также убрать повторы, поскольку разные сообщения иногда требуют одних и тех же параметров:
Конечный список нам ещё нужно уточнить, проясняя по каждому параметру, откуда он берётся, куда поступает и как используется. Причём двигаться удобнее в обратном порядке, и начать именно с использования данных.
• Как используется
Здесь уже приходит пора погружаться в функционал выбранного нами сервиса рассылок. Мы идём в раздел автоматических/триггерных рассылок и пробуем в черновом виде создать интересующие нас сценарии, без детально проработанных писем. Подключенная API-интеграция также пока не требуется:
Возникающие по ходу вопросы решаем при помощи техподдержки и базы знаний сервиса. Такая предварительная настройка поможет нам понять имеющиеся в сервисе ограничения, и с учётом этого скорректировать набор данных.
| Подробнее этот подход показан в статье Настраиваем автоматические письма, исходя из возможностей… |
Например, мы увидим, что возможности подставлять товары в письмо о брошенной корзине нет, но можно запустить напоминание просто со ссылкой на корзину. Для этого нам понадобится, скажем, добавление пользователя в отдельный список внутри сервиса.
Вносим соответствующие правки в наш список:
Конечно, учитывать возможности сервиса можно было и сразу, при составлении первичного списка данных на предыдущем шаге. Но если мы занимаемся подготовкой к интеграции впервые, легче двигаться последовательно.
К тому же, работа по определению набора данных по «программе максимум» никогда не будет лишней. Она пригодится нам в перспективе, для дальнейшего развития email-маркетинга на проекте.
• Куда поступает
Когда мы пробуем настроить цепочки писем в сервисе, то, вероятно, уже создаём для этих целей различные поля с данными внутри него, а также пользуемся его собственными «системными» полями:
На основе некоторых из них будет запускаться отправка писем, другие данные будут подставляться в самом письме (например, обращение к подписчику по имени при его наличии).
Это ещё больше позволит уточнить наш исходный набор данных, вплоть до конкретных названий и форматов, в которых эти данные понадобится передавать — текст, число, дата и т.п.:
• Откуда берётся
Когда набор данных на стороне сервиса мы уточнили, остаётся сделать то же самое на стороне нашего сайта, откуда они будут передаваться. При этом достаточно ограничиться чисто внешней стороной вопроса: залезать глубоко в базу данных, смотреть код и прочие технические нюансы не нужно.
Задача тут скорее дать «наводку» для веб-разработчика (проджект-менеджера), с помощью которого будет далее выполняться API-интеграция — какие данные мы имеем в виду, из какой формы, полей профиля, карточки внутри CMS/CRM-системы и т.п.:
Это окончательно прояснит необходимый нам набор данных:
Такая таблица — уже почти готовое ТЗ на интеграцию базы данных с сервисом рассылок. Остаётся только дополнить её событиями, инициирующими обмен данными, и очертания, в которых будет работать наша будущая API-интеграция, вполне сложатся.
Однако формирование списка событий заслуживает отдельного разговора, поэтому перенесём его на какой-нибудь другой раз;)
А пока что завершаем работу. Набор данных для интеграции с сервисом рассылок готов!
 |
[В следующей статье мы выберемся из технических «дебрей», и поговорим о вещах более простых и понятных: как составлять и вести контент-план для рассылок]. |
—
P.S. Если вы ещё не подписались на рассылку моего блога — самое время это сделать 😉
