Ex-директор по росту и исследованиям «ВКонтакте» Андрей Законов поделился опытом, как организовать работу с метриками в продуктовой команде, найти продуктового аналитика и не закопаться в данных при проверке продуктовых гипотез.
Я расскажу, как мы внедрили data-driven подход в команде ленты новостей и рекомендаций и развивали продуктовую работу с аналитикой. Пять лет назад, когда я начинал работу, мы относительно немного использовали данные. Но уже понимали, что если активнее применять аналитику для продуктовых решений, получится ускорить органический рост. По состоянию на 2019 год мы ежедневно анализировали более 20 миллиардов событий и параллельно проводили сотни a/b тестов.
Как развивать культуру в команде в направлении data-driven
«ВКонтакте» — большой продукт, частью нашей работы была лента новостей и развитие контентной экосистемы. В том числе мы занимались задачами, связанными с машинным обучением, рекомендациями друзей, музыки и видео.
Важно, что наша команда — продуктоориентированная. В команду приходят не писать код, а создавать продукт.
На первом этапе мы мало использовали данные, но уже начали двигаться в сторону data-driven подхода. Поставили конкретные задачи: увеличить активность в ленте новостей и сделать удобный для чтения порядок записей. Чтобы этого достичь, нужно было наладить вспомогательные процессы — например, построить big data платформу, hadoop и т.п. Изначально эта задача была продуктовой, поэтому развитие инфраструктуры hadoop никогда не было абстрактной самоцелью.
Почему это важно? Если у вас 10 тысяч пользователей в одном городе, возможно, вы понимаете, как они используют продукт. Наши пользователи разного возраста, живут в разных странах и разных часовых поясах, поэтому не так просто понять, как они используют «ВКонтакте». Когда есть миллионы пользователей, любые изменения надо внедрять осторожно: вы никогда заранее не знаете, станет ли им всем удобнее, даже если вы уверены в своей гипотезе.
Нам была нужна платформа для проведения A/B экспериментов, а следовательно — набор удобных продуктовых метрик и инструменты для работы с ними. Чтобы двигаться дальше, нужно было сделать определенные шаги:
- Выбрать технологию.
- Собрать команду.
- Сделать процесс добавления новых метрик максимально простым.
- Наладить тестирование метрик.
- Замотивировать всех участников.
Четвертый пункт ключевой, потому что если в команде только пара человек хотят data-driven, а остальные не готовы инвестировать время в изменение процессов, вряд ли что-то поменяется. Один человек не может создать культуру, посчитать все метрики и начать по-новому разрабатывать продукт. Важно продать идею команде.
Исходя из моего опыта работы с аналитикой, у системы есть четыре характеристики: быстро, дешево, удобно, гибко, но в реальной жизни нужно выбрать только две. С вариантом, в котором работает всё и сразу, я не встречался.
Если хочется быстро и дешево, пользуйтесь Google Analytics. Если хочется быстро и удобно — это, например, Amplitude. Мы пошли по пути «удобно и гибко», потому что было понятно, что это правильная инвестиция времени и ресурсов. Если мы сделаем удобную ленту новостей, это поможет вырастить активность пользователей и улучшить продукт.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Как найти аналитиков
На следующем этапе нужна команда: продуктовые аналитики, дата инженеры и разработчики, которые реализуют систему для работы с данными. С продуктовыми аналитиками всё менее прозрачно, чем с разработчиками, потому что под этим термином каждый может подразумевать что-то свое. После сотни собеседований и встреч создается ощущение, что для одних продуктовый аналитик — это человек, который работает с Google Analytics и Excel (для других — с Python, Pandas и Jupyter), а для кого-то — инженер, который может поднять hadoop и настроить процессы с данными. Кто-то ожидает хорошее продуктовое мышление, а кто-то — опыт работы с высокими нагрузками.
Мы в команде выбирали простой подход: мало специалистов, но все крутые. Поэтому я искал в команду аналитика, который пишет код на PHP, отправляет его в прод, думает о высоких нагрузках, потом анализирует метрики и помогает принимать продуктовые решения. Чтобы не промахнуться, важно вначале очень четко сформулировать свои требования и ожидания.
Сложности на пути к data-driven
После того, как сформирована команда, развернута инфраструктура, добавлено много метрик, начинается новый этап. Появляется много графиков, и команда начинает активно узнавать всё больше и больше о продукте и об активности пользователей. С графиками намного проще находить любые проблемы в проекте, например: определенная сборка приложения плохо работает на какой-то версии android или пуши иногда доставляются долго. В этом плане хорошие продуктовые метрики помогают не только двигаться вперед, но и находить проблемы и понимать их критичность.
Следующий момент –– можно проверять продуктовые гипотезы. И этот этап максимально опасный. Кажется, многие команды застревают на нем надолго. Вместо 50 графиков, в которых все были уверены, в какой-то момент появляется 5000 разных графиков. И никто уже толком не знает, где и что искать. И главный риск в том, что нет полной уверенности в данных, потому что добавление новой статистики — тоже написание кода. Здесь можно ошибиться: например, какие-то кейсы посчитать, а какие-то нет. В итоге информации много, но вы не можете ей полностью доверять и принимать решения на ее основе.
Выход из этой ситуации простой — добавить немного правил и регламентов, описать процессы. Например, добавление статистики нужно тестировать, метрики — описывать. И главное, не заниматься всем подряд, а фокусироваться на движении в правильном направлении.
Как рационально тратить время команды аналитики
Когда данных много, легко увлечься ими и целыми днями изучать то, что никому не нужно, и создавать дешборды, которые никто не откроет.
Простая проверка на логику, когда к команде аналитики приходят с новой задачей, — задавать вопрос «Что мы будем делать, когда посчитаем это число?». Нужен ли этот ответ нам прямо сейчас для решения задачи? Если число повлияет на продуктовый роадмап, надо считать. Если задач много, можно применить подход из двух вопросов, чтобы рассортировать их. Первый — «Это Actionable или Exploration?». Actionable — то, что может поменять работу команды и планы. Exploration — это когда вы пытаетесь больше узнать про окружающий мир. Последнее тоже полезно, но обычно не приоритетно.
Второй вопрос: «Это Critical или Nice to have?» Critical значит, что знание нужно здесь и сейчас, а Nice to have — что это не срочно. Получается, что все задачи по аналитике можно легко раскидать по четырем квадратам, чтобы сразу было понятно, в каком порядке их решать. Сначала Critical и Actionable, потом Exploration, потом Actionable и Nice to have и так далее.
Уровни метрик
Следующий важный момент — появляются красивые дешборды с графиками просмотров. С одной стороны, просмотр постов в ленте — понятная метрика. Но каждый продакт воспринимает график по-своему. Кто-то может думать, что это только пользователи мобильных устройств, кто-то считает, что это просмотры на стене, а не в ленте. Сложность в том, что даже у такой простой метрики возникает масса нюансов:
- засчитается ли просмотр, если ленту открыли из личных сообщений?
- засчитаются ли просмотры рекламы?
- засчитается ли один или два раза, если пользователь быстро прокрутил ленту вниз, а потом вернулся?
- засчитается ли просмотр, если пользователь смотрит ленту, когда нет интернета (например, в метро)?
Кажется, что каждый вопрос по отдельности не принципиальный, но в итоге можно 5% событий потерять и 3% событий посчитать два раза. В итоге получится бессмысленный график. И если продакт-менеджер не знает ответы на эти вопросы, он выбирает интуитивно удобную ему трактовку.
Сложно принимать правильные продуктовые решения, используя неправильные данные.
Если добавить, что в графике ещё есть вероятность ошибки, потому что разработчик забыл посчитать просмотры с мобильной версии веба, картина становится еще хуже. Ошибочные метрики могут быть опаснее для продукта, чем отсутствие метрик.
Избежать такой ситуации помогают регламенты и два разных уровня метрик. Первый уровень — протестированные базовые метрики, на основе которых строятся квартальные планирования, KPI и прочие ключевые показатели. Второй уровень — метрики в режиме свободного полета, для которых не нужно составлять точную документацию. Они нужны, чтобы быстро проверять гипотезы. При этом все должны понимать, что эти метрики не такие качественные, зато всё можно сделать быстро.
Документация для базовых метрик важна, потому что продакты и аналитики в команде меняются. Может возникнуть ситуация, когда кто-то уйдет, а новые члены команды не смогут разобраться, что значит график просмотров, как он считается и почему появился. Тогда придется повторять значительную часть уже проделанной работы.
Разумеется, не все в команде будут рады необходимости все тестировать, описывать и проверять. Эту идею тоже нужно продать. Говорить про data-driven правильно не в тот момент, когда добавили много непонятных графиков, а когда команда уверена в данных и может использовать их для принятия продуктовых решений.
Риски data-driven подхода
Когда много метрик, экспериментов и всё основано на данных, тоже есть несколько сложностей для продуктовой команды. Во-первых, все начинают думать, что если нельзя что-то измерить, значит, и делать это не нужно. Такой подход усложняет развитие продукта и приводит к тому, что вы начинаете заниматься локальной оптимизацией метрик.
Во-вторых, важно помнить, что даже когда есть красивые дешборды, hadoop, толковый аналитик и графики распределения, на самом деле вы все равно работаете со средним по больнице. Потому что всегда будет какой-то кейс, в котором все графики выросли, но это потому что 80% пользователей стали жить лучше. При этом 15% пользователей стали жить чуть-чуть хуже, а у 5% пользователей ничего не работает. С одной стороны, вы радуетесь подросшим графикам, с другой — эти 5% пользователей через неделю уйдут из приложения, и их уже не вернешь. И среди ушедших пользователей может оказаться блогер-инфлюенсер с аудиторией 500 тысяч человек. Нельзя пропускать такие моменты.
Всегда есть риск сломать что-то, когда выходит очередное обновление. Поэтому не зацикливайтесь только на метриках, продолжайте общаться с людьми, смотрите, что вам пишут в поддержку, спрашивайте ключевых пользователей, что они думают о нововведениях. Бывает, что метрики выросли, но это ошибка.
Как находить точки роста
Когда вы немного разберетесь с метриками, статистика начнет становиться аналитикой. Аналитика помогает продактам понимать происходящее не только на уровне приборов и цифр — она дает подсказки.
Хорошее упражнение –– сформулировать, каким образом вы видите идеальное поведение пользователей. В случае социальной сети я сформулировал бы так: здорово, если человек заходит туда шесть или семь дней в неделю. Если меньше, значит, продукт недостаточно ценный. В ленте можно смотреть таймспент: сколько времени пользователь проводит в приложении. Если мало, наверное, лента не очень интересная.
Затем нужно выделить пользователей, которые ведут себя «правильно» — так, как мы ожидаем, и по-другому — то есть менее активно. Сформулировать, что такое «правильно», это творческий и нетривиальный процесс. Во-первых, вся команда должна одинаково понимать, что такое «правильно использовать продукт». Все должны работать в одном направлении. Во-вторых, эта метрика должна быть чувствительной и быстрой. Например, если мы считаем количество заходов в неделю, то минимальная длина эксперимента — неделя.
В чем профит? Все пользователи, которые ведут себя менее активно, являются точкой роста для продукта. Надо их выделить, понять, чего им не хватает, и активнее доносить до них ценность и нужные фичи.
Самое интересное — понять истинную причину, почему продукт используют меньше или не так, как хотелось бы. Из популярных причин можно выделить две группы. Первая — конкуренты делают лучше или людям в принципе не нужен продукт, вторая — это баги или недостаточно продуманный флоу пользователей или онбординг. Например, пользователю не приходит СМС при регистрации или он не дошел до нужной фичи и не почувствовал ценность продукта. И как раз для этих задач нужна хорошая аналитика и много данных.
Выводы
- Надо правильно выбрать момент развития продукта и команды для построения data-driven подхода. Сперва оцените, стоит ли инвестировать в это деньги, время и усилия команды. Иногда это только всё усложнит.
- Если данных много, но в аналитике пока царит хаос, это состояние нужно поскорее пройти, потому что оно скрывает массу опасностей для продукта. На этом этапе важно наладить процессы и опираться на здравый смысл.
- Если вы уже data-driven, не нужно скатываться только в цифры и графики, правильно быть data-informed. Важен сам продукт. Нужно помнить, что аналитика не поможет увидеть всю картину целиком. Продолжайте общаться с людьми, чтобы получать инсайты.
- Чтобы найти точки роста, нужно выделять пользователей, которые ведут себя не так, как вы ожидаете. Им нужно давать подсказки и вести к идеальному сценарию использования продукта.
Благодарим за подготовку статьи редактора Елену Егину.
