Структура лендинга
Из оффера и аудитории собирается порядок экранов: какой блок, зачем он, что на нём и почему он стоит именно здесь, а не выше или ниже.
Порядок блоков на лендинге задаётся не модой, а состоянием читателя: холодный не готов смотреть цену, а горячий не хочет читать объяснение проблемы. Инструмент собирает структуру под ваш оффер и источник трафика, объясняет задачу каждого экрана и отдельно называет блоки, которые вам не нужны.
Порядок задаётся состоянием читателя, а не шаблоном
Типовая структура лендинга существует и в общем работает, но её главная слабость в том, что она одинаковая для всех источников трафика. Человек, пришедший по запросу «купить X с доставкой завтра», и человек, прилетевший с рекламы в ленте, находятся в разных состояниях и требуют разного порядка.
Первому нужны условия, цена и кнопка как можно раньше: он уже выбрал категорию и сравнивает предложения. Второму сначала нужно узнать себя в описании ситуации, иначе цена в первом экране читается как «мне что-то продают» и он уходит.
Поэтому структура здесь собирается от источника трафика и состояния читателя, и у каждого экрана написано, почему он стоит именно в этом месте. Отдельным разделом идут блоки, которые вам не нужны: лишний экран не нейтрален, он отодвигает действие вниз.
Что инструмент намеренно не делает
Не подставляет цифры, сроки, бенчмарки и названия компаний, которых не было в вашем вводе. Если для вывода нужна цифра, которой вы не дали, в ответе будет пометка «уточнить», а не правдоподобное число. Это ограничение стоит в системном промпте и работает против главного свойства языковых моделей: складно достраивать недостающее.
Данные не сохраняются: текст уходит в модель, ответ возвращается в браузер, на стороне сайта ничего не пишется в базу. У инструмента стоит ограничение на число запросов с одного адреса, поэтому при частых прогонах он попросит подождать.