Чтобы провести анализ целевой аудитории с помощью нейросети, начните с конкретного бизнес-вопроса и соберите наблюдения, которые можно проверить по исходным записям. На выходе будут не готовые портреты рынка, а гипотезы о задачах и барьерах, промпт для разбора и вопросы для проверки. Ниже — полный учебный пример на трёх вымышленных наблюдениях: он не подтверждает устойчивые сегменты или свойства условной мастерской.
Поставьте вопрос и соберите наблюдения
Начните с решения, для которого нужны данные. Например: «Какую информацию человеку важно получить до обращения в условную мастерскую?» Укажите период, который относится к вашему решению, и определите единицу анализа: например, одну реплику или фрагмент обращения с одной мыслью. Так будет понятно, что именно сравнивать и к каким исходным данным должен вести каждый вывод.
Источниками могут быть интервью, обращения и отзывы. Отзывы и обращения показывают реальные ситуации; в жалобах могут отражаться ожидания и неудобные процессы. Яндекс Реклама: «Боли клиентов»
Присвойте каждой записи ID: obs1, obs2 и далее. Если сообщение содержит несколько тем, разделите его на фрагменты и сохраните связь с исходной записью. Не подменяйте слова собеседника своей версией причины: иначе вывод будет вести уже к пересказу аналитика, а не к наблюдению.
Перед передачей текста помощнику удалите имена и другие персональные детали. Яндекс ЯРД рекомендует обезличивать ответы интервью перед загрузкой в Алису AI. Яндекс ЯРД: анализ целевой аудитории Если вы не знаете, разрешено ли передавать конкретные данные выбранному сервису, сначала проверьте его официальные условия.
Для интервью подготовьте открытые вопросы о конкретном опыте:
- Что вам важно выяснить о цене до обращения?
- Какие материалы вам удобно передать и зачем?
- Какие ограничения по времени для вас важны?
Это предлагаемые вопросы, а не цитаты клиентов. Интервью — разговор об опыте человека; вопросы не должны подталкивать собеседника к нужной формулировке. Яндекс ЯРД: анализ целевой аудитории
Выберите помощника и задайте правила
Сначала определите, что именно должен уметь помощник: например, разбирать текст интервью или работать с файлом. Яндекс ЯРД описывает Алису AI как помощника для подготовки вопросов и разбора ответов интервью. Яндекс ЯРД: анализ целевой аудитории В справке GigaChat отдельно указана функция анализа прикреплённого файла формата DOCX, PDF или TXT. GigaChat: работа с документами Это примеры документированных возможностей, не рейтинг сервисов и не результаты сравнительного теста.
Если хотите сравнить помощников, проведите пробный запуск на одном и том же обезличенном наборе и с одинаковым промптом. Проверьте, может ли результат:
- связать каждую гипотезу с исходными ID;
- дословно сохранить запись в поле
observation; - оставить неизвестное неизвестным;
- показать записи, которые поддерживают гипотезу, и те, которые ей противоречат;
- выдержать заданный формат.
Сверку ID, дословности и структуры можно поручить агенту по этим правилам. Человек уточняет отсутствующие бизнес-факты и принимает решения по исключениям. Если помощник сообщает цену, условия и разрешения на передачу данных проверьте на официальных страницах выбранных сервисов: подтверждённых цен в этой инструкции нет.
Промпт для исследования
Передайте помощнику бизнес-вопрос и обезличенные наблюдения с ID. В промпте задан конкретный формат JSON: руководство Яндекс Cloud рекомендует указывать требуемую структуру ответа, в том числе JSON. Яндекс Cloud: руководство по промптам Формат помогает проверить, заполнены ли поля, но сам по себе не доказывает правильность выводов.
Скопируйте промпт целиком и подставьте свои вопрос и наблюдения. В учебном примере используются три вымышленных записи. Структура результата ниже совпадает со структурой, запрошенной в промпте.
Ты — аналитик аудитории. Разбери наблюдения для бизнес-вопроса: [вставьте вопрос].
Правила:
- Каждую исходную запись передавай с её ID. Дословно скопируй полную формулировку в поле observation: не сокращай, не исправляй и не заменяй пересказом.
- Формулируй задачи, барьеры, возможные причины, JTBD и сегменты как гипотезы, а не как установленные факты. Не придумывай демографию и свойства бизнеса.
- Объединяй записи в одну гипотезу только при наличии общего основания в их формулировках. В observations сохрани все записи группы с их ID и дословным текстом. Не объединяй записи только потому, что в них упоминается одна тема.
- Для каждой гипотезы укажи evidence_ids — записи, которые её поддерживают; non_supporting_ids — записи, которые её не подтверждают и не опровергают; counterevidence_ids — записи, которые ей противоречат. Не скрывай записи ни одной из этих категорий. Если подходящих записей нет, верни пустой список. Перечисляй только ID из входа.
- Не выдавай отсутствие противоречий во входной выборке за доказательство отсутствия противоречий вне её. Не делай вывод о спросе всего рынка по ограниченному набору записей.
- В jtbd заполни when, want, so_that. В jtbd_explanation простыми словами поясни задачу человека в обстоятельствах, описанных во входе. Не превращай неизвестное обстоятельство в факт.
- Если общей задачи для группы записей не видно, не объединяй их. Если данных для вывода о сегменте недостаточно, так и напиши.
- Добавь открытый вопрос для проверки каждой гипотезы.
- Верни только JSON следующей структуры:
{
"hypotheses": [
{
"hypothesis_id": "H1",
"observations": [
{
"obs_id": "obs1",
"observation": "дословная полная формулировка входной записи"
}
],
"situation": "ситуация, описанная в записи или группе записей",
"task": "гипотеза задачи",
"barrier": "гипотеза барьера или неизвестно",
"possible_reason": "возможная причина или неизвестно",
"jtbd": {
"when": "обстоятельства, описанные во входных данных",
"want": "чего человек, возможно, хочет",
"so_that": "возможная цель или неизвестно"
},
"jtbd_explanation": "простое пояснение задачи в конкретных обстоятельствах без добавленных фактов",
"segment_hypothesis": "гипотеза потребности или сегмента; если данных недостаточно, укажи это",
"evidence_ids": [],
"non_supporting_ids": [],
"counterevidence_ids": [],
"unknowns": []
}
],
"review_questions": [
{
"hypothesis_id": "H1",
"question": "открытый вопрос для проверки"
}
]
}
Наблюдения:
- obs1: человек спрашивает о цене до визита
- obs2: человек хочет прислать фото повреждения
- obs3: человек спрашивает о записи на выходные
От наблюдения к гипотезе
Ниже — заполненный результат для тех же трёх вымышленных наблюдений и в той же JSON-структуре, что задана в промпте. Каждое поле observation дословно повторяет входную запись. Пустой counterevidence_ids означает только, что среди этих трёх записей не указано противоречие. Наличие оценки повреждения по фото и работы по выходным не подтверждено.
{
"hypotheses": [
{
"hypothesis_id": "H1",
"observations": [
{
"obs_id": "obs1",
"observation": "человек спрашивает о цене до визита"
}
],
"situation": "человек спрашивает о цене до визита",
"task": "возможно, человеку важно узнать цену до визита",
"barrier": "неизвестно; запись не показывает, что мешает обратиться",
"possible_reason": "неизвестно",
"jtbd": {
"when": "когда человек спрашивает о цене до визита",
"want": "узнать цену до визита",
"so_that": "возможная цель — решить, обращаться ли; это нужно проверить"
},
"jtbd_explanation": "В записи человек спрашивает о цене до визита. Возможно, он пытается понять, стоит ли обращаться, но его цель нужно уточнить.",
"segment_hypothesis": "устойчивый сегмент не установлен; данных недостаточно",
"evidence_ids": ["obs1"],
"non_supporting_ids": ["obs2", "obs3"],
"counterevidence_ids": [],
"unknowns": ["причина вопроса", "какой информации о цене достаточно", "решил ли человек обратиться"]
},
{
"hypothesis_id": "H2",
"observations": [
{
"obs_id": "obs2",
"observation": "человек хочет прислать фото повреждения"
}
],
"situation": "человек хочет прислать фото повреждения",
"task": "возможно, человеку важно передать информацию о повреждении с помощью фото",
"barrier": "неизвестно; запись не подтверждает, что отправить фото невозможно",
"possible_reason": "неизвестно",
"jtbd": {
"when": "когда человек хочет прислать фото повреждения",
"want": "прислать фото повреждения",
"so_that": "цель отправки в наблюдении не названа"
},
"jtbd_explanation": "В записи человек хочет прислать фото повреждения. Его обстоятельства, цель отправки и ожидания от мастерской не указаны.",
"segment_hypothesis": "устойчивый сегмент не установлен; данных недостаточно",
"evidence_ids": ["obs2"],
"non_supporting_ids": ["obs1", "obs3"],
"counterevidence_ids": [],
"unknowns": ["зачем человеку нужно отправить фото", "каким способом он хочет его передать", "может ли мастерская оценивать повреждение по фото"]
},
{
"hypothesis_id": "H3",
"observations": [
{
"obs_id": "obs3",
"observation": "человек спрашивает о записи на выходные"
}
],
"situation": "человек спрашивает о записи на выходные",
"task": "возможно, человеку важно узнать о записи на выходные",
"barrier": "неизвестно; запись не объясняет, почему нужны именно выходные",
"possible_reason": "неизвестно",
"jtbd": {
"when": "когда человек спрашивает о записи на выходные",
"want": "узнать о записи на выходные",
"so_that": "возможная цель — найти подходящее время; это нужно проверить"
},
"jtbd_explanation": "В записи человек спрашивает о записи на выходные. Почему ему нужны выходные и какое время подходит, не указано.",
"segment_hypothesis": "устойчивый сегмент не установлен; данных недостаточно",
"evidence_ids": ["obs3"],
"non_supporting_ids": ["obs1", "obs2"],
"counterevidence_ids": [],
"unknowns": ["почему человеку подходят выходные", "какие часы ему нужны", "есть ли запись в это время"]
}
],
"review_questions": [
{
"hypothesis_id": "H1",
"question": "Что вы хотели понять, спросив о цене до визита?"
},
{
"hypothesis_id": "H2",
"question": "Что вы хотели бы сообщить или выяснить, если бы прислали фото повреждения?"
},
{
"hypothesis_id": "H3",
"question": "Какое время записи вам подходит и что важно при его выборе?"
}
]
}
JTBD — это прогресс, которого человек стремится достичь в конкретных обстоятельствах. Christensen Institute: Jobs to Be Done Поля «когда / хочу / чтобы» здесь — учебный шаблон, а не приписанный источнику дословный стандарт. В примере это возможные направления для проверки, а не доказанные причины или устойчивые сегменты.
Как проверить потребность и принять решение
Добавляйте новые интервью и обращения отдельными записями с ID. Агент может сверить ID с входом, проверить дословность observation, отметить дубли и распределить записи: поддерживают гипотезу, не подтверждают её или противоречат ей. Если не хватает бизнес-факта или встретилось исключение, человек уточняет факт и принимает решение.
Если помощник вывел частоты, пересчитайте уникальные исходные записи в каждой группе и проверьте знаменатель. Агент может выполнить эту сверку по заданным правилам и показать записи, вошедшие в числитель и знаменатель. Частота в небольшом наборе не показывает долю рынка и не доказывает спрос на каждый частный шаг процесса.
Проверяйте гипотезы новыми наблюдениями и открытыми вопросами из review_questions. Если подтверждённое различие задач или барьеров меняет нужную человеку информацию либо следующий шаг, можно проверить для него отдельное сообщение или предложение. Если различие не подтверждается или не меняет решение, оставьте общий вариант и продолжайте собирать данные.
Условный пример: если новые наблюдения подтвердят, что вопрос о цене связан с барьером до визита, сначала уточните у бизнеса реальный способ оценки стоимости, затем объясните именно его. Не обещайте цену или оценку по фото, пока такие условия не подтверждены.
Если подтверждённая гипотеза меняет план публикаций, пригодится составление контент-плана с помощью ИИ. Если она влияет на содержание посадочной страницы, используйте руководство по созданию лендинга с нейросетью.