Как развести сервисные и рекламные сообщения в настройках платформы

Письмо о доставке должно прийти даже тому, кто отказался от рекламных подборок. Но что делать, если к номеру заказа добавили блок «Купите ещё со скидкой»? В интерфейсе сообщение по-прежнему называется transactional, то есть транзакционным, а по содержанию уже решает две разные задачи.

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

Классифицируйте сообщение до выбора маршрута

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

Определение рекламы в статье 3 российского закона о рекламе связано с назначением распространяемой информации. Поэтому внутреннее название «сервис» не освобождает команду от оценки фактического содержания.[1]

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

Сформируйте отдельные правила допуска

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

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

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

Разведите технические потоки без ложного чувства защиты

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

Google в рекомендациях отправителям отдельно предостерегает от смешивания рекламного содержания с сообщениями о транзакциях.[3] Практическое решение CRM Lab — хранить рекламные вставки в управляемых компонентах и запрещать их использование в утверждённых сервисных шаблонах без повторного согласования.

Иначе команда один раз проверит письмо, а через месяц общий блок рекомендаций автоматически появится в подтверждении оплаты. Контроль должен отслеживать не только файл шаблона, но и его динамические зависимости.

Условный пример: чек с рекламным хвостом

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

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

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

Проверьте обходы и исключения

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

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

Как принимать изменения

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

Итоговая таблица для команды содержит назначение сообщения, допустимые события, основание, проверяемые ограничения, шаблон, технический маршрут и ответственного. Тогда спор «это сервис или реклама» перестаёт решаться в последнюю минуту оператором рассылки.

Источники

[1] Российская Федерация. Федеральный закон от 13.03.2006 № 38-ФЗ, статья 3. Действующая редакция; текст нормы в СПС «КонсультантПлюс». Проверено 22.09.2026.

[2] Российская Федерация. Федеральный закон от 13.03.2006 № 38-ФЗ «О рекламе», статья 18. Действующая редакция; текст нормы в СПС «КонсультантПлюс». Проверено 22.09.2026.

[3] Google. Email sender guidelines. Справка Gmail; требования и рекомендации для отправителей на личные адреса Gmail. Проверено 22.09.2026.