Вопросы на собеседовании: Email-маркетолог

Динамический сегмент пересчитывает состав по правилам, а статический хранит фиксированный набор контактов, пока его явно не изменят.

• Состав динамического сегмента меняется вместе с полями профиля или событиями, поэтому контакт может войти или выйти без ручного обновления.
• Состав статического сегмента меняется только при явном добавлении или удалении контактов через импорт, форму, интеграцию, ручное действие, API или автоматизацию; правила аудитории его не пересчитывают.
• Сегмент активных за последние 30 дней естественно делать динамическим, а фиксированную контрольную группу или список участников на дату среза статическим.
• Динамический сегмент не является историческим снимком, потому что повторный запуск того же правила позже может вернуть другую аудиторию.

Поведенческий триггер реагирует в момент события, а поведенческий сегмент объединяет контакты, чья история событий соответствует правилу.

• Событие purchase_completed может запустить вход в цепочку в момент покупки с учётом правил повторного входа и дедупликации.
• Сегмент вроде совершивших покупку за 30 дней пересчитывается по сохранённым событиям и может использоваться как аудитория или условие.
• Одно событие может поддерживать обе сущности, но триггер обозначает переход, а сегмент текущее состояние членства.
• Если триггер пропущен в момент события, контакт может не войти в цепочку, тогда как поздний расчёт сегмента всё ещё найдёт событие в истории.

Давность показывает, как недавно произошло событие, а частота считает, сколько раз оно произошло в заданном окне.

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

Engaged-30, engaged-90 и engaged-180 являются внутренними названиями по последнему значимому взаимодействию в заданных окнах ретроспективного анализа.

• При одинаковом сигнале engaged-30 входит в engaged-90, а engaged-90 входит в engaged-180.
• Если нужны отдельные интервалы, их задают как до 30 дней, более 30 и до 90, более 90 и до 180 дней, чтобы один контакт не попадал во все более широкие когорты.
• Apple Mail Privacy Protection может заранее загружать пиксели отслеживания и создавать открытие без прочтения письма человеком.
• Клики, покупки, ответы и авторизованные действия на сайте являются более надёжными сигналами, а членство по открытиям следует считать шумным приближением.

RFM оценивает клиентов по давности, частоте и денежной ценности за указанный период наблюдения.

• Давность означает время с последней подходящей покупки или другого заданного ценностного события, причём более недавнее событие обычно получает более высокий балл.
• Частота означает число подходящих транзакций за период, где лучше считать заказы, а не продублированные позиции или события.
• Денежная ценность означает сумму покупок, выручку, валовую прибыль или другой явно заданный показатель ценности за тот же период.
• Каждый компонент часто ранжируют по квантилям, например от 1 до 5, а затем объединяют, но направление шкалы и веса должны быть явными.

RFM требует калибровки, потому что полезные границы оценок зависят от распределения клиентов, цикла покупок и определения ценности в конкретном бизнесе.

• Квантильные пороги нужно пересчитывать или проверять при изменении сезонности, ассортимента и поведения клиентов.
• Частота и денежная ценность часто коррелируют, поэтому их объединение без проверки может дважды учитывать один и тот же паттерн покупок.
• Новые клиенты могут выглядеть слабо, потому что ещё не успели набрать частоту, а одна давняя дорогая покупка может переоценить значимость неактивного клиента.
• RFM описывает выбранную историю транзакций, а не намерение, удовлетворённость, предпочтительный канал или полную прибыльность клиента после всех затрат, поэтому сегменты нужно проверять по последующим результатам.

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

• Пересечение возникает, когда контакт соответствует нескольким правилам, например недавно и купил, и кликнул.
• Приоритет разрешает пересечение: сначала проверяется самое приоритетное правило, а уже назначенные контакты исключаются из следующих.
• В классификации недавние покупатели могут стоять выше активных без покупки, поэтому второе правило явно требует отсутствия недавней покупки.
• Сумма размеров сегментов должна равняться их объединению для проверки взаимоисключаемости; полное покрытие требует равенства объединения всей целевой аудитории или fallback-сегмента для остальных.

Атрибуты профиля описывают текущее или действующее состояние контакта, а свойства события контекст одного зафиксированного действия.

• Локаль, тариф, lifecycle-статус и заявленные предпочтения хранят в профиле, если они действуют дольше одного события и могут меняться.
• ID товара, сумма заказа, устройство и кампания хранятся в событии, когда они объясняют действие в момент его совершения.
• Сегмент может объединять оба вида данных, например текущий тариф premium И покупка категории X за 30 дней, не копируя покупку в профиль.
• Нужно явно задать владельца поля, тип данных, время события и правила обновления, чтобы временный контекст не перезаписал устойчивое состояние профиля.

Lifecycle-цепочка является постоянной автоматизацией с состоянием, а разовая кампания представляет собой отдельную отправку выбранной аудитории в заданное время.

• Кампания обычно определяет аудиторию, отправляет одно основное сообщение или согласованную партию и завершается.
• Цепочка принимает контакты по событию или условию и может содержать задержки, ветвления, повторяющиеся шаги и критерии выхода.
• Состояние цепочки хранит текущий шаг каждого контакта и разрешение на повторный вход, тогда как членство в кампании не отражает движение по последовательности.
• Обе сущности могут использовать одинаковые шаблоны и сегменты, но расписание серии рассылок само по себе не создаёт lifecycle-состояние, учитывающее события.

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

• Вход должен происходить при зафиксированной действующей подписке и разрешении; если подтверждение обязательно или настроено, первое письмо отправляют только после него.
• Первое письмо выполняет обещание при подписке и задаёт ожидания, а следующие шаги знакомят с подходящей ценностью и ведут к понятному действию.
• Ответы квиза нужно хранить как определённые поля профиля или события, которые направляют контакты в подходящие ветки, сохраняя путь по умолчанию для пропущенных или неизвестных ответов.
• Ветки могут снова сходиться на общих шагах, а покупка, конверсия, отписка или недействительный адрес должны переводить контакт к подходящему выходу.

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

• На ранних этапах обычно подтверждают потребность и обучают, а на поздних дают доказательства и предлагают подходящее следующее действие.
• Сигналами ветвления могут быть клик по ссылке, скачивание материала, просмотр продукта, отправка формы или покупка.
• Ветка должна проверять определённый сигнал за определённый период, а не делать вывод о намерении только по открытию письма.
• Для контактов без сигнала нужен явный путь по умолчанию, чтобы они не застревали в цепочке.

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

• Участие в win-back определяется поведением клиента, например временем с последнего заказа, продления или платного действия.
• Участие в реактивации определяется поведением в канале, например отсутствием недавних кликов или другого надёжного взаимодействия с письмами.
• Успехом win-back может быть повторная покупка, а успехом реактивации считается возобновление взаимодействия или явное подтверждение настроек подписки.
• Неудачная реактивация обычно ведёт к исключению из маркетинговых рассылок, а неудачный win-back сам по себе не отменяет действующее разрешение на письма.

Задержка отсчитывает промежуток после предыдущего шага, а окно относительно события размещает отправку рядом с датированным событием.

• Задержка на 24 часа начинается, когда конкретный контакт достигает шага, поэтому предыдущие ветки и ожидания влияют на итоговое время отправки.
• Правило относительно события может отправить письмо за два дня до продления или в заданный период после времени покупки.
• Если дата исходного события меняется, расписание относительно события может пересчитаться, а задержка обычно продолжает отсчёт с момента своего начала.
• Для контактов с уже прошедшим окном нужно правило, например пропустить письмо или перейти к следующему доступному шагу.

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

• Выход может произойти после отписки, потери соответствия условиям, покупки или другого события, которое делает оставшиеся шаги неуместными.
• Цель фиксирует успех, например завершённую покупку, но перемещает или удаляет контакт только при соответствующей настройке платформы и цепочки.
• Повторный вход можно запретить, разрешить один раз после выхода или разрешать снова при каждом новом подходящем событии.
• Эти правила задают до активации, чтобы контакты не получали устаревшие шаги и не попадали одновременно в дублирующиеся экземпляры цепочки.

Контактная политика применяет общие правила частоты и приоритета, когда один человек подходит сразу для нескольких маркетинговых писем.

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

Merge-теги подставляют отдельные значения данных, а условный или динамический контент выбирает содержимое для конкретного получателя.

• Merge-тег может вставить имя, тариф, баланс или дату продления в общий для всех текст.
• Условный контент может показать один абзац действующим клиентам, а другой пользователям пробного тарифа по результату проверки правила.
• Динамические блоки могут выбирать целые позиции из каталога или контентной ленты, а не заменять одно текстовое значение.
• Подставляемым значениям нужны форматирование и фолбэки, а условному и динамическому контенту также нужна безопасная ветка по умолчанию, если ни одно правило не сработало.

Безопасная логика шаблона проверяет известные данные получателя через явные и замкнутые условные ветки до формирования письма.

• Liquid использует конструкции if, elsif, else и endif, а AMPscript использует IF, ELSEIF, ELSE и ENDIF.
• Сравнения должны учитывать ожидаемые типы данных и явно сгруппированные логические условия, чтобы текст случайно не обрабатывался как число или логическое значение.
• Данные подписчика должны оставаться данными, а не исполняемым кодом шаблона, а вставляемые тексты и URL нужно экранировать и проверять средствами платформы.
• Каждую ветку проверяют на записях с совпадающими, несовпадающими и отсутствующими данными, потому что ошибка синтаксиса или рендеринга может затронуть всё письмо.

Шаблон должен нормализовать непригодные значения и соблюдать заданный порядок фолбэков до формирования персонализированного контента.

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

Динамический блок выбирает подходящие записи из каталога или ленты с учётом контекста получателя и правил сообщения.

• Кандидатами могут стать записи из просмотренных категорий, истории покупок, заявленных интересов или общей подборки контента.
• Фильтры соответствия исключают недоступные, просроченные, запрещённые в регионе получателя или неуместные для сообщения позиции.
• Затем правило ранжирования выбирает среди подходящих позиций по давности, релевантности или заданному порядку мерчандайзинга.
• Если ни одна запись не подходит, блок должен показать утверждённую позицию по умолчанию или исчезнуть без поломки вёрстки.

Локаль управляет языком и региональным форматированием, а часовой пояс определяет смысл локального времени отправки и датированных событий.

• Локаль может выбирать переведённый текст и форматировать даты, числа и валюты по правилам региона получателя.
• Часовой пояс преобразует правило вроде отправки в 9:00 в соответствующий момент для каждого получателя.
• Отправка в фиксированное время UTC, отправка по локальному времени получателя и отправка относительно времени события имеют разный смысл и должны быть явно обозначены.
• Для отсутствующих или некорректных значений нужны задокументированные фолбэки, а для локального расписания нужно проверить обработку перехода на летнее и зимнее время платформой.