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

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

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

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

• Отсутствие автоматической синхронизации контактов, контакты с сайта, CRM, 1С загружаются лишь эпизодически через Excel. Иногда вендоры вроде Flocktory, собирающие контакты с разрешения компании, хранят их у себя и не спешат ими делиться.
• По историческим причинам используется несколько ESP. Типичный пример — retail, где оффлайн со своей программой лояльности может использовать одну ESP, а интернет-магазин — другую.
• Отсутствие обмена отписками и баунсами между ESP. Иногда использование нескольких ESP оправданно, например тем, что в основной ESP недостаточно сильная механика по рекомендациям. Но в таком случае обязательно нужен процесс передачи данных по отпискам, баунсам и жалобам FBL.
• Использование слабой ESP, которая не позволяет реализовать необходимые маркетинговые механики,
• Наоборот, иногда используется слишком дорогая ESP, которая не нужна для тех задач, которые стоят перед компанией
• Не настроены необходимые для триггеров интеграции — фиды с товарами, передача данных о просмотрах, и.т.д. Иногда на это месте очевидна нехватка DDM.

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