Продуктовая аналитика на примере GPT-бота

Когда я начинал учиться аналитике, для меня долгое время было большим вопросом - чем все же занимаются аналитики? Сложно это объяснить понятным языком. Я полностью понял уже получив опыт работы в аналитике, а также (что мне кажется немаловажно) в ходе ведения бизнеса. Когда учишься смотреть на продукт и метрики с точки зрения бизнеса, какие метрики непосредственно влияют на прибыль, а какие не так уж важны.

Недавно я создал для учеников бесплатного для них в рамках курса телеграм бота с GPT, а вчера добавил туда и новую LLM - Claude. Есть мнение, что она даже умнее GPT, как минимум в плане написания кода. Сам последнее время пользуюсь именно ей.

Итого, бот умеет отвечать с помощью двух LLM (можно выбрать одну из них), понимает голосовые, картинки, умеет сам рисовать картинки.

Как выглядела бы продуктовая аналитика данного "продукта" и зачем она нужна? Давайте детально разберем.

Общая цель продукта

При развитии любого продукта необходимо сначала определить общую цель. В коммерческих продуктах чаще всего это прибыль.

Итак, я создал этого бота и решил продавать доступ. Во-первых, нужно примерно прикинуть юнит экономику. То есть сколько я трачу и сколько получаю.

Каждое сообщение в боте тратит сколько-то моих токенов, которые я покупаю за доллары на сайте GPT и других LLM.

Допустим, я прикинул, сколько люди тратят, и решил установить цену в 500р в месяц. При этом на токены я буду тратить по 200-300р (в зависимости от активности человека). Также стоит дневной лимит по запросам - нельзя потратить больше определенного числа токенов.

Зачем мне вообще аналитика?

В моем бизнесе есть ключевые процессы, которые необходимо контролировать. И вопросы, на которые нужно знать ответ.

1. Какой доход я получаю каждый день, каждый месяц? Растет мой доход или падает?
2. Каков уровень клиентского сервиса? Бот регулярно работает или постоянно сбои? Каковы основные причины сбоев?
3. Сколько пользователей используют бот каждый день, каждый месяц? (эти метрики называются DAU, MAU). В какие дни, часы дня пики активности?
4. Каково удержание клиентов? Те, кто подписались на бота - насколько они активно им пользуются? Продляют ли подписку? Если нет, то почему не продлили?
5. На что у меня идут основные расходы на токены? Растут они или падают в расчете на 1 человека в среднем? Как можно их уменьшить (=и увеличить прибыль)?

Это все для бизнеса критически важные вопросы. Для регулярного получения ответов на них как раз и создается база данных, логируются (сохраняются) все действия пользователей, строятся графики.

Исходя из вопросов, на которые нам нужно получать ответ, продумываются основные метрики продукта. В данном случае это -

• Доходы, расходы, юнит экономика
• DAU (Daily Active Users - кол-во активных юзеров каждый день)
• MAU (Monthly Active Users)
• Retention (удержание клиентов)
• Рейтинг удовлетворенности клиента (поставленный балл от 1 до 5)
• Среднее время использования бота в день
• Доля пользователей, которые уткнулись в потолок токенов при использовании бота

И так далее. За этими метриками нужно следить. При изменении каждой из них следуют конкретные действия. То есть не просто так графики строятся с непонятной целью.

Например, строится график DAU - и в один из дней он падает. Аналитики это видят на графике, начинают копаться в данных, смотреть в чем проблема, детализировать ее. Например локализовать - посмотрели в какое время люди использовали бот, увидели, что утром и днем все было ок, а вечером вообще нет активности. И оказывается в это время был сбой на 3 часа. Действие: исправить по возможности причину бага, продумать техническое решение на будущее.

Откуда берутся данные

Исходя из примерного понимания бизнеса продумывают структуру базы данных. Допустим, она будет в PostgreSQL.

Что в ней должно сохраняться? Например:

• таблица users с пользователями (user_id, telegram_id, name)
• таблица usage (user_id, timestamp, message_type, tokens_used, message_text)
• таблица payments (user_id, payment_date, status, amount, payment_method, subscription_period)
• таблица subscriptions (user_id, start_date, end_date, status, subscription_type)

Все данные переписок и других запросов поступают в таблицу usage. Также создаем таблицы для платежей, подписок. Далее разберем детально зачем все они нужны.

Налаживают процесс поступления данных в базу обычно дата-инженеры. Это смежная с аналитикой профессия.

Строим графики в BI системе

Итак, мы наладили процесс корректного поступления данных в базу. Далее построим графики в BI системе. Разберем для примера Yandex Datalens, остальные все на него очень похожи и тоже интуитивно понятны при использовании.

Как он работает. В нем есть несколько видов объектов.

• Подключение: Создается подключение к базе данных
• SQL запросы: К подключению можно создать определенный SQL запрос и сохранить его. Результатом SQL запроса является таблица.
• График. По таблице строится график и добавляется на дешборд.
• Дешборд: состоит из нескольких графиков на одной странице

Итак, мы определились с метриками, теперь осталось построить по ним дешборды в BI системе. Для небольшого стартапа все вполне может быть и на одном большом дешборде. Если бы этим ботом пользовались тысячи людей, у нас были большие бюджеты, команда аналитики - создали бы отдельные дешборды по каждой из тем:

1. Финансовый дешборд

• График дневной/месячной выручки
• График расходов на токены по каждой LLM
• Средний доход с пользователя (ARPU)
• Юнит-экономика (доходы vs расходы на пользователя)
• Conversion rate из бесплатного в платный период

2. Пользовательская активность

• DAU/MAU тренды
• Количество сообщений в день
• Распределение использования по типам запросов (текст/голос/картинки)
• Доля пользователей, достигающих лимита токенов

3. Качество сервиса

• Uptime бота (время работы без сбоев)
• Количество и длительность технических сбоев
• Среднее время ответа бота
• Рейтинг удовлетворенности пользователей
• Количество ошибок по типам

4. Retention (удержание)

• Cohort анализ по месяцам
• Процент продления подписки

И так далее.

Дешборд состоит из графиков, каждый из которых строится по результатам SQL запроса. Соответственно, если в базу поступят новые данные, и мы нажмем "обновить" на дешборде - все SQL запросы выполнятся заново и на графиках отобразятся актуальные данные.

Как может выглядеть дешборд по пользовательской активности:

Работа аналитика

Все описанное выше можно назвать аналитической инфраструктурой. Теперь, когда мы все это обсудили, можем разобрать работу непосредственно аналитика джуна-миддла.

Рассмотрим аналитика пользовательской активности. По этой тематике есть целый дешборд, который мы обсудили выше

Пользовательская активность

• DAU/MAU тренды
• Количество сообщений в день
• Распределение использования по типам запросов (текст/голос/картинки)
• Доля пользователей, достигающих лимита токенов

Если компания небольшая (стартап например), задачей аналитика может быть с нуля создать эту систему дешбордов. В большой компании скорее всего такой дешборд уже есть и надо его поддерживать или вносить правки

Как проходит работа команды, возьмем усредненный пример: спринты раз в 2 недели. Вся команда занимается аналитикой, но разными направлениями (описанными выше). На спринте каждому назначают задачи. Задачи ставит тимлид либо продукт менеджер со стороны бизнеса, который занимается развитием продукта в целом. Далее в течение недели проходят ежедневные дейлики в 10 утра на 30 минут, также раз в 2 недели в конце спринта презентация результатов всего отдела.

Далее разберем примеры задач

Рутинные задачи

Состоят в том чтобы поддерживать дешборд. Каждый день с утра заходить в BI систему и проверять, что данные обновились, появились метрики за вчерашний день. Если есть сильное падение активности пользователей за вчера - пойти разобраться почему. Может быть, всплывет технический баг, тогда его надо поправить. Может быть, вы детализируете проблему, и окажется что падение было в определенный интервал из-за технических причин. А может и не найдется явного ответа, тогда остается следить за последующими днями, сохранится ли этот тренд, или это была случайность. Если сохранится - потом надо будет делать более детальную аналитику и искать причину.

Инфраструктурные задачи

Наладить ETL процессы, построить витрину данных. Сейчас объясню понятными словами.

ETL (Extract, Transform, Load) - процесс выгрузки данных из одного места, преобразования и загрузки куда-то еще.

Например, ботом стало пользоваться очень много людей. Таблица usage стала очень большой, и запросы стали выполняться очень долго.

Можно поставить задачу создать витрину daily_metrics - таблицу с полями, например, date, dau, total_tokens, avg_response_time.

Пример SQL запроса:

SELECT  
    date_trunc('day', timestamp) as date,  
    count(distinct user_id) as dau,  
    sum(tokens_used) as total_tokens, 
    avg(response_time) as avg_response_time,  
-- и другие агрегированные метрики 
FROM usage 
GROUP BY 1

Зачем нужна витрина? Допустим, данных стало так много, что расчет запроса выше даже для одной даты занимает 10 секунд. Значит, если на дешборде уже данных за полгода, каждое обновление графиков потребует заново выполнить SQL запрос, который будет выполняться 30 минут. Что невероятно долго, и точно нам не подойдет.

Поэтому мы создаем ETL процесс при помощи скрипта в python, который каждый день выполняет SQL запрос, считает данные за прошлый день и сохраняет их в новую таблицу с названием daily_metrics.

В ней они уже в готовом виде, поэтому SQL запрос выполнится почти мгновенно. И график сразу обновится.

Витрину нужно построить, а далее поддерживать, следить что регулярно обновляется. При сбоях разбираться в причинах.

Код витрины пишется в python. В нем происходит подключение к базе данных, там же можно написать SQL запрос, выгрузить данные, преобразовать, далее написать код загрузки в другую таблицы базы.

Ад хок задачи

Периодически аналитики делают разовые задачи на доработку дешбордов, выгрузку данных, проверку гипотез. Все они связаны с бизнес процессами в компании.

Большинство задач делаются в python в jupyter notebook. Вообще python это универсальный инструмент, который позволяет решать самые разные задачи. В нем и к базе подключиться можно, и данные выгрузить с помощью SQL запроса, и csv/excel файл легко загрузить.

Примеры ад хок задач:

1. У продукт менеджера есть гипотеза, что плохой сервис приводит к оттоку пользователей. Что нужно сделать: найти в данных тех пользователей, которые столкнулись с техническими сбоями (когда бот не работал 2-3 часа). По данным в базе выбрать тех что как раз в это время хотел что-то сделать, но не смог. Далее посмотреть, повлияло ли это на удержание этих клиентов, сколько % из них вернулись через день, через неделю. Отличается ли от тех, кто не столкнулся с проблемой.
2. Посмотреть, что с теми пользователями, кто достигал лимита по токенам? Много ли вообще таких? Влияет ли это событие на их лояльность и приводит ли к оттоку или нет?
3. Сравнить опыт использования Claude и GPT для ответов. Приводит ли использование Claude к улучшению пользовательского опыта или нет? Те кто начали использовать Claude - они потом возвращаются к GPT или нет?
4. В бот добавили новую опцию - команду set_initial_prompt для задания общего промпта беседы (например, "отвечай от лица Александра Пушкина красиво и литературно"). Надо проверить, что данные о ее использовании корректно поступают в базу. Добавить на дешборды фильтр, чтобы уметь возможность смотреть отдельно метрики по тем, у кого включен такой промпт (хотим убедиться, что у них не возникло проблем).
5. Сделать выгрузку пользователей, кто прекратил пользоваться ботом более месяца назад. Далее csv файл нужно передать отделу разработки - они настроят рассылку с предложением скидки, чтобы люди вернулись в продукт.

Пример работы над задачей

Разберем для примера задачу -

Посмотреть, что с теми пользователями, кто достигал лимита по токенам? Много ли вообще таких? Влияет ли это событие на их лояльность и приводит ли к оттоку или нет?

Как я ее делаю?

Создаю скрипт в jupyter notebook на python. Импортирую нужные библиотеки (наборы функций).

Загружаю данные также в python с помощью кода для подключения к базе. перед этим могу поделать простые запросы в DBeaver, отдельной программе для работы с SQL. посмотреть примеры данных, сделать простые проверки, подготовить SQL код и потом выгрузить по нему данные в python.

Получаю список пользователей, которые достигали лимита. Руками проверяю данные - все ли они верны? Нет ли пробелов в данных?

Далее с помощью другого SQL запроса смотрю данные по retention выбранной группы пользователей vs всех остальных, кто пользовался ботом и не встретил проблем. Смотрю, есть ли отличие. Если есть, оно именно с плохим сервисом связано? Может есть другая более простая причина, которая приводит к отличию retention в этой группе? Проверяю все эти гипотезы исходя из контекста и наблюдаемых данных. Подготавливаю вывод - он может содержать несколько разовых графиков, построенных в python, а также итоговые цифры.

Разовые графики отличаются от дешбордов. В дешбордах те графики, которые мы регулярно смотрим. А этот график с двумя retention для 2 групп мы 1 раз построили, сделали вывод, и дальше нам уже не надо на него смотреть.