Как маркетинговым командам развёртывать приложения, созданные ИИ, не раскрывая данные подписчиков

«Кто-то из маркетинговой команды хочет создать сайт. Это не инженер, и у него, вероятно, практически нет опыта или знаний в области безопасности», — рассказал исследователь безопасности Джоэл Марголис изданию Wired. В том же материале Wired описывается, как компания RedAccess обнаружила более 5 000 приложений, созданных методом вайб-кодинга, практически без защиты и аутентификации; около 40 процентов этих приложений раскрывали конфиденциальные данные. Wired не удалось подтвердить подлинность изученных персональных или корпоративных данных.

В созданных ИИ приложениях для маркетинга эта проблема приобретает особую форму. Полезные инструменты — конструктор сегментов, панель кампаний, анализатор A/B-тестов, синхронизация аудиторий — подключены к списку подписчиков, а часто и к рекламному аккаунту.

Кратко (TL;DR)

• Каждому API-ключу почтовой платформы и токену рекламного аккаунта предоставляйте только минимальный доступ, необходимый инструменту, и храните их в серверном коде. У Marketing API Mailchimp нет типа ключа с более узкими правами, поэтому для задачи только на чтение вместо ключа используйте ограниченный экспорт лишь необходимых данных.
• Почтовая платформа остаётся достоверным источником статуса подписки. Инструмент никогда не подписывает повторно тех, кто отказался от рассылки, передаёт запросы на отписку платформе и включает рабочую ссылку для отписки в каждое маркетинговое письмо, которое отправляет самостоятельно.
• Хешированный список для пользовательской аудитории всё равно содержит персональные данные: заранее определите, что передаётся рекламным платформам и ИИ-сервисам, и обеспечьте отражение каждой отписки в рекламной аудитории.
• GDPR регулирует хранение и использование списка: уведомление об утечках и безусловное право возражать против маркетинга. ePrivacy/PECR, CAN-SPAM или CASL регулируют отправку писем, даже когда их отправляет внутренний инструмент.

Ошибки развёртывания, которые раскрывают данные подписчиков или нарушают условия согласия

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

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

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

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

Каждая строка основана на документации самой платформы: справке Mailchimp об API-ключах, правах API-ключей SendGrid, руководстве Klaviyo по аутентификации и документации Mailgun по API-ключам. Права Listmonk описаны ниже в разделе о Listmonk.

Инструмент получает ключ с минимально допустимыми для задачи правами либо не получает его вовсе. В Mailchimp задачу только на чтение — отчёт или подсчёт сегмента — лучше решать встроенными отчётами платформы либо ограниченным экспортом, который выполняет владелец аккаунта и который содержит лишь необходимые поля. Цена этого решения — время человека и актуальность данных лишь на момент экспорта; задачи изменения и отправки передают ИТ-команде или оставляют в Mailchimp. На других платформах, например ActiveCampaign или Brevo, сначала ищите вариант ограниченного ключа.

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

Найди в этом проекте все API-ключи, токены доступа, пароли и секреты для нашей почтовой платформы — Mailchimp, Klaviyo, SendGrid, Mailgun, Listmonk или любой другой — и любой рекламной платформы: Meta, Google Ads, LinkedIn или иной. Проверь код, файлы окружения и историю репозитория локальным сканером секретов или одобренным ИТ-командой методом. Никогда не отправляй внешнему ИИ-сервису исходные значения секретов, содержимое файлов окружения или историю с учётными данными. Передавай ИИ только результаты со скрытыми секретами, включая расположение файлов и тип найденных учётных данных. Для каждого укажи:

- файл и строку

- записано ли значение в коде или читается из переменной окружения

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

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

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

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

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

Проверка: откройте инструмент, нажмите F12, выберите вкладку Network и используйте инструмент так, как будет пользоваться команда, проверяя домен каждого запроса. Прямое обращение браузера к закрытому API почтовой платформы — тревожный признак, но один адрес назначения не доказывает раскрытие секрета. Проверьте заголовки запросов и код на наличие закрытых учётных данных, не копируя их значения в чат ИИ. Публичные запросы клиентского SDK отличаются: они могут законно использовать публичные идентификаторы вместо секретных API-ключей. В Klaviyo запросы к a.klaviyo.com/client/ используют публичный ключ и уместны в браузере, а браузерный запрос к a.klaviyo.com/api/ требует изучения, поскольку эта конечная точка обычно требует аутентификации закрытым ключом. Установите, действительно ли передавались закрытые учётные данные.

Остальное делает человек: создаёт ограниченный ключ из аккаунта, не принадлежащего одному человеку — Mailchimp удаляет API-ключи пользователя при отзыве его доступа, — называет ключ по имени инструмента, поскольку Mailchimp рекомендует отдельный ключ для каждой интеграции, и с помощью ИТ-команды сохраняет его в принятом для ключей инструмента месте. При плановой ротации переключите инструмент на новый ключ до отзыва старого: отозванный ключ Mailchimp нельзя активировать снова. Уже скомпрометированный ключ отзовите немедленно и замените. Учитывайте и срок действия: API-ключи Mailchimp, созданные 22 июня 2026 года или позже, истекают через год после создания.

Дайте токену рекламного аккаунта только те права, которыми пользуется инструмент

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

Однако такой токен не возвращает список подписчиков, загруженный в пользовательскую аудиторию. Руководство Meta по Custom Audiences использует значения, хешированные SHA-256, и при добавлении, и при удалении людей: это одностороннее преобразование каждого адреса, результат которого платформа сравнивает со своими записями. Ни одна документированная конечная точка не возвращает читаемый список из существующей аудитории.

Справочник разрешений Meta описывает каждое разрешение и советует разработчикам выбирать только необходимые приложению. Каждый инструмент получает отдельный токен системного пользователя — так Meta называет аккаунт в Business Manager, используемый программой, — назначенного только рекламному аккаунту, с которым работает инструмент. Не используйте в инструменте личный токен входа разработчика, а токен системного пользователя храните на сервере, как почтовый ключ; такой же учёт нужен для любого доступа к Google Ads или LinkedIn.

Перечисли все вызовы этого инструмента к Marketing API Meta, Google Ads и любой другой рекламной платформе, включая вызовы через вспомогательные библиотеки и SDK. Для каждого укажи:

- файл и строку

- конечную точку или метод SDK

- метку: REPORT — чтение показателей или расходов; MANAGE — создание или изменение кампаний, объявлений, бюджетов или аудиторий; LEADS — чтение ответов лид-форм

- разрешение платформы, необходимое для этой метки

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

Проверка: проверьте токен панели в инструменте отладки токенов Meta, который показывает разрешения токена, и сравните их с метками из запроса. У токена панели отчётности должно быть ads_read и не должно быть прав управления аккаунтом; метка MANAGE или LEADS у отчётного инструмента — выявленная проблема. Затем в настройках Business убедитесь, что инструмент использует токен своего системного пользователя, а не личный токен разработчика.

Закройте публичный адрес и показывайте строки подписчиков только администраторам списка

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

Вторая сторона вопроса — что каждый видит после входа. Панель кампаний должна показывать показатели на уровне кампаний: долю открытий, долю кликов, результаты A/B-тестов и размеры сегментов. Стоящие за ними строки подписчиков — каждый адрес со сведениями о согласии и историей взаимодействий — являются персональными данными.

Правильно обезличенные агрегированные показатели обычно не являются персональными данными, но небольшие сегменты или подробные разрезы всё ещё могут позволять идентифицировать людей. Даже анонимные показатели могут раскрывать конкурентную информацию компании, а анализатор A/B-тестов, хранящий открытия и клики по каждому человеку, также содержит персональные данные. Команда видит агрегаты; строки видят только управляющие списком, а сервер обеспечивает это при каждом запросе.

Перечисли все поля базы данных, экранов, экспортов и ответов API этого приложения, содержащие персональные данные подписчиков: электронный адрес, имя, телефон, почтовый адрес, IP-адрес, местоположение, статус подписки, источник и время согласия, дату подписки, статус отписки, открытия и клики каждого человека. Для каждого поля укажи экраны и экспорты, где оно отображается. Отмечай всё, в чём не уверен, вместо догадок.

Затем добавь две роли, получаемые из вошедшего аккаунта и проверяемые сервером для каждой страницы, экспорта и маршрута API:

- администратор списка: видит строки подписчиков и выполняет экспорт

- маркетолог: видит только показатели кампаний, количество в сегментах и результаты A/B-тестов, без персональных строк и экспортов

Любой другой доступ отклоняй ответом «доступ запрещён» (403). Укажи, какая проверка защищает каждую страницу и маршрут.

Зашифрованы ли сохранённые данные на диске — вопрос к ИТ-команде; ИИ-инструмент не может подтвердить это, читая код.

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

Оставьте отписки и записи о согласии почтовой платформе

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

1. Почтовая платформа — достоверный источник статуса подписки. Инструмент читает этот статус и никогда не подписывает повторно и не перезаписывает существующего подписчика. Он может передать явный запрос на отписку через предназначенный для этого процесс платформы.
2. Массовый импорт или синхронизация не заменяют существующие записи подписчиков и не перезаписывают их данные о подписке и согласии. Проверенный инструмент может обновлять явно одобренные поля, например метки, не меняя статус подписки. Новые подписки поступают через собственную форму или путь импорта платформы, чтобы действовал её процесс получения согласия; собственная форма инструмента после проверки может добавлять новых подписчиков с источником, временем и формой, но никогда не подписывает существующий контакт повторно и не перезаписывает его сведения о подписке или согласии.
3. При любой отправке или экспорте инструмент читает статус с платформы в этот момент, а не из собственной копии. Экспорт исключает отписавшиеся и заблокированные для отправки контакты либо помечает их как список «не отправлять», который никогда не используется для рассылки.
4. Поля согласия — источник, время, форма или способ — сохраняются без изменений в любой копируемой записи, либо инструмент не копирует их и не утверждает, что располагает ими.

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

- изменить статус подписки существующего подписчика

- перезаписать существующие записи подписчиков

- включить отписавшиеся или заблокированные для отправки контакты

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

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

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

Проверка: добавьте тестового подписчика в почтовой платформе, затем отпишите его там. Запустите синхронизацию, конструктор сегментов и экспорт инструмента. На платформе тестовый подписчик остаётся отписанным; в экспорте инструмента он отсутствует или помечен «не отправлять»; ни в одном сформированном инструментом списке отправки его нет.

Отправляйте через почтовую платформу или сначала создайте механизм отписки

Инструмент повторного вовлечения, рассылающий письма напрямую через SMTP-аккаунт или API транзакционных писем, не получает то, что почтовая платформа добавляет в маркетинговые письма, — ссылку для отписки, почтовый адрес и проверку списка исключений, — если его код не реализует каждый элемент. Решение — доверить отправку платформе или Listmonk, а инструменту оставить создание сегмента или запуск кампании платформы. Если инструмент должен отправлять самостоятельно, это инструмент отправки, который следующий раздел направляет к ИТ-команде.

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

При массовых рассылках ссылки в подвале может быть недостаточно. Gmail требует от отправителей 5 000 и более сообщений в сутки на личные аккаунты Gmail поддерживать отписку в один клик по RFC 8058 для маркетинговых писем и писем по подписке. Это означает добавление заголовков List-Unsubscribe и List-Unsubscribe-Post наряду с видимой ссылкой для отписки. Конечная точка отписки в один клик должна обрабатывать POST-запрос; простое открытие URL через GET не должно отписывать человека. Перед отправкой в таком масштабе попросите ИТ-команду проверить эти требования.

Добавь ссылку для отписки в каждое отправляемое инструментом маркетинговое сообщение и реализуй за ней конечную точку отписки.
Если инструмент подпадает под требования Gmail к массовым отправителям, также реализуй заголовки отписки в один клик по RFC 8058, покрытые действительной подписью DKIM, и конечную точку на основе POST. Никогда не запускай отписку только из-за открытия URL. Все сомнения передай ИТ-команде на проверку.
Когда конечная точка отписки получает действительный запрос — переход по ссылке, отправку формы или API-вызов:

- немедленно добавь адрес в список исключений, хранящийся отдельно от таблиц подписчиков

- запиши время и канал поступления запроса

- если список хранится в нашей почтовой платформе, также сообщи ей об отписке адреса

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

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

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

Заранее решите, что передаётся рекламным платформам и ИИ-инструментам

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

Meta и Google могут сопоставлять клиентские аудитории по контактным идентификаторам, хешированным SHA-256. Data Manager API Google требует нормализовать и хешировать электронные адреса и телефоны до передачи, тогда как некоторые загрузки через интерфейс Google Ads могут выполнять хеширование в процессе загрузки. Хеширование позволяет платформе сопоставить адрес с профилем; оно не делает человека анонимным — см. FAQ.

Для новых интеграций Google Customer Match проверьте поддерживаемый API загрузки до разработки синхронизации. С 1 апреля 2026 года Google ограничивает старые методы загрузки Customer Match для новых пользователей и направляет такие интеграции в Data Manager API.

Условия Meta для аудиторий из клиентских списков требуют от рекламодателя гарантировать наличие необходимых прав, разрешений и правового основания для передачи данных. Политика Google Customer Match требует раскрывать передачу в политике конфиденциальности и получать согласие там, где этого требует закон.

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

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

Любой ИИ- или аналитический сервис, получающий данные подписчиков, должен быть одобрен компанией. Перед передачей персональных данных выясните, выступает ли поставщик обработчиком или самостоятельным контролёром, и обеспечьте надлежащие договорные гарантии, включая соглашение об обработке данных, когда оно требуется.

Проверь все исходящие вызовы инструмента: почтовые платформы, рекламные платформы, включая загрузки аудиторий, API ИИ — OpenAI, Anthropic или другие, — аналитические инструменты и вебхуки. Для каждого вызова точно перечисли поля подписчиков в теле запроса или URL. Укажи, какие вызовы могут выполнить задачу с меньшим количеством полей или вообще без данных подписчиков. В конце перечисли по имени каждый внешний сервис для сверки с одобренными поставщиками.

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

Для каждого пути инструмента, загружающего контакты в Meta, Google Ads или другую рекламную платформу:

- до загрузки хешируй электронные адреса и телефоны с помощью SHA-256 на сервере по правилам нормализации каждой платформы

- загружай только контакты из [сегмента, одобренного вашей компанией для рекламного сопоставления]

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

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

- регистрируй каждую загрузку и удаление со временем, аудиторией, количеством контактов и пользователем или заданием, запустившим действие

Сообщи, что изменено, и отметь всё, в чём не уверен.

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

Действия инструмента со списком определяют место его запуска

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

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

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

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

Серверную часть следует передать ИТ-специалистам, назначив одного ответственного за сервер и ключи. Инструмент работает на VPS — арендованном сервере, полностью контролируемом командой, — под управлением средства развёртывания вроде Coolify или Dokploy, которое запускает приложение из его кода и хранит переменные окружения, включая ключи платформ.

Частную сеть обеспечивает Tailscale: его быстрее настроить, но он зависит от собственного координационного сервиса, который может заменить Headscale, — либо полностью самостоятельно размещённый WireGuard. Корпоративный вход — единый вход с аккаунтом компании — дают Authentik или Keycloak, а обратный прокси Caddy или Nginx Proxy Manager добавляет HTTPS везде, где инструмент доступен из интернета.

Перенос почтового движка в Listmonk

Другой путь вместо ограниченных ключей текущей платформы убирает ключ коммерческой платформы, перенося список и отправку в самостоятельно размещённый менеджер списков. Listmonk версии v4.0.0 и новее позволяет каждому инструменту иметь собственного API-пользователя с ролью, ограниченной списками, с которыми работает инструмент.

Инструмент только для чтения получает просмотр своих списков без отправки; campaigns:send и tx:send для транзакционных сообщений получает только инструмент отправки. Три особо опасных разрешения не должны входить в роли ограниченных инструментов: lists:get_all и lists:manage_all, отменяющие ограничения ролей отдельных списков, и subscribers:sql_query, которое, как предупреждает документация Listmonk по ролям и разрешениям, позволяет «запрашивать все списки и подписчиков напрямую из базы данных, обходя отдельные права списков и подписчиков». Также проверьте широкие разрешения subscribers:get_all, campaigns:get_all и campaigns:manage_all, прежде чем считать инструмент ограниченным отдельными списками. Каждому API-пользователю выдавайте только необходимые задаче права. Listmonk предназначен для кампаний, а не многошаговой автоматизации — когда Listmonk не подходит; такую автоматизацию на сервере того же типа обеспечивает Mautic.

Цена — постоянная работа: команда отвечает за аутентификацию домена отправки — SPF, DKIM и DMARC, — SMTP-реле для доставки писем, обновления, резервные копии и доставляемость. Если список небольшой, некому отвечать за сервер или репутация отправки и автоматизации текущей платформы выполняют важную для команды работу, лучше остаться на платформе с ограниченными ключами.

Оба пути требуют сервера с ответственным владельцем, на котором работают средство развёртывания и частная сеть, а при самостоятельном размещении ещё и Listmonk с SMTP-реле. Наш Linux VPS предоставляет root-доступ, а Listmonk, Mautic, Tailscale, WireGuard и Authentik развёртываются как приложения в один клик. Тогда ИТ-специалисты тратят время на настройку и проверку вместо установки; своевременное обновление всего остаётся задачей команды.

Доступны Франкфурт и Амстердам в ЕС, Лондон в Великобритании и несколько городов США; выбранное место определяет, где находятся инструмент и любая копия списка, а в Listmonk — сам список. Местоположение — исходные данные для обсуждения с DPO, а не замена обсуждения; само по себе оно не обеспечивает соответствие требованиям.

Согласие и антиспам-требования для маркетинговых писем

GDPR для списка подписчиков

GDPR не требует согласия как основания обработки для прямого маркетинга: пункт 47 преамбулы говорит, что такая обработка «может рассматриваться как осуществляемая в законных интересах». Если же маркетинг опирается на согласие, статья 7 требует, чтобы компания «могла продемонстрировать» согласие каждого человека, и чтобы отозвать согласие было так же легко, как дать его. Именно для этого почтовая платформа хранит источник и время согласия.

Более строгое правило содержит статья 21 GDPR. Независимо от основания человек может в любой момент возразить против прямого маркетинга, включая связанное с ним профилирование, после чего «персональные данные больше не должны обрабатываться для таких целей». В маркетинге нет проверки баланса интересов, в отличие от других возражений по той же статье. Для этого инструмента безопаснее по умолчанию распространять общее возражение против прямого маркетинга на все маркетинговые применения данных человека: список отправки, сегменты инструмента и рекламные аудитории. Отписка в отдельном канале может иметь более узкую сферу, поэтому компания должна определить правила предпочтений вместе с ответственным за конфиденциальность и обеспечить надлежащее выполнение каждого запроса.

Утёкший или ошибочно изменённый список может означать нарушение безопасности персональных данных. Статья 33 требует уведомить надзорный орган — национальный регулятор защиты данных — без неоправданной задержки и, по возможности, в течение 72 часов после обнаружения, кроме случаев, когда нарушение вряд ли создаёт риск для людей. В Великобритании эквивалентный закон — UK GDPR, за соблюдением которого следит ICO.

Законы об отправке: ePrivacy и PECR, CAN-SPAM и CASL

Правила ePrivacy ЕС и британские PECR требуют предварительного согласия на маркетинговые письма физическим лицам с узким исключением soft opt-in для существующих клиентов. В Великобритании также есть отдельное исключение soft opt-in для благотворительных целей с определёнными условиями; эта статья посвящена коммерческому маркетингу. Канадский CASL требует явно выраженного или подразумеваемого согласия. Американский CAN-SPAM не требует согласия на отправку; он требует рабочего отказа, исполняемого в течение 10 рабочих дней, а также точных данных отправителя и почтового адреса в каждом сообщении.

Исключение soft opt-in в статье 13 Директивы ePrivacy охватывает контактные данные, полученные при продаже и используемые для собственных похожих продуктов, с бесплатной возможностью отказаться при сборе и в каждом сообщении. Британская версия — правило 22 PECR, разъяснённое в руководстве ICO по email-маркетингу. Статья 13 также запрещает маркетинговые письма, скрывающие отправителя или не содержащие действительного адреса для запросов об отказе; правило 23 PECR устанавливает такой же запрет в Великобритании.

Суммы CAN-SPAM взяты из руководства FTC по CAN-SPAM, которое также указывает, что адреса отказавшихся нельзя продавать или передавать, кроме передачи компании, нанятой для помощи в соблюдении CAN-SPAM. Правила CASL приведены в разделе 6 CASL и разделе 11, а санкции — в обзоре CASL от ISED.

Часто задаваемые вопросы

Применяется ли GDPR к инструменту рассылки, который я создал самостоятельно?

Ответ зависит от того, где работает компания и чьи данные хранит инструмент, а не от способа его создания. Согласно статье 3, GDPR распространяется на компании, учреждённые в ЕС, и на компании за его пределами, которые предлагают товары или услуги людям в ЕС либо отслеживают их поведение там. Применимость к конкретной компании должен определить её DPO.

Что произойдёт, если утечёт наш API-ключ Klaviyo?

Обладатель ключа Full Access может менять список; ключ Read-Only позволяет только просматривать его. Создайте замену лишь с областями доступа, которыми пользуется инструмент: Klaviyo не позволяет позже добавить область доступа в существующий ключ, поэтому выберите их сейчас. Немедленно отзовите утёкший ключ, переключите инструмент на замену и проверьте несанкционированные экспорты или изменения списка. Если список могли прочитать, рассматривайте это как возможное нарушение GDPR.

Остаётся ли хешированный список электронных адресов персональными данными?

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

Действуют ли те же правила для маркетинговых писем B2B?

Не везде. По данным FTC, CAN-SPAM не предусматривает исключения для писем между компаниями. Правило PECR об электронной почте охватывает физических лиц, а ICO подтверждает возможность отправлять маркетинговые письма компаниям. Для стран ЕС и Канады обратитесь к юристу.