Как я систему сбора количественного фидбека строил Если вы не знали, я ведь тоже своего рода строитель. Последние пару месяцев выстраивал систему сбора регулярного количественного фидбэка в моих продуктах в BL (как вам такой заход??). Где-то в начале лета я узнал, что все продакты замеряют удовлетворенность по своим продуктам через внутри интерфейсные поп-ап опросы. И вроде как молодцы, уже круто что собирают какие-то метрики и анализируют их. Но в нашем случае, мы получили яркую иллюстрацию пословицы: “хотели как лучше, а получилось как всегда”. В итоге, удовлетворенность замерялась абсолютно топорным способом, в большинстве случаев не там и не тогда, когда надо. Было очевидно, что продакты пытаются закрыть несколько целей одним опросом. Я предложил эту систему немного перестроить на более гибкую и разнообразную. Мой замысел был в том, чтобы в зависимости от этапа пользовательского флоу или CJM, показывать человеку вопрос, который будет максимально точно замерять опыт взаимодействия с продуктом. Например, если пользователь заканчивает определенный флоу в первый раз — показываем ему SEQ (single ease question). Отваливается на важном этапе воронки — задаем вопрос, почему. Попользовался сервисом пару месяцев и накопил опыт взаимодействия — замеряем удовлетворенность. Звучит просто и логично, но на практике настроить это всё оказалось тем ещё гемороем. Во-первых, нужно было заручиться поддержкой продакт-менеджеров. Для этого важно было подсветить, почему существующий подход неидеален и как новый подход может принести им ценность. Что мы сделали? Создали древо решений, пройдя по которому каждый продакт мог бы понять, какой тип опроса ему нужен под его конкретные цели. Это древо решений завязано на коротенький опрос, пройдя который продакт получает инструкцию, как быть и что делать дальше. Во-вторых, настройка с технической стороны тоже потребовала много времени: создание опросов, выверка формулировок, выбор правильных событий, которые будут триггерить опросы, а также согласование правил показа опросов в целом, чтобы не перегрузить пользователей. Много созвонов и переговоров в командой CRM, разгоны с аналитиками и часы сотворчества с чатом GPT. В итоге, через боль и слёзы всё засетапили. Далее, предпоследний, но самый трудъемкий этап – создания дашборда метрик. Мы запускаем опросы через Iterate и у него есть встроенный функционал для анализа. Но он настолько поверхностный и неточный в области анализа качественных данных, что нужно было придумать другой способ. Я хотел свести результаты всех опросов в одном месте и настроить максимально гибкий и разнообразный анализ. Для этого я «стряхнул пыль» с Excel (ладно, это был Google Sheets) и настроил дохуя графиков и таблиц, которые автоматически обновляются при добавлении новых данных. В дашборд также подтягиваются негативные и позитивные ответы на открытые вопросы, что хорошо добавляет глубины в анализ. Итого, получился следующий алгоритм: в течение спринта собираем данные –> выгружаю и добавляю их в Google Sheets –> копирую готовый анализ в ChatGPT –> он заранее заготовленному промпту выдает красивый дайджест –> отправляю его в Slack-канал нашей лаборатории и в каналы команд. Сегодня вот отправил первый дайджест, получилось симпатично. Через 2 недели повторим и посмотрим, что можно улучшить. Пока писал понял, насколько большая работа проделана нами. Рафу и Алтане огромное спасибо и респект, без вас ничего бы не получилось 🤍 Как-то так. Всем отличной рабочей недели, а я пошёл дальше в шахту, солнце ещё высоко. 🥂