Сегменты читателей
Срез DATA-01 содержит четыре контакта с разными состояниями и предпочтениями. Теперь построим сегменты: группы, определённые понятным правилом отбора. Результат урока — два тематических кандидата и два исключения, по которым можно объяснить каждое решение. Сегментация не должна угадывать интересы человека по адресу или считать всех записанных контактов активными читателями.
Используем только синтетические данные ProfessorWeb из прошлого урока. Никакого экспорта CRM или провайдера нет. В lesson-05 архива серии сохраняем правила и ожидаемые составы групп. Письма не готовятся к реальной отправке, учебные команды не исполняются.
Допустимость раньше темы
Первый фильтр проверяет подтверждение цели lesson_updates и отсутствие запрета. Он оставляет R001 и R002. R003 исключается из-за истёкшей заявки, R004 — из-за остановки. Только после этого смотрим интересы и частоту. Такой порядок не позволяет включить отписавшегося человека в полезную ему тему и оправдать сообщение его предполагаемой заинтересованностью.
Для web-подборки с недельной частотой кандидат R001. Для seo-подборки с месячной частотой кандидат R002. Это не оценка квалификации. Выбор темы web не означает, что человек начинающий, а seo — что он предприниматель. Мы знаем только заявленные предпочтения. Дополнительные характеристики должны иметь собственный источник и назначение, иначе сегмент превращается в выдуманный портрет.
| Группа | Правило | Состав в модели |
|---|---|---|
| eligible | confirmed, цель совпадает, запрета нет | R001, R002 |
| web-weekly | eligible, web, weekly | R001 |
| seo-monthly | eligible, seo, monthly | R002 |
| excluded | Нет допустимой подписки | R003, R004 |
Состав группы — результат правила на конкретном срезе. Его нельзя хранить навечно как неизменную метку. Если R001 сменит тему, он уйдёт из web-группы. Если R002 отписался после подготовки списка, он исключается перед действием. Актуальная проверка будет особенно важна при автоматизации: старый снимок сегмента не отменяет новый выбор человека.
Известный интерес
Предпочтение из формы имеет происхождение declared. Наблюдаемый переход на статью имел бы происхождение observed. Это разные данные. Один переход может быть случайным или связанным с разовой задачей. Поэтому в нашей модели наблюдение не меняет тему подписки автоматически. Для добровольной подборки явный выбор сильнее редакторского предположения о скрытом интересе.
Если позже понадобится рекомендовать материалы по поведению, потребуется отдельно описать модель и условия использования данных. Здесь мы такого механизма не создаём. Не добавляем невидимые идентификаторы и не связываем контакты с реальными посетителями сайта. Учебный пример показывает прозрачный отбор по заявленным значениям, доступный для объяснения самому читателю.
Неизвестное значение требует отдельной обработки. У R004 темы null, но он уже исключён по остановке. Если у активного контакта темы неизвестны, нельзя автоматически включать его во все тематические подборки. Возможное действие — предложить добровольное уточнение в разрешённой коммуникации или оставить только согласованную общую категорию, если она была частью обещания. В нашей модели общей категории нет.
У сегмента есть имя и версия правила. SEG-WEB-v1 обозначает подтверждённую web-подписку с weekly. Если редактор позже включает monthly в тот же выпуск, правило меняется. Сравнение численности до и после без этой оговорки будет неверным. Изменение состава могло возникнуть из-за условия отбора, а не роста аудитории.
Частота и окно
Частота не просто поле для красивой настройки. Она ограничивает допустимое число редакционных сообщений за период. Для нашего проекта введём не больше одного учебного письма за любые семь дней для weekly и одного месячного выпуска для monthly по принятой календарной политике. Точная политика monthly будет задана выпуском; пока R002 не получает недельные сообщения. Это проектное ограничение, не правило всех провайдеров.
Сегмент отвечает на вопрос «кому тема подходит», но конкретное письмо требует ещё проверки окна. R001 может быть подходящим кандидатом и всё же ждать следующего допустимого слота. В последующих уроках приветственная серия будет использовать ту же ёмкость сообщений. Нельзя отдельно считать частоту каждого вида и в сумме отправлять человеку в несколько раз больше обещанного.
Сохраните причину исключения. Для R003 она expired, для R004 — unsubscribed. Одинаковая метка not_selected не объясняет следующий шаг. Истёкшую заявку можно возобновить новым выбором, остановленный контакт требует уважения запрета. Причина также помогает увидеть ошибку, если при будущем обновлении данных контакты неожиданно попали в группу.
В приложении нет SQL-запроса или программного фильтра, который якобы проверен. artifact.md содержит полные логические условия и ожидаемые ID. Это достаточно для редакторской модели. Техническая реализация в будущей базе должна будет учитывать те же правила и актуальное состояние, но её корректность нельзя вывести из чтения таблицы.
Изменение одного условия
Изменим сценарий: R001 выбирает seo вместо web. Его подписка остаётся confirmed, частота weekly. Он исчезает из SEG-WEB-v1, но не появляется в seo-monthly, потому что частота отличается. Возникает отдельная группа seo-weekly или отложенное редакторское решение о ней. Так пример показывает, почему тема и частота независимы и не должны подменять друг друга.
Если же R001 остановил подписку, он исчезает из всех редакционных сегментов цели lesson_updates. Для этого не нужно удалять темы и историю. Актуальный запрет проверяется раньше релевантности. Такой результат сохраняет возможность объяснить, почему контакт существует в данных, но ни одна подборка ему не разрешена.
Полезно сохранить и объяснение включения, а не только исключения. Для R001 это confirmed, цель lesson_updates, выбранный web и weekly. Если в будущем группа неожиданно расширилась, редактор сможет сопоставить основание с новым правилом. Простое число участников такой причины не показывает. В учебном artifact это одна строка на контакт, без лишнего копирования адреса. Такое представление позволяет обсудить правило отбора с редакцией, не раскрывая способ связи в каждом отчёте. Реальной адресной книги здесь нет, поэтому пример остаётся открытым учебным документом.
В after.json добавлены SEG-01, версии правил и причины исключения. Ожидаемый состав — два активных кандидата разных групп, не четыре получателя одного письма. Реальные списки и отправки отсутствуют. Следующая глава построит приветственную серию для R001, используя тот же ограниченный процесс и известное обещание.