Email-рассылка СМИ

Происхождение и история предмета

В докладе Reuters Institute 2016 года Эндрю Джек описывает раннее освоение email отдельными журналистами в 1990-е годы: через списки рассылки они распространяли свои статьи среди специализированных читателей и людей, которым трудно было получить печатное издание. Далее он отмечает переход издателей от автоматических заголовков и ссылок к ручному отбору и специально написанному тексту ^{[7, с. 5]}. Это документированная линия развития практики, а не установление первого автора термина.

К 2016 году Джек разбирал уже разные редакционные решения: краткие подборки, полные тексты, собственные и внешние источники ^{[7, с. 14–15]}. В исследовании, опубликованном для конференции CHI 2023 года, Атреджа и соавторы изучили работу десяти журналистов, составлявших рассылки из материалов разных издателей. Интервью проходили в июне–августе 2022 года; это узкая качественная выборка, а не перепись мировой отрасли ^{[8, разделы 3.1–3.5]}.

Параллельно развивалось управление подпиской. В июле 1998 года RFC 2369 описал служебные поля List-Help, List-Subscribe, List-Unsubscribe и ещё три поля для списков рассылки ^[1]. Служебный заголовок — часть сообщения, которую почтовая программа обрабатывает отдельно от видимого текста. Такие поля позволяют программе предложить читателю общие команды управления списком ^[1].

В январе 2017 года RFC 8058 описал one-click — техническую отписку без дополнительного взаимодействия получателя со страницей сайта. Она использует поля List-Unsubscribe и List-Unsubscribe-Post, защищённый запрос HTTPS методом POST и проверяемую подпись DKIM ^{[2, разделы 1, 3–4]}. Это развитие инфраструктуры, а не дата рождения жанра.

С 1 февраля 2024 года Google применяет опубликованные требования к отправителям на личные адреса Gmail. Для потоков свыше 5000 сообщений в сутки набор условий шире; для маркетинговых и подписных сообщений таких отправителей требуется one-click и заметная ссылка отписки в теле ^[3]. История редакционной формы и история технической доставки связаны, но отвечают на разные вопросы: что получает читатель и как он управляет получением.

Суть и механизм

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

Обещание объясняет, какую повторяющуюся пользу получит человек. Исследование Атреджи и соавторов показывает, как некоторые участники формулировали цель на странице подписки и учитывали интересы читателей при отборе ^{[8, раздел 4.2.2]}. Формулировка «главные решения городской администрации по пятницам простыми словами» задаёт аудиторию, содержание и ритм. Без неё редакция рискует отправлять всё, что удобно ей самой, и называть это одним продуктом.

Подписка фиксирует осознанное подключение к потоку. Правила сервиса Яндекс 360 требуют отправлять рассылки тем получателям, которые явно дали согласие, и иметь заметную ссылку для отписки ^[4]. Это условия конкретного сервиса; вопрос о юридической достаточности согласия и квалификации содержания решается отдельно.

Выпуск создаётся как редакционный материал. В исследовании Атреджи и соавторов процесс включает сбор кандидатов, отбор и добавление ценности: контекста, краткого объяснения или связей между историями. Авторы подчёркивают, что шаги могут повторяться и идти в разном порядке ^{[8, раздел 4, рисунок 1]}. Для нашей рабочей схемы после отбора добавим проверку фактов и ссылок, тему письма, макет и чтение тестовой копии. Дайджест может вести на сайт, а самостоятельное письмо — содержать основную ценность внутри. Клик нельзя назначать обязательным результатом для обоих форматов.

Отправка включает техническую аутентификацию. SPF (Sender Policy Framework) сообщает, какие серверы могут отправлять почту от домена; DKIM (DomainKeys Identified Mail) добавляет проверяемую цифровую подпись; DMARC (Domain-based Message Authentication, Reporting and Conformance) задаёт политику и согласование домена ^[3]. В текущей справке Gmail для всех отправителей указан минимум SPF или DKIM, а для отправляющих более 5000 сообщений в сутки на Gmail — SPF, DKIM и DMARC ^[3]. Это требования конкретной сферы, а не утверждение об одинаковых правилах каждого провайдера.

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

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

Виды и классификации

У Джека в разделе о формате выделены семь осей различий: автоматический или ручной отбор; краткое изложение или полный текст; наличие или отсутствие ссылок; собственные или сторонние источники; формальный или разговорный стиль; только текст или текст с изображениями; исключительная доставка по email или распространение на нескольких площадках ^{[7, с. 14–15]}. Это оси сравнения, поэтому одно письмо одновременно занимает позицию по каждой из них.

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

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

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

Как применяется на практике

Учебный пример. Региональное СМИ запускает письмо «Что изменится в городе на следующей неделе». Обещание: каждую пятницу объяснять решения, которые влияют на транспорт, коммунальные услуги и школы. Редактор выбирает только события с подтверждённой датой и ссылкой на первичный документ.

В выпуск входит сообщение о временном закрытии моста. Автор указывает участок, начало ограничения, предполагаемое окончание и маршрут объезда. Если срок окончания в документе не назван, письмо прямо говорит об этом. Уверенная догадка сделала бы выпуск короче, но менее надёжным.

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

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

Для российских отправителей дополнительно проверяются правила выбранного сервиса. Яндекс предупреждает, что жалобы пользователей и некачественная база могут привести к остановке рассылки или блокировке ^[4]. Это последствие условий платформы; оно не заменяет требований закона и не доказывает качество содержания.

Как измерить или проверить

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

Доля уникальных получателей с переходом:

где $U_c$ — число уникальных получателей, совершивших хотя бы один переход, а $D$ — число доставленных писем. Единица — процент доставленных писем.

Учебный расчёт. Доставлено 1000 писем, по ссылкам перешли 50 разных получателей: $CTR_d = 50 / 1000 \times 100\% = 5\%$. Это условный результат одного выпуска, а не отраслевой ориентир. Если сервис считает все клики, а не людей, числитель будет другим.

Доля отписок:

где $U_o$ — число обработанных запросов на отписку после выпуска. При 8 отписках из 1000 доставленных писем $UR = 0{,}8\%$. Показатель фиксирует действие, но сам по себе не объясняет, вызвано ли оно темой, частотой или изменившейся потребностью читателя.

Чистое изменение базы за период считают как новые подтверждённые подписки минус завершённые отписки. Если добавилось 120 адресов, а ушло 80, чистое изменение равно +40 адресов. Однако эта сумма скрывает оба потока, поэтому в отчёте сохраняют все три числа. Это упрощённый баланс: если редакция также удаляла недействительные адреса или объединяла дубли, изменение общего размера базы потребует дополнительных слагаемых. При нуле доставленных писем обе доли не определены: делить на ноль нельзя, и отчёт должен показать отсутствие расчёта, а не нулевой процент.

Метрику открытий интерпретируют осторожно. Apple сообщает, что Mail Privacy Protection может загружать удалённое содержимое в фоне при получении письма, а не при его просмотре ^[6]. Если система засчитывает такую загрузку пикселя как открытие, техническое событие не доказывает чтение человеком. Это не делает всю аналитику бесполезной, но ограничивает смысл конкретного показателя.

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

Технический контроль one-click тоже отдельный. RFC 8058 требует сочетания служебных полей, HTTPS URI, POST и покрывающей их DKIM-подписи ^[2]. Ссылка «отписаться» внизу письма нужна читателю, но её наличие не доказывает реализацию протокола.

Ошибки, ограничения и спорные вопросы

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

Вторая — менять ритм без объяснения. Подписка на еженедельный выпуск не означает очевидного согласия на несколько писем в день. Для учебного проекта это повод заново объяснить читателю ритм и проверить условия подписки, а не заранее приписать изменение метрик одной причине.

Третья — считать аутентификацию доказательством согласия. SPF, DKIM и DMARC помогают проверить происхождение сообщения и политику домена ^[3]. Они не отвечают на вопрос, соглашался ли конкретный адресат на конкретный поток.

Четвёртая — оптимизировать только открытия. Защита приватности, блокировка изображений и способы загрузки контента делают этот сигнал неоднозначным ^[6]. Переходы тоже не универсальны: самостоятельный выпуск может быть полезен без клика.

Пятая — механически переносить правила Gmail или Яндекс 360 на все почтовые системы. У каждой документации есть собственная сфера действия. Текущие требования нужно повторно проверять перед изменением инфраструктуры или запуском нового потока. Профильные исследования также имеют предел переноса: интервью 2022 года касались англоязычных подборок из нескольких издателей, поэтому не описывают автоматически все письма российских СМИ ^{[8, раздел 3.5]}.

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

Правовой аспект

Часть 1 статьи 18 Федерального закона от 13.03.2006 № 38-ФЗ «О рекламе» в редакции от 04.08.2026 устанавливает: распространение рекламы по сетям электросвязи допускается только при предварительном согласии адресата. Обязанность доказать получение согласия лежит на рекламораспространителе; по требованию адресата распространение рекламы ему должно быть немедленно прекращено ^[5].

Эта норма применяется к рекламе, распространяемой по сетям электросвязи ^[5]. Вопрос, является ли конкретный выпуск рекламой, в этой статье не решается. Правила Яндекс 360 требуют явного согласия для использования своего сервиса ^[4], но условия платформы и федеральный закон — разные основания.

При обработке персональных данных на основании согласия действует также часть 1 статьи 9 закона от 27.07.2006 № 152-ФЗ, в редакции от 26.07.2026: согласие должно быть конкретным, предметным, информированным, сознательным и однозначным, а также оформленным отдельно от иных подтверждаемых документов. Часть 3 возлагает доказательство согласия либо иных предусмотренных законом оснований на оператора ^[10]. Требование об отдельном оформлении введено статьёй 5 закона от 24.06.2025 № 156-ФЗ и действует с 01.09.2025 ^[11]. Это не означает, что для всякой обработки единственное основание — согласие; правомерность конкретной базы и рекламных включений требует отдельной оценки.

Частые вопросы

Связанные термины

• Email-маркетинг
• Подписка на СМИ
• Контент-план
• UTM-метки
• Отток подписчиков
• CTR (кликабельность)