Сопровождение рассылки и CRM
Серия разделила подписку, письма, доставку, обращение и анализ возвращения. Теперь нужно сохранить согласованное состояние и список задач сопровождения. Результатом заключительного урока станет REVIEW-01: текущий срез контактов, журнал открытых интеграций и правила пересмотра. Это локальная подготовка процесса, а не запуск рассылки или CRM.
В lesson-16 архива серии находится финальный current-subscribers.json. Все адреса и события синтетические, внешние аккаунты не используются. Программы, почтовые сеансы и тесты примеров не запускались. Учебная автоматизация остаётся выключенной, а технические части отмечены как неподготовленные.
Актуальный срез
История DATA-01 хранит прежний confirmed у R001, но одиннадцатый урок добавил остановку. Финальный срез обязан учитывать её. Поэтому R001 сейчас unsubscribed, R002 confirmed с seo/monthly, R003 expired, R004 unsubscribed. Это не изменение настоящей базы, а согласование документов модели. Старые решения остаются историей и не становятся источником актуального разрешения.
| Контакт | Текущее состояние | Редакционные сообщения |
|---|---|---|
| R001 | unsubscribed | Запрещены для lesson_updates |
| R002 | confirmed, seo/monthly | Только при остальных условиях |
| R003 | expired | Не допускаются |
| R004 | unsubscribed | Запрещены для lesson_updates |
Обращение CASE-01 связано с R001, но имеет отдельную цель support_reply. Оно не восстанавливает подборку. Передача ожидаемо assigned, уточнение prepared_local, уведомление не отправлено. Эти поля сохраняются в итоговом журнале. Если читать только адрес и последний подготовленный текст, можно ошибочно включить контакт в коммуникацию; разделённые объекты предотвращают такую подмену смысла.
Сопровождение данных
Регулярный пересмотр должен отвечать на конкретные вопросы: актуально ли обещание, соблюдаются ли запреты, откуда взяты предпочтения, нет ли неподтверждённых адресов в кандидатах? Период зависит от процесса проекта. В нашей модели выберем редакционный просмотр перед каждым выпуском и отдельный ежемесячный обзор правил. Это плановое решение, не универсальный стандарт и не выполненное расписание.
Истёкшие заявки требуют политики хранения. Нельзя сохранять всё бессрочно только потому, что файл небольшой. Но удаление тоже не должно случайно убрать необходимый запрет и привести к повторному включению адреса. Сроки и допустимые основания реального хранения зависят от проекта и применимых условий. Здесь retention_policy оставлена как отдельная открытая задача, а не заполнена непроверенным числом дней.
Предпочтения имеют источник. У R002 seo/monthly — явный синтетический выбор; отчёт о возвращении не меняет его автоматически. Один просмотр урока не становится новой темой подписки. Если будущий проект добавит рекомендации, их данные и правила будут отдельным объектом. Сопровождение должно сохранять эту границу, иначе постепенно возникнет скрытое расширение назначения контактов.
Адреса и секреты не должны попадать в публичные приложения. В нашей серии все файлы учебные, поэтому архив безопасен по происхождению данных, а не по наличию сложного шифрования. Для настоящей редакции понадобится отдельное хранилище с правами доступа и ограниченными экспортами. Открытый Markdown-контракт не заменяет защиту рабочих данных.
Интеграции и готовность
Список технических задач включает форму с обработчиком, подтверждение, страницу предпочтений, one-click endpoint, почтового провайдера и сопоставление событий доставки. Ни одна из них не создана в этой серии. HTML и text/plain готовы как локальные образцы содержания. MIME-конверт, DNS, DKIM и действующая HTTPS-служба отсутствуют. Такой журнал показывает, что требуется до возможного внешнего запуска.
Для каждой интеграции нужен конкретный первичный источник и дата сверки. Перед реальным подключением почтового сервиса проверяют его API, повтор операций, достоверность событий и смысл статусов. В этой модели провайдер не выбран, поэтому нет готовых endpoint, заголовков авторизации и выдуманных успешных ответов. Сопровождение не должно превращать общую схему в якобы проверенную интеграцию.
Требования личных Gmail отделены от проектных решений и правил других получателей. Изменение инструкции может потребовать пересмотра инфраструктуры, но не отменяет добровольный выбор и простой способ прекращения, принятые нашей моделью. Сохраните ссылку и дату чтения, затем сверяйте конкретный механизм при работе. Документирование требования не является его выполнением.
Автоматизация AUTO-01 выключена. Месячная задача R002 имеет planned_local, не queued у провайдера. Альтернативная ветка отписки из четырнадцатого урока не меняет основной текущий статус: она показывает ожидаемое поведение при другом условии. В финальном срезе это различие названо явно. Иначе учебный контрпример мог бы незаметно испортить преемственность всей серии.
Пересмотр процесса
Если обнаружена неверная тема в сегменте, сначала выясняют источник поля и правила отбора. Массовая повторная отправка «исправленного письма» не является автоматическим решением. Может быть достаточно отменить будущую задачу и исправить предпочтения по подтверждённому выбору. В настоящем инциденте решение зависит от факта и масштаба; в лаборатории действий наружу нет. Журнал фиксирует ожидаемый порядок исследования.
Если изменилось обещание, версия PROMISE-v1 остаётся основанием прежних событий. Новую версию нельзя присвоить всем контактам без выбора. Если изменилось только оформление письма, модель согласия может остаться прежней, но обе части содержания нужно просмотреть. Такие различия помогают избежать лишних повторных подтверждений и одновременно не расширять коммуникацию скрыто.
Отчёт RET-01 хранит исходную когорту и определение учебного возвращения. Финальный срез контактов не переписывает знаменатель прошлого периода. Если позже редактор сравнивает новый период, он должен указать новую группу и те же или изменённые правила. Это сохраняет честность статистики даже при смене подписок. Сопровождение данных и анализ не должны незаметно подменять друг друга.
У процесса есть ответственные: редактор за обещание и содержание, будущий технический оператор за интеграции, владелец данных за доступ и хранение. В модели последняя техническая роль ещё не назначена. Нельзя записать «всё делает система» и считать задачу завершённой. Явный список открытых работ позволяет подготовить отдельный этап реализации, когда он будет разрешён.
Финальное состояние
after.json сохраняет все шестнадцать решений, а current-subscribers.json материализует актуальные статусы. В приложении есть полные тексты, HTML и схемы, но нет отправленных писем, настоящих контактов и результатов тестов. Ожидаемый результат серии — понятная локальная система правил и редакторских образцов, которую можно расширять без смешения согласия, темы, доставки и обращения.
Для следующего проекта выберите одно конкретное усложнение, например реализацию подтверждения в разрешённой локальной среде. Используйте состояния и критерии этой серии, но не объявляйте готовыми отсутствующие обработчики. Отдельно согласуйте внешние подключения и применимые условия. Так расширение становится последовательной работой над известным пробелом, сохраняя правдивость уже подготовленных уроков и выбор читателя.