Як маркетинговим командам розгортати застосунки, створені ШІ, не розкриваючи дані підписників

«Хтось із маркетингової команди хоче створити сайт. Це не інженер, і він, імовірно, майже не має досвіду чи знань із безпеки», — розповів дослідник безпеки Джоел Марголіс виданню 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 зі спеціальних аудиторій використовує значення, хешовані 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 підтверджує можливість надсилати маркетингові листи компаніям. Для країн ЄС і Канади зверніться до юриста.