Что сделаем
Разберем, как использовать Claude Fable 5 для продуктовой аналитики: собрать фидбек пользователей, выделить гипотезы, разложить аудиторию на сегменты и найти возможные причины оттока. Это не замена Amplitude, PostHog, BI или продуктового аналитика, а способ быстрее разобрать качественные данные и подготовить понятные выводы.
Главное правило: Claude помогает объяснить и структурировать данные, но не должен придумывать метрики. Если нет события, сегмента, источника или чисел, вывод нужно помечать как гипотезу.
Что нужно на входе
Для первого анализа достаточно четырех источников:
- фидбек пользователей: чаты, звонки, NPS, отзывы, тикеты;
- продуктовые события: регистрации, активация, ключевые действия, оплаты, отмены;
- сегменты: тариф, роль, источник привлечения, размер компании, страна, период использования;
- бизнес-контекст: что изменилось в продукте, какие релизы были, какие гипотезы уже есть.
Если событийной аналитики пока нет, начните с фидбека и таблицы пользователей. Лучше честно работать с неполными данными, чем делать уверенные выводы из воздуха.
Шаг 1. Задайте безопасный режим анализа
Сначала ограничьте Claude: факты отдельно, гипотезы отдельно.
Ты помогаешь продуктовому аналитику разобрать данные.
Правила:
- отделяй факт, наблюдение, гипотезу и рекомендацию;
- не придумывай метрики, которых нет во входных данных;
- если данных мало, снижай confidence;
- каждый вывод связывай с источником;
- не делай окончательный вывод о причине оттока без проверки;
- спорные места помечай [проверить].
Сначала сделай карту данных и скажи, чего не хватает.Проверка: если Claude сразу пишет “главная причина оттока — цена”, а у вас только 5 отзывов, это плохой анализ. Он должен сказать: “есть сигнал, нужна проверка”.
Шаг 2. Соберите карту данных
Перед выводами нужно понять, какие данные вообще есть.
Сделай карту данных для продуктового анализа.
Формат:
- источник данных;
- что в нем есть;
- какой период покрывает;
- какие сегменты доступны;
- какие ограничения;
- какие вопросы можно проверить;
- какие вопросы нельзя проверить.Карта данных защищает от ложной уверенности. Например, по отзывам можно понять боли, но нельзя надежно посчитать долю пользователей с каждой проблемой.
Шаг 3. Классифицируйте фидбек
Фидбек лучше превращать в таблицу. Так видно не только “пользователи недовольны”, а чем именно.
Классифицируй фидбек пользователей.
Вход:
[вставьте отзывы, тикеты, NPS-комментарии или выдержки из звонков]
Колонки:
- ID;
- фрагмент фидбека;
- тема;
- боль пользователя;
- желаемый результат;
- сегмент пользователя, если известен;
- стадия пути: onboarding / activation / usage / payment / support / cancellation;
- эмоциональный тон;
- срочность;
- это баг, запрос функции, непонимание, цена, UX, доверие или другое;
- confidence;
- что проверить.Проверка: одна фраза может относиться к нескольким темам. Например “не смог настроить интеграцию и отменил подписку” — это и onboarding, и интеграция, и churn signal.
Шаг 4. Найдите паттерны
После классификации попросите Claude искать повторяющиеся сигналы.
Найди паттерны во фидбеке.
Сгруппируй:
- повторяющиеся боли;
- сегменты, где боль встречается чаще;
- этапы продукта, где возникает проблема;
- фразы пользователей, которые стоит сохранить как Voice of Customer;
- темы, где данных мало;
- гипотезы, которые стоит проверить количественно.
Не делай вывод, если он основан на одном примере. Помечай такие пункты как единичный сигнал.Хороший паттерн звучит конкретно: “новые пользователи из малого бизнеса часто не понимают, как подключить интеграцию в первые 2 дня”. Плохой паттерн: “нужно улучшить UX”.
Шаг 5. Сформулируйте продуктовые гипотезы
Гипотеза должна связывать проблему, сегмент, изменение и ожидаемый эффект.
Сформулируй продуктовые гипотезы.
Формат:
- проблема;
- сегмент;
- наблюдение из данных;
- гипотеза;
- что изменить в продукте;
- какую метрику проверить;
- ожидаемый эффект;
- риск;
- confidence.
Пиши гипотезы так, чтобы их можно было проверить.Пример:
Проблема: пользователи не завершают настройку интеграции.
Сегмент: малый бизнес, первые 3 дня после регистрации.
Гипотеза: если добавить чек-лист настройки и пример готовой интеграции, activation rate вырастет.
Метрика: доля пользователей, подключивших интеграцию за 7 дней.Шаг 6. Разложите пользователей на сегменты
Сегменты нужны, чтобы не делать среднюю температуру по продукту.
Предложи сегменты для анализа.
Данные:
[описание продукта и доступных полей]
Сегменты:
- по роли пользователя;
- по размеру компании;
- по тарифу;
- по источнику привлечения;
- по стадии жизненного цикла;
- по уровню активности;
- по использованию ключевой функции;
- по риску оттока.
Для каждого сегмента укажи:
- зачем он нужен;
- какие вопросы помогает проверить;
- какие данные нужны;
- какие ошибки возможны.Проверка: сегмент должен помогать принять решение. Если сегмент красивый, но не ведет к действию, он лишний.
Шаг 7. Найдите причины оттока
Отток почти никогда нельзя объяснить одним комментарием. Нужна связка: поведение, фидбек, сегмент и момент ухода.
Проанализируй возможные причины оттока.
Вход:
- список ушедших пользователей;
- сегмент;
- последние действия;
- обращения в поддержку;
- NPS или комментарий;
- дата регистрации;
- дата отмены;
- тариф;
- использованные функции.
Верни таблицу:
- пользователь или группа;
- возможная причина оттока;
- доказательства;
- альтернативное объяснение;
- что проверить количественно;
- какая команда должна смотреть: продукт / поддержка / продажи / success;
- confidence.Проверка: если есть только причина отмены “дорого”, это не всегда цена. Возможно, пользователь не увидел ценность, не завершил настройку или попал не в тот сегмент.
Шаг 8. Свяжите фидбек с метриками
Claude полезен, когда помогает соединить качественные сигналы с измеримыми метриками.
Свяжи качественный фидбек с продуктовыми метриками.
Для каждой темы фидбека укажи:
- какую метрику проверить;
- какое событие нужно в аналитике;
- какой сегмент смотреть;
- какой период взять;
- какой результат подтвердит гипотезу;
- какой результат опровергнет гипотезу.Пример: если пользователи жалуются на сложный импорт данных, смотрите completion rate импорта, время до первого успешного импорта, ошибки импорта и обращения в поддержку по этой теме.
Шаг 9. Соберите выводы без воды
Финальный отчет должен быть коротким и применимым.
Собери отчет по продуктовой аналитике.
Ограничения:
- максимум 10 выводов;
- каждый вывод должен иметь источник;
- каждый вывод должен вести к действию;
- гипотезы не выдавать за факты.
Формат:
1. Что увидели.
2. На какие сегменты это влияет.
3. Почему это важно.
4. Что проверить метриками.
5. Что сделать дальше.Если вывод не ведет к действию, удалите его или перенесите в “наблюдения”.
Шаг 10. Сделайте план экспериментов
После анализа должен появиться список проверок.
Составь план экспериментов.
Колонки:
- гипотеза;
- сегмент;
- изменение;
- метрика успеха;
- guardrail-метрика;
- срок проверки;
- нужные данные;
- владелец;
- риск;
- приоритет.Guardrail-метрика нужна, чтобы улучшение одного показателя не испортило другой. Например, можно повысить активацию агрессивными подсказками, но ухудшить retention.
Шаблон полного промпта
Ты помогаешь с продуктовой аналитикой.
Цель: разобрать фидбек, выделить гипотезы, сегменты и возможные причины оттока.
Правила:
- факт, наблюдение, гипотеза и рекомендация должны быть разделены;
- каждый вывод связывай с источником;
- не придумывай метрики;
- если данных мало, снижай confidence;
- причины оттока формулируй как гипотезы до количественной проверки;
- выводы должны вести к действиям.
Сделай:
1. Карту данных.
2. Классификацию фидбека.
3. Паттерны.
4. Продуктовые гипотезы.
5. Сегменты.
6. Возможные причины оттока.
7. Связку фидбека с метриками.
8. Короткий отчет.
9. План экспериментов.
10. Проверку качества анализа.Что автоматизировать позже
Когда ручной процесс работает, можно подключить:
- PostHog, Amplitude или Mixpanel для событий;
- Google Sheets для таблицы фидбека;
- Slack или Intercom-экспорт для пользовательских сообщений;
- NPS-формы и опросы;
- n8n или Make для регулярной обработки;
- Notion или Jira для гипотез и экспериментов.
Начинайте с read-only и черновиков. Автоматически менять roadmap, статусы задач или сегменты пользователей без проверки не стоит.
FAQ
Можно ли использовать Claude Fable 5 вместо продуктового аналитика?
Нет. Claude помогает структурировать фидбек, находить паттерны и формулировать гипотезы. Но метрики, события, причинность и решения по roadmap должен проверять человек.
Что делать, если есть только отзывы и нет событийной аналитики?
Начните с качественного анализа: темы, боли, сегменты, гипотезы. Затем составьте список событий и метрик, которые нужно начать собирать.
Как не перепутать причину оттока и симптом?
Ищите связку: поведение пользователя, фидбек, сегмент, момент ухода и метрики. Один комментарий редко доказывает причину.
Сколько фидбека нужно для первого анализа?
Для первого прохода хватит 30-50 фрагментов. Но выводы по маленькой выборке нужно помечать низким или средним confidence.
Как понять, что вывод полезный?
Он должен вести к действию: проверить метрику, изменить onboarding, улучшить функцию, обновить подсказку, провести интервью или запустить эксперимент.
