4. Основные задачи
аналитиков сервиса
• Подготовка запуска
• Регулярная аналитическая
поддержка сервиса (через отчеты)
• Сопровождение и анализ крупных РК
на всех этапах
• Отслеживание рынка
• Ответы на почти любые разовые
аналитические вопросы
4
5. • Решение длительной задачи пользователя
• Неидентичность пользователей
• Часто новые
5
13. KPI?
Сильно отличаются в зависимости от задачи:
•охват поисковых запросов
•качество ответа на Поиске,
•аудитория (доля рынка),
•возвращаемость,
•узнаваемость,
•деньги
13
14. Что оцениваем
• Насколько заметно (по доле людей, например)
• Так ли используется (логи и Метрика)
• Не нашли ли люди дополнительного профита,
который мы не предполагали
• Как запуск помог
окружению
(возвращаемость и пр.)
14
22. История №3, итоги:
• Обсчёт запусков фич и рекламы
• Обработка данных для СМИ
• Анализ поведения пользователей
22
23. Подводя итоги
• Аналитик - это НЕ про анализ требований
• Аналитик это тот, кто поможет:
– формализовать ожидания от запуска и оценить
его на разных этапах,
– найти узкие и проблемные места,
– расставить приоритеты, указать на
возможности
– креатив, новые подходы
23
25. Как посчитать счастье
пользователей?
• Количество просмотренных страниц
• Густота кликов
• Используемость фич
• Длина сессии
• Количество уникальных посетителей
• Время между кликами
• …
Решил ли он свою задачу?
Получил ли он ответ? 25
27. Сложности
• Посчитать
• надо считать по каждой из групп
• сессии до и после прихода не сервис
• поведение на сервисе и на других сайтах
• составить кучу поведенческих случаев
• Очень «дорого»
• сотни кейсов
• посчитать-то можем, но вот использовать на
продакшене – не сможем
27
28. История №4, итоги:
• Не знаем что такое «счастье
пользователей»
• Не знаем что должно
происходить, когда
оно случается
• Много/долго/сложно
считать
28
29. Спасибо за внимание!
Вопросы?
Карпов Михаил (michail.karpov@ya.ru)
pmrussia.blogspot.com
@michailkarpov
29
Notes de l'éditeur
Нет внешнего заказчика Есть конкуренты Веб О том как мы пытаемся быстрее сделать продукт, который понравится пользователям.
Аналитики у нас бывают всякие разные. Всех обсудить не сможем, поэтому, поговорим про основную группу – «продуктовых аналитиков» (аналитиков сервиса) и немного обсудим исследователей интерфейсов (юзабилистов, занимающихся проектированием взаимодействия пользователей с сервисом) и информационных архитекторов (занимающихся анализом предметной области).
Таким образом основные задачи аналитиков получаются такими… Эти задачи распределяются у нас между тремя типами аналитиков…
Про Яндекс: Продуктовая разработка – делаем продукты, основная цель – ответить на вопросы пользователей Берем кейс Яндекс.Работы (агрегатор вакансий с работных сайтов). Поиск работы – это длительный процесс, продолжительный вопрос пользователя. Особенность – часто меняется состав пользователей.
Про Яндекс: Продуктовая разработка – делаем продукты, основная цель – ответить на вопросы пользователей Берем кейс Яндекс.Работы (агрегатор вакансий с работных сайтов). Поиск работы – это длительный процесс, продолжительный вопрос пользователя. Особенность – часто меняется состав пользователей.
Значит, придумали мы «зафигачить» сайт на котором будут все объявления о работе с России, Украины, Белоруси и Казахстана. То есть собрать объявления с ведущих сайтов ( hh, superjob,.. ) и показать их в едином интерфейсе. Прикинули, что запросы про работу это примерно 1% от всех запросов в Яндекс (то есть действительно оочень много), решили делать. Нужно было понять состояние работного рынка, поэтому мы пошли к нашей группе информационных архитекторов.
Для Яндекс.Работы, анализ предметной области инфархи разложили по следующим основам-осям.
В результате – получили, например, такой артефакт. Ещё есть артефакты с обзором конкурентов и с фичами для пользователей. По вертикали –ти пы пользователей, по горизонтали – этапы поиска работы, которые они проходят. Итого к «Истории 1»: Получаем общий анализ предметной области. Понимаем с чего начать – важнейшие группы пользователей и базовые фичи для них. Получаем долгострочную стратегию, понимаем куда двигаться дальше.
Собираем фидбэк и «оцениваем волну» Сравниваем с плановыми показателями Сравниваем с рынком (лететь не медленнее)
Нужны не только ключевые показатели, но и понимание как используется запущенная функциональность. Насколько то, что мы сделали заметно, используется (по доле людей например) Насколько то, для чего мы что-то делали так и используется (мы ожидали одного поведения, оказалось ли оно таким?) Не нашли ли люди дополнительного профита, который мы не предполагали Как запуск помог окружению – если это новый функционал в сервисе, то как он помог сервису (вот тут как раз возвращаемость и пр)
Поскольку залезть в голову мы не можем, то мы проводим юзабилити-исследования. Есть гипотезы и вопросы, которые мы не можем проверить релизом или не всегда можем их быстро понять, или просто их так много, что не понятно какую из них стоит проверять рассчётами. Поэтому делаем не только количественную проверку, но и качественную. Например, выкатывали новый элемент функциональности в Яндекс-Поиске – а люди не кликали, - это, видимо, говорило, о том, что они не видят – надобы сделать заметнее, побольше. Ан нет – оказалось, что пользователи просто не доверяли самой функциональности, принимая её за рекламу и спам.
Собираем фидбэк и «оцениваем волну» Сравниваем с плановыми показателями Сравниваем с рынком (лететь не медленнее)
Про Яндекс: Продуктовая разработка – делаем продукты, основная цель – ответить на вопросы пользователей Берем кейс Яндекс.Работы (агрегатор вакансий с работных сайтов). Поиск работы – это длительный процесс, продолжительный вопрос пользователя. Особенность – часто меняется состав пользователей.
Мы сидим на огромной груде информации и время от времени выпускаем исследования, построенные на этой информации. Само собой эту информацию надо уметь правильно и грамотно подсчитывать.
Задача – найти аналитика для решения задач уже готового сервиса. Тут уже несколько другие задачи и требования.
Оценивать запуски, «кнопки докручивать». Сервис растёт, фич становиться всё больше и со временем он уже начинает походить на склад. Фич много, не всем пользователям они нужны, и большая часть пользователей можно спокойно не знать про какую-то полезную функциональность на сервисе. А хочется, чтобы сервис больше походил на музей.
Хочется знать о пользователях больше, чтобы, в иделе, сделать для каждого из них (или хотя бы для каждой из групп) свой персональный гид. Истории: про поведение бухгалтеров и водителей про мультирегиональность По результатам - можем изменять поведение сервиса в зависимости от определяемой группы пользователя Инструменты / что считаем – используемость фич, характер запросов, возвращаемость
Собираем фидбэк и «оцениваем волну» Сравниваем с плановыми показателями Сравниваем с рынком (лететь не медленнее)
Требованиями занимается проектный менеджер, являющийся и продуктовым
CTR и клики невсегда помогают оценить «счастье» пользователей (!! Пример !!), поэтому пробуем найти другие метрики. Оценить получил ли пользователь ответ на свой вопрос в нашем случае достаточно сложно – не ясно как это проверить. Я бы с радостью в кулуарах с кем-нибудь подискутировал на эту тему.
В каких-то случаях можем посчитать дали ли мы ответ, а в каких-то – это проблематично. Кейс 1: например, сделали сниппеты более информативными, - что должно было измениться, должны ли стать по ним чаще кликать? А ничего не изменилось, хотя с продуктовой стороны – это полезная выкатка. Кейс 2: изменили релевантность – тоже не ясно должны дольше листать или нет?
CTR и клики невсегда помогают оценить «счастье» пользователей (!! Пример !!), поэтому пробуем найти другие метрики. Оценить получил ли пользователь ответ на свой вопрос в нашем случае достаточно сложно – не ясно как это проверить. Я бы с радостью в кулуарах с кем-нибудь подискутировал на эту тему. Это действительно сложная задача, которую мы до сих пор пытаемся решить.
Собираем фидбэк и «оцениваем волну» Сравниваем с плановыми показателями Сравниваем с рынком (лететь не медленнее)