В начале моя система описывалась вот так:
доставленное письмо на электронный ящик покупателя и желание покупателя просмотреть письмо, перейти в магазин и купить товар.
Обсуждая с ИИ я попросил агента написать цепочку применений паттернов из FPF и итоговый результат. Дальше укороченный ответ с моим пониманием каждого применения паттернов.
1. Восстанавливаем предмет проекта — A.15.6
Нашли систему-кандидата как проектная работа предназначена изменить существующую операционную систему email-рассылок интернет-магазина
2. Уточняем слово «механизм» — A.6.1
Я говорю о правилах выполнения операции, о сущности, которая реализует эти правила, или о конкретном выполнении?
В данном случае интерес представляет работающая операционная сущность, которая выбирает адресатов, инициирует отправку и обрабатывает события. Поэтому далее используем название операционная система email-рассылок
3. Проверяем, является ли кандидат системой — A.1.SCR
Сначала нужно выяснить, не обозначает ли фраза работу, метод, документ, механизм, результат или отношение. Только если решение действительно зависит от системности сущности, выполняется полный тест A.1
Этот паттерн является маршрутизатором к тому какой паттер нужно дальше использовать:
«Работающий механизм рассылки»
│
▼
A.1.SCR: что именно здесь названо?
│
├─ декларация операций? → A.6.1
├─ работа рассылки? → A.15.1
├─ отдельное письмо? → публикация/доставка
└─ действующий контур? → выполнить тест A.1
4. Проверяем конструктивные признаки системы — A.1
- Точная сущность. Эксплуатируемый контур email-рассылок конкретного интернет-магазина, а не абстрактная технология email и не отдельная кампания.
- Составляющие. Исполняемые компоненты выбора аудитории, планирования и запуска отправки, интеграции с почтовым провайдером, хранения состояния кампаний и приёма событий взаимодействия. Конкретный перечень должен подтверждаться устройством существующей реализации.
- Сборка. Компоненты связаны потоками данных и управлением так, что совместно выполняют рассылку от выбора адресата до регистрации результата взаимодействия.
- Переидентификация. Изменение шаблона, правила сегментации или версии одного компонента обычно сохраняет ту же систему; полная замена операционного контура или изменение принятого правила идентичности может означать систему-преемника.
- Свойство целого. Способность выполнять управляемый цикл email-коммуникации отсутствует у любого отдельного компонента.
- Большее целое. Система рассылок может быть подсистемой операционной системы маркетинга или интернет-магазина, взаимодействуя с каталогом, профилями покупателей и оформлением заказов.
Из чего ЛЛМ решила, что
операционная система email-рассылок является обоснованным кандидатом на `U.System` и систему, представляющую интерес для проекта
5. Отделяем систему от требуемого изменения снаружи — A.1.STM
Паттерн предлагает начинать с результата, который должен возникнуть за границей системы, и только затем обосновывать выбор системы и её внутренней архитектуры.
В нашем случае:
- доставка письма — результат взаимодействия системы с почтовой инфраструктурой;
- покупатель и его состояние не обязаны быть частью системы рассылок;
- открытие письма, переход и покупка происходят за выбранной границей;
- проект изменяет систему рассылок ради гипотезы об изменении внешнего поведения.
Промежуточный вывод: реакция покупателя не должна входить в определение состава системы. Она описывает ожидаемое внешнее изменение и основание выбора системы проекта.
6. Проводим рабочую границу — B.1.2
Для текущего проектного решения принимается следующая рабочая граница.
Скопировал из ответа ЛЛМ, но прочесть занятно.
Внутри системы:
- настроенный для интернет-магазина операционный контур Mindbox: проект или пространство клиента, его рабочая конфигурация и операционное состояние;
- хранящиеся в этом контуре профили покупателей и история полученных Mindbox событий о действиях покупателей до рассылки;
- настроенные в Mindbox правила выделения сегментов и выбора адресатов;
- настроенные в Mindbox рассылки, их параметры, триггеры и расписание;
- выполняемая Mindbox отправка писем выбранным адресатам;
- приём и связывание в Mindbox событий доставки, открытия и перехода с профилем покупателя и конкретной рассылкой;
- приём сведений о действиях покупателя после рассылки, включая сведения о покупке;
- выполняемый в Mindbox подсчёт показателей и результатов рассылки;
- настройки интеграционного обмена, определяющие, какие события интернет-магазин передаёт в Mindbox и как они связываются с покупателем и рассылкой.
Снаружи системы:
- маркетолог как оператор системы;
- покупатель;
- почтовый провайдер и почтовый клиент покупателя;
- витрина, корзина, оформление заказа и другие системы интернет-магазина, в которых происходят отслеживаемые действия покупателя;
- общая платформа Mindbox, её инфраструктура и организация-поставщик в той мере, в какой они обеспечивают наш настроенный контур, но не изменяются данным проектом.
Границу пересекают:
- команды и параметры рассылки, которые маркетолог вводит в настроенный контур Mindbox;
- идентификаторы, профильные данные и события действий покупателя до отправки, передаваемые системами интернет-магазина в Mindbox;
- письмо, передаваемое из Mindbox через почтовую инфраструктуру покупателю;
- события доставки, открытия и перехода, возвращаемые в Mindbox;
- события действий и покупки после рассылки, передаваемые системами интернет-магазина в Mindbox;
- рассчитанные Mindbox показатели и результаты, предоставляемые маркетологу или внешней аналитической системе.
Покупатель взаимодействует с системой, но не является её частью; покупка также не является частью системы — это внешнее событие, сведения о котором возвращаются через границу.
7. Не называем желаемое изменение уже произошедшим — A.3.4
Необходимо назвать продолжающийся изменяемый предмет, границы изменения, различающиеся факты до и после и правило непрерывности.
В определении следует писать «ожидаемый внешний эффект» или «цель изменения», а не утверждать состоявшееся изменение реакции покупателей.
8. Формируем набор характеристик результативности — C.25 и C.16
Успех системы описывается измеряемыми внешними характеристиками, но эти метрики не становятся частями системы и сами не доказывают причинное влияние рассылки.
В этом пункте пришлось поработать с нейронкой, так как она выделяла незначительные показатели результативности исключив из рассмотрения менеджера магазина, который работает с нами как с агентством.
9. Разделяем атрибуцию и причинный эффект — C.28
Тут пространные рассжудения про A/B-тестирования, но суть понятна - мы хотим понять как мы можем убедиться, что именно наша система внесла эффект улучшения показателей
В результате ответ ЛЛМ выглядит так
Система, представляющая интерес для проекта, — настроенный для интернет-магазина операционный контур email-рассылок на базе Mindbox. Этот контур получает данные о действиях покупателей, использует их для выделения сегментов и выбора адресатов, отправляет письма, связывает с профилями покупателей последующие события и рассчитывает результаты рассылок. Проектная работа предназначена для изменения этого контура и его настроек. Покупатели, их действия, почтовые клиенты и покупки находятся за границей системы; внутри системы находятся полученные представления этих действий в виде событий и связанных данных. Экономическая результативность использования системы оценивается прежде всего прибылью на потраченный рубль и прибылью, связанной с рассылками по принятому методу атрибуции; вероятности открытия, перехода и покупки после перехода используются как диагностические показатели. Инкрементальный причинный эффект изменений системы подлежит отдельной проверке.
В целом согласен с предложенным вариантом ЛЛМ, хотя последние пункты 8 и 9 пришлось просить переписать, так как был не согласен с метриками и методами исследования причинности эффекта.