Модуль 8 · Урок 28

Permission, lawful basis і list hygiene

Email-база — не список адрес, а набір дозволів, цілей, доказів і do-not-send правил. Тут ви побудуєте permission register, відокремите сервісні повідомлення від маркетингу та спроєктуєте hygiene без куплених баз і прихованого повторного залучення.

PurposeConsent evidenceSuppressionList hygiene

Спершу purpose і тип повідомлення

ПотікПрикладКонтроль
Security / servicePassword reset, receipt, зміна умов облікового записуЛише необхідний зміст; не маскувати promotion під сервіс
Lifecycle marketingOnboarding tips, renewal, win-backEligibility, permission/lawful basis, cap, exit та unsubscribe
CampaignNewsletter, offer, eventAudience contract, suppression, sender rules і measurement

Назва flow не визначає його правовий статус. Оцініть реальну мету, зміст, recipient expectation, jurisdiction і застосовні правила. Якщо в receipt додати рекламний блок, це не робить промо «транзакційним».

Permission register

Мінімальний запис
Subject key · data source · timestamp · notice version · purpose · message type · jurisdiction · proposed lawful basis · evidence · withdrawal method · retention · owner · legal review status.

Коли використовують consent, він має бути конкретним, поінформованим, однозначним і відкличним; pre-checked або bundled choice не є надійним доказом. Legitimate interest не вмикається прапорцем: потрібні purpose, necessity і balancing tests, reasonable expectations, а ePrivacy чи національні правила можуть окремо вимагати consent.

Не юридична консультація

Шаблон допомагає поставити правильні питання. Для реальної кампанії відповідальний owner має підтвердити jurisdiction, lawful basis, notice, retention і direct-marketing rules із кваліфікованим privacy/legal фахівцем.

Suppression — окремий контроль

Unsubscribe, complaint і permanent delivery failure повинні швидко виключати адресу з відповідного потоку. Повне видалення suppression record може дозволити випадково імпортувати адресу знову, тому зберігають мінімальний pseudonymous do-not-send ключ та scope стільки, скільки обґрунтовано політикою.

Global unsubscribeЗабороняє весь marketing у визначеному каналі.
PreferenceЗалишає лише явно вибрані теми або частоту.
ComplaintНегайна suppression та incident review.
Hard bouncePermanent failure: не повторювати автоматично.
Soft bounceТимчасова помилка: обмежена retry policy, не нескінченні повтори.
Internal exclusionTest, employee, legal hold або інший documented scope.

List hygiene без самообману

  1. Не купуйте, не scrape-те і не вгадуйте адреси; «verified» не означає willing recipient.
  2. Підтверджуйте source, timestamp, purpose і доказ до імпорту, а не після complaint spike.
  3. Відокремлюйте invalid, hard bounce, soft bounce, complaint, unsubscribe та stale engagement — це різні причини й дії.
  4. Role accounts, давні контакти та різкий reactivation потребують окремого risk review.
  5. Валідація синтаксису або mailbox existence не створює permission.
  6. Звіряйте CRM, ESP і suppression store; reconciliation має мати owner та журнал.

Практика уроку

  1. Візьміть synthetic flow і заповніть permission register.
  2. Розділіть service, lifecycle marketing і campaign messages.
  3. Намалюйте unsubscribe → suppression → ESP/CRM reconciliation.
  4. Визначте hard/soft bounce, complaint, stale і re-entry policies.
  5. Запишіть три питання для privacy/legal review та stop rule.

Завантажити Email & CRM Pack

Офіційні джерела

Практична перевірка · урок 28 з 42

Закріпіть матеріал уроку

Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.

1. З чого починається рішення про email-повідомлення?
2. Чи стає promotion сервісним, якщо його додати в receipt?
3. Що має містити permission register?