Product × Science: заметки с тегом Практический пример

Меньше нотификаций дают лучшую возвращаемость в долгосроке

Fri, 23 Dec 2022 01:00:00 +0300

Ресерчеры и аналитики из Мордакниги установили, что меньшее количество нотификаций в долгосрочке обеспечивает лучшую возвращаемость в продукт. Хотя поначалу продуктовые метрики и просели.

И выводят два тезиса:

Результаты эксперимента в короткосроке и долгосроке могут сильно отличаться
Меньше нотификаций, но более качественных полезнее в долгосрочной перспективе.

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

Чтобы этот эксперимент провести и защитить использовали данные из опросов и фактического поведения аудитории.

Еще один хороший пример как смешивание разных типов данных и методов помогают в сложных бизнес-ситуациях.

https://medium.com/@AnalyticsAtMeta/notifications-why-less-is-more-how-facebook-has-been-increasing-both-user-satisfaction-and-app-9463f7325e7d

Намерения пользователей и как это проявляется в поведении

Mon, 28 Jun 2021 12:31:00 +0300

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

Краткий пересказ:

Spotify хотят сделать более крутые рекомендации. Оно и логично. Рекомендации — это фишка их продукта, которая напрямую влияет на бизнес-метрики (в это статье об это упоминается взколь, но про это они писали в других материалах).
Осталось только понять, а что такое «круто» и как его увеличивать.
Из других исследований и лучших дизайн/продуктовых практик известно, что за каждым пользовательским взаимодействием с системой стоит какая-то цель или потребность.
Гипотеза — если научиться учитывать потребности в движке рекомендаций, то это увеличит целевые бизнес-метрик и даст понимание, на какие прокси-метрики следует ориентироваться при улучшении движка.
Инициировали цепочку исследований, чтобы вытащить список задач. Тут использовали как количественные, так и качественные методы — десятки интервью и опросы на сотни тысяч пользователей.
Нашли 8 потребностей. Т. к. была связка ответов пользователей с их поведением в продукте, то смогли наложить разные метрики на сессии и понять по каким метриках можно определять их тип. Ну и какие интеракции имеют значение для каждой потребности.
Т. к. научились находить тип сессии на данных, то это уже можно использовать как параметр при моделировании.
Построили несколько моделей, прогнали через оффлайн симуляторы и онлайн АБ-тесты. Получили аплифты.

Вот так вот сложно. Думаю, это заняло суммарно не менее 6 месяцев. Но эту сложность можно понять — они улучшают зрелый продукт, который и так один из топов на рынке. Низковисящие фрукты уже давно сорваны. Остались сложные проблемы. И вот тут на помощь и приходят продвинутые методы исследований и аналитики.

Исследование: https://dl.acm.org/doi/fullHtml/10.1145/3308558.3313613
Интересные скриншоты

Распределение пользовательских интентов

Взаимосвязь поведенческих факторов и интентов

Кейс: находим драйверы роста в социалке при помощи ML и поднимаем ретеншн

Sun, 12 Jan 2020 00:00:00 +0300

В феврале на Flo Data Meetup я рассказывал про кейс с работы. В нём я применил «классические» методы продуктового анализа и теорию графов.

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

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

Видео содержит:
— Вводную про продуктовые подходы
— Небольшой обзор на науку Human-Computer Interaction, из которой я люблю брать новые идеи
— Информацию про продукт
— Вопросы на которые стейкхолдеры хотели получить ответы
— Как я перевёл эти вопросы на язык данных и как начал ресерч
— Почему не хватило «классических» методов
— Минимум про матрицы и теорию графов
— Сниппет кода, который поможет самому сделать похожий ресерч
— Как я интерпретировал полученные данные
— Что мы сделали с инсайтами и какой получили эффект в метриках
— Книжки для самообразования
— QnA секцию, из которой вы сможете немного узнать про нюансы работы с данными в Flo + немного обсудили филосовские вопросы 🙂

Баланс ролей — ключ к росту социальной системы

Thu, 20 Jun 2019 19:06:00 +0300

Seekers, Providers, Welcomers, and Storytellers: Modeling Social Roles in Online Health Communities я рекомендую прочитать тем, кто занимается продуктами с групповыми/социальными фичами: Q&A-сервисы, ПО для коллективной работы, мультиплеерные игры, «социальный» e-commerce и т. д.

Группа ученых из Carnegie Mellon и Stanford решила изучить феномен «успеха» крупнейшего форума по теме рака в мире — Cancer Survivor Network (CSN). Сайт существует с начала 2000-х и стал самым крупным в своем сегменте. Было много аналогичных площадок, но все рано или поздно затухали, а CSN развивается и по сей день.

У социологов возникла гипотеза — на форуме сложилась определенная структура социальных ролей, которая обеспечивала «баланс» в сообществе и позволила ему развиваться. Осталось ее проверить на данных, которые были предоставлены American Cancer Society (а это вся переписка на сайте с 2003 по 2018 гг).

Но для начала надо формально определить, чем является «социальная роль» на данных. Для этого они обратились к теории. Социальная роль в науке определяется 4 факторами:

Цель — у индивида в сообществе есть цель, которую он преследует исходя из собственных интересов.
Взаимодействия — роль контактирует с другими участниками сообщества. На форуме эти взаимодействия проявляются по-разному: старт новой темы обсуждений, написание ответа, лайк комментария или обращение в директ.
Ожидания — социальные роли при взаимодействии рассчитывают на определенную обратную связь. Например, на работе начальник и подчиненный знают чего ждать друг от друга и соответственно подбирают стиль общения. В онлайн-сообществах обычно нет явно формализованных ролей и только «старожилы» знают как и с кем общаться. Например, из-за этого новички на StackOverflow часто стесняют вступать в разговоры и задавать вопросы.
Контекст — некоторые роли могут существовать только при определенных условиях. Например, «поставщик информации» существует во многих типах сообществах, включая Q&A сервисы, рабочие группы и форумы. А вот «коммитер» — это специфичная роль для сообщества разработчиков (GitHub, Bitbucket). Приватность также играет большое значение. Поведение человека на публике обычно отличается от его поведения наедине или с родными.

Кратко про технические моменты:

При помощи кластеризации решили определить какие вообще есть роли, т. к. «доменные эксперты» (модераторы и другие сотрудники CSN) сами до конца не могли однозначно ответить на этот вопрос. Разметки не было.
В реальной жизни человек принадлежит к нескольким ролям одновременно. Например, на работе я одновременно «аналитик» и «спамер в slack». Чтобы учесть это, была использована Gaussian Mixture Model (GMM), которая позволяет отнести объект к нескольким группам с определенной вероятностью.
Для «генерации фич» были использованы подходы из сетевого анализа (SNA) и обработки текста (NLP). Всего было сделано 83 признака.
Количество кластеров — это гиперпараметр модели, которые исследователи сами могли задавать. Они пробовали находить от 2 до 20 кластеров. После «игры» с данными, количество от 10 до 15 показалось им «адекватным».

Чтобы окончательно определиться с количеством ролей, были подключены доменные эксперты. После долгих дискуссий, пришли к оптимальному количеству кластеров — 11.
Тем не менее, модераторы отметили, что модель не нашла один тип роли. Она редко встречается на форуме, но сильно запоминается.
Видимо, слишком мало подобных наблюдений было в датасете или ученые не нашли «нужные» фичи.

После этой огромной работы, они начали проверять свои гипотезы и находить другие инсайты. Кратко:

Основная гипотеза про «баланс» ролей в сообщество подтвердилась.
Нашли свое доказательство «на данных» несколько теорий из социологии, что также сработало как доп.фактор валидации модели.
Нашли «путь успешного пользователя» форума, который становится костяком сообщества. Как следствие, смогли лучше понять retention/churn.

So What?

Исследователи разработали рабочий подход к нахождению «социальных ролей». Они заявляют, что эта методология универсальна и может быть использована в других предметных областях. На работе я уже частично использовал методы из этого ресерча (привет, Алися!) и получил интересные результаты.
Найдя роли в своих продуктах, можно будет 1) определить хорошие Health-метрики, 2) более четко формулировать и проверять продуктовые гипотезы, 3) системно развивать социальную составляющую продукта.

Исследования, приоритеты и метрики в Atlassian

Thu, 24 Jan 2019 20:00:00 +0300

Один из способов становиться лучше как профессионал — это учиться на опыте других. Особенно интересны примеры из больших компаний с налаженными процессами и топовыми специалистами. Из разных источников я попытался восстановить процесс большого редизайна Jira. Ссылки вы найдете в конце.

Проблема на уровне бизнеса

В 2016 году исследователи компании проанализировали интервью и комментарии текущих и ушедших клиентов. Удобство пользования продуктом было камнем преткновения для пользователей Jira.

Продуктовый департамент транслировал эту проблему бизнесу. Повышение удобства использования стало одной из главных целей компании. Улучшения решили оценивать по NPS.

Спрашивать NPS внутри продукта — нормальная практика. А вот запросить доп.информацию о юзере и назначить интервью в том же окошке— это интересно :)

Метрики

NPS (индекс лояльности) — это главная метрика Atlassian. Важнее продаж, выручки, LTV и размера месячной аудитории. Но она не подходит для оценки релизов:

NPS — это интегральная метрика, на которую влияют многие аспекты бизнеса, а не только удобство продукта.

В зрелой компании сложно двигать верхнеуровневые метрики. Практически невозможно заметить улучшение после короткой итерации.

Продуктовым команда была нужна метрика, которая позволит напрямую оценить изменения на юзабилити. Индустриальным стандартом для этой цели является System Usability Scale (SUS).

Придуманный в 1986 году опросник оценки удобства пользования.

Главная проблема SUS при использовании в качестве in-product опроса— количество вопросов сильно прерывает работу пользователей, что снижает количество заполненных анкет.

Исследователи компании предложили использовать более компактные юзабилити-метрики: UMUX и UMUX-Lite. В них всего 4 и 2 вопроса соответственно, что позволяет разместить эти опрос внутри продукта и получать хорошую конверсию в ответ. Притом, ранние исследования доказали сильную корреляцию между этими метриками, SUS и NPS.

Вопросы из UMUX-Lite

Была проведена серия экспериментов, где последовательно спрашивали UMUX-Lite и NPS. Была найдена относительно сильная линейная зависимость между этими метриками (R² = 0.62), что позволило UMUX-Lite стать “мостиком” для NPS. Продуктовым командам выдали формулу “перегонки” из одного значения в другое: NPS = 3.18 ∗ (UMUX-Lite) − 200.6. Это позволило выставлять реалистичные цели на релизы.

NB! Не переиспользуйте эту формулу у себя. Установите свой процесс замера этих метрик и на своей аудитории найдите формулу зависимости.

Приоритизация инициатив

У членов команды было много предложений как сделать Jira удобнее. Нужно было выстроить систему приоритетов. Для этого снова обратились к комментариям из NPS. Вдохновившись классификацией требований к программным системам FURPS, фидбек разбили по следующим темам:

Reliability — требования к надежности.
Usability — требования к удобству использования.
Functionality — функциональные требования.

Каждая тема содержит иерархию из категорий и отдельных фичей.

Продуктовая команда Atlassian получает около 2000 комментариев в месяц. Для тэгирования (кодинга) такого объема информации ребята взяли к себе несколько стажеров. Разметка идет в общем Google Spreadsheet. Каждый комментарий может быть включен в 3 категории и обязательно назначается на ответственную команду.

Каждую потенциальную фичу / проблему они рассматривают в трех измерениях: размер аудитории, частота использования и доля негативного фидбека.

Feature 1 — хороший кандидат для исправления. Большое количество аудитории часто ей пользуется и доля негативных комментов (Pain Index) тоже высока.

Юзабилити-проблемы также разбивали на три популярных категории, которые встречались в комментариях. Это позволило прицельно решать проблемы.

Числа в ячейках — это количество детракторов, которые упомянули о проблеме

Инструмент мониторинга: UX ScoreCard

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

Например, NPS мы можем получить только после выпуска продукта. Или метрики в стиле “время на выполнения задачи” хорошо замеряются в юзабилити-тестах, но не всегда четко отслеживаются “в бою”, т. к. мы не знаем контекст пользователя. Исключением, конечно, являются страницы с четкими Call to Action.

Поэтому в Atlassian используют два дашборда:

Early Signal Testing Scorecard (ESTS) — для дизайн-команды выносят метрики, которые помогают принимать решения на этапе разработки. Для этого они создали собственный мини-фреймворк — Early Signal Testing (никаких откровений особо по ссылке нет, но можно пощелкать презентацию).
Instrumented Scorecard — для продуктовой команды, когда фича уже в проде. Сюда выносят метрики, которые составлены по Google HEART и UMUX-Lite (это, видимо, замеряет Happiness).

Early Signal Testing Scorecard отображает метрики по новым и текущим юзерам

Находим эффект от продуктовых изменений в UMUX-Lite

Продуктологам хочется понимать “стрельнул” ли апдейт. Для этого аналитик строит линейную модель, которая пытается предсказать значение UMUX-Lite.

Линейные модели — не самые точные ML-алгоритмы, зато очень легко интерпретируются, что и нужно в работе над продуктом. Можно посмотреть, дал ли апдейт ожидаемый вклад. Ну или можно воспользоваться A/B-тестами.

Вывод

Анализ комментариев из NPS позволил подсветить проблемные места продукта. Через процесс кодинга удалось “оцифровать” жалобы клиентов и использовать количество жалоб как один из факторов в расстановке приоритетов.

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

UMUX-Lite стал мостиком между дизайнерами, продуктологами и бизнесом, который позволил быстрее получать обратную связь на релизы и понимание вклада в цель компании.
Более подробнее про метрику и методологию можно прочитать здесь: Measuring Usability: From the SUS to the UMUX-Lite.