Продолжаем разбор разделов отчета по аудиту email-маркетинга. В этом разделе изучим архитектуру систем, участвующих в email-маркетинге.

Для начала полезно задокументировать архитектуру AS-IS.

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

Типичные проблемы с архитектурой:

— отсутствие автоматической синхронизации контактов, контакты с сайта, CRM, 1С загружаются лишь эпизодически через Excel. Иногда вендоры вроде Flocktory, собирающие контакты с разрешения компании, хранят их у себя и не спешат ими делиться;

— по историческим причинам используется несколько ESP. Типичный пример — retail, где оффлайн со своей программой лояльности может использовать одну ESP, а интернет-магазин — другую;

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

— использование слабой ESP, которая не позволяет реализовать необходимые маркетинговые механики;

— использование слишком дорогой ESP, которая не нужна для тех задач, которые стоят перед компанией;

— не настроены необходимые для триггеров интеграции — фиды с товарами, передача данных о просмотрах и т.д. Иногда на этом месте очевидна нехватка DDM.

Скорее всего, рекомендации, которые вы дадите в этом разделе, будут реализовываться дольше всех остальных (если вообще будут), поскольку они потребуют больше всего расходов. С другой стороны, потенциально здесь можно затронуть самые болезненные для компании вопросы, например неадекватная ESP. Так что сложность этих вопросов — не повод не рекомендовать их решение.