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

Руководство рассчитано на интернет-магазин с собственной клиентской базой и действующим доступом к сервису. Контакты покупателей маркетплейса нельзя автоматически считать базой для внешней рассылки.

Составьте таблицу решений до вставки тегов

Для каждого варианта укажите основание: количество подтверждённых заказов, принадлежность группе или заполненное поле. Справка Mailchimp допускает условия по полям аудитории и группам, но обычные контактные tags с этим механизмом не работают. Не подменяйте отсутствие нужного поля похожей меткой в интерфейсе. Их одинаково удобные названия не означают одинаковой поддержки внутри шаблона.

Разделите положительный, отрицательный и неизвестный результат. Если число заказов не передано, это ещё не ноль покупок. Для такого профиля можно подготовить нейтральное предложение. Основание скидки проверяется по данным магазина, а не по желанию сделать письмо более личным. Принцип корректного сопоставления полей объясняет разбор импорта клиентских данных.

Проверьте тип поля и порядок условий

Для числовых сравнений Mailchimp рекомендует числовые поля. Текст со смешанными значениями может дать неожиданный результат. При нескольких порогах важно читать ветки сверху вниз: высокий уровень обычно проверяется до более широкого низкого. Это редакционная модель принятия решения, которую нужно проверить на конкретном коде, а не универсальное обещание автоматического расчёта выгодной скидки.

В руководстве указано, что обычные AND и OR нельзя вставлять внутрь условия как привычные логические операторы: строка будет интерпретирована целиком. Начало и конец конструкции должны находиться в одном блоке. Учебный вариант для заранее созданного числового поля ORDERS: *|IF:ORDERS >= 10|* открывает предложение постоянному покупателю, *|ELSE:|* — резервный текст, *|END:IF|* закрывает конструкцию. ORDERS здесь имя поля примера, а не встроенный счётчик сервиса. Для сложных вложений привлеките специалиста, который проверит синтаксис; визуальная привлекательность письма ничего не говорит о том, закрыты ли все условные конструкции.

Не переносите этот механизм в неподдерживаемые места

Conditional merge tags не предназначены для темы письма и уникальных URL. Они также не подставляют персональные значения в обычную тестовую отправку. Используйте предпросмотр с данными контактов и подходящий контрольный сегмент. Отличие такого контроля от просмотра пустого макета разобрано в материале о персонализированных блоках.

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

Проверьте исполнение предложения в магазине

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

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