Всем привет! Я работаю продуктовым аналитиком уже чуть больше двух лет. Мой путь начинался со стартапа и сейчас уже почти год я работаю в так называемом бигтехе. В общем, в познании я немного преисполнился и успел осознать все свои ошибки на первой работе в качестве аналитика. Сразу скажу, эта статья не претендует на премию по технической сложности, она больше для тех, кто впервые оказался в продуктовой команде и не знает, как с этим быть. Итак, приступим.
В чем проблема работать аналитиком в стартапе? Когда это твоя первая работа – примерно во всем:
Начиная с того, что в продукте очень мало данных и нет возможности проводить АБ тесты, о которых все пишут.
Заканчивая тем, что ты просто не понимаешь с чего начать и как аналитика может помочь бизнесу (ну или как оправдать свою зарплату).
Моя первая работа заключалась в том, что нужно было с нуля настроить аналитику для двух мобильных приложений и начать делать какие-то выводы на основе данных, чтобы у компании появились первые скачивания и продажи. Проблема была в том, что на тот момент я только что узнал про словосочетание «продуктовая аналитика». Но тут мне на помощь пришли разные курсы и статьи, которые примерно дали понимание о том, что такое метрики и как на их основе можно генерировать гипотезы.
Это база: метрики
Первым делом я изучил самую базу: DAU, Retention, LTV, ARPU и кучу других метрик. Затем надо было понять, как их рассчитывать и применять. Откуда взять данные? Я узнал про системы self-service аналитики, которые позволяют рассчитывать метрики и строить дашборды. Пришел к разработчикам и как-то вместе мы осилили задачу – подключили систему аналитики Amplitude, которая собирала данные с приложения в виде событий, которые можно брать за основу разных метрик. Рассчитал Retention, DAU, воронку по шагам в приложении (что-то типа: Зашли в приложение – Открыли лекцию – Прошли лекцию – Прошли тестовое задание).
Получается все готово, аналитика есть и я справился с подключением. Но что делать дальше? Как понять, что делать исходя из каких-то непонятных значений. Ясное дело, что DAU плохой, возвращаемость (retention) тоже не айс. Плюс в курсе говорилось, что нужно знать метрики ROI, ARPU, LTV, а их рассчитать не получается.
И вот он, первый совет: забейте на все эти метрики пока ваш продукт не получил хотя бы несколько тысяч пользователей. Не нужно сразу бежать и считать все метрики – на этом этапе достаточно понимать, сколько пользователей у вас есть, как это количество растет или падает в динамике, и как они справляются с этапами воронки (насколько успешно проходят через все обязательные этапы)
Генерация гипотез
Самое важное, что вы можете сделать сейчас – посмотреть на воронку и увидеть, где есть сильное падение. Допустим, в воронке регистрации у нас сильное падение на этапе начала ввода номера телефона. Может дело в том, что у нас отстойный UX и пользователи просто не могут адекватно ввести номер телефона? Вот, уже одна гипотеза. Едем проверять ее руками и идем к разработчикам с парой матерных слов с новостями, что вы заметили сильную просадку в приложении и уже знаете как ее можно пофиксить.
Продолжаем в том же духе и главное не забываем указывать на свои успехи начальнику, демонстрируя красивые презентации с тем как было и как стало. Название статьи как раз пошло от того, что мой начальник не мог понять результат моей работы, а я не мог грамотно его донести. Вообще, рекомендую презентовать результаты своей команде по методике STAR (situation, tasks, actions, results).
Получается, мы уже научились использовать метрики для того, чтобы генерить гипотезы и предлагать идеи по улучшению нашего продукта. Но здесь не нужно сильно закапываться и высасывать из пальца гипотезы. В конце концов вы можете потратить кучу времени на предложение идей, которые почти не повлияют на опыт пользователя, но зато раздуют бэклог разработчиков и с матами придут уже они.
Спросите у пользователей
В условиях недостаточности данных и недоразвитости аналитики самым главным источником гипотез будут качественные исследования. Один из вариантов – проводить интервью с пользователями (или просто с людьми, которые потенциально могли бы использовать ваш продукт). Есть множество статей на тему того, как и зачем правильно проводить глубинные интервью, и как они могут вам помочь.
Если кратко, то это позволит вам получить больше контекста об условиях, в которых используют ваш продукт, о задачах, для которых его могут использовать, и паттернах поведения пользователей. Все это можно брать и тут же генерить кучу гипотез о том, что действительно нужно пользователям.
Как провести такое исследование? Найдите несколько людей, связанных с предметной областью и поспрашивайте у них про то, как они справляются с написанием конспектов, заказом такси, арендой повербанков (или с чем там связан ваш продукт). Узнайте, в какие моменты у них возникает потребность в схожих продуктах, и как они решаются заплатить за какой-либо продукт. Главное перед этим почитайте несколько статей о том, как правильно задавать такие вопросы, чтобы получить как можно больше пользы из ответов.
Чем это лучше анализа разных метрик? Тем, что в условиях недостаточности данных метрики
во-первых, не покажут вам действительности (из-за слишком сильного разброса в данных)
во-вторых, ограничат поиски гипотез только тем функционалом, который уже есть в вашем продукте
Но ведь никто не гарантирует, что пользователям нужно именно это. Например, вы делаете приложение для аренды самокатов, но не добавляете возможность авторизации через соцсети. Анализ метрик вряд-ли подскажет вам, что пользователям в подобных сервисах важно быстро проходить авторизацию (как правило через номер телефона, ВК, Google или Apple ID). Или вы плохо подумали над прайсингом и выставили только один вариант ежемесячной подписки, а у пользователей есть запрос на оплату подписки на весь сезон сразу. Для получения подобных выводов из аналитики вам бы пришлось ждать несколько месяцев пока накопятся данные, а до тех пор вы бы упускали большую прибыль от продаж на длительный срок.
Итог: читайте статьи на тему глубинных исследований и собирайте группу энтузиастов-альтруистов, готовых помочь за приятный бонус.
АБ тесты не нужны
Вот мы подобрались к тому моменту, когда у нас накопилось достаточно много гипотез и разработчики подготовили новый UI. Нам нужно как-то его протестить, но АБ тесты проводить рано, у нас всего 1000 пользователей в месяц. Почему это проблема? Потому что в таких условиях вам скорее всего придется проводить АБ тест несколько месяцев, а это значит, что в течение этих месяцев половина пользователей будет использовать плохой UI и вряд ли захочет много платить за это. Бизнес к такому не готов, а значит нужно искать другие способы.
Выход есть! Юзабилити-тестирование вам в помощь. Юзабилити – это когда вы даете потенциальным пользователям ваш новый UI на «попробовать» и просите их найти в приложении что-то важное (например, как найти самокат на карте и разблокировать его). Вы подробно следите за ходом мыслей пользователей и записываете все, что они делают. На основе таких тестов можно открыть много нового для себя. Иногда доходит до банального: пользователи просто не могут увидеть нужную кнопку, потому что она сливается с кучей других кнопок и глаза разбегаются.
В таких тестах важно помнить, что пользователь должен максимально быстро и легко справляться с основным флоу и не ловить затупы на каких-то элементарных операциях (например, при попытке ввести промокод на скидку). Если же этого не происходит, нужно фиксировать, что пошло не так и пытаться понять, чем руководствовался пользователь в попытках найти то самое поле ввода промокода.
В отличие от АБ тестов, юзабилити тестирование не дает достоверного знания о необходимости изменений, но когда 4 из 6 пользователей не смогли быстро найти кнопку «Профиль» – это о чем-то да говорит. Плюс таких исследований в том, что они позволяют вам быстро протестировать новый функционал в условиях недостаточности данных и больше погрузиться в то, как именно пользователи взаимодействуют с вашим продуктом.
Юзабилити и глубинные интервью стоит проводить на постоянной основе, чтобы лучше понимать своих пользователей и дополнять аналитические (количественные) исследования знаниями о паттернах поведения пользователей.
Подведем итог
Фух, мы уже прям почти вышли на уровень мидла, пора просить повышение)) Ну, а если серьезно, то самое важное – грамотно выстроить процесс генерации гипотез, организовать процесс глубинных исследований и юзабилити тестирований. Если все эти инструменты вы будете использовать разрозненно, то часть ваших гипотез будет некорректна, а каких-то гипотез может вообще не появиться на свет.
Поэтому желаю справиться со всем этим, а сейчас можете поделиться своими факап историями или кейсами, в которых у вас так же взорвался мозг, как у меня когда-то.
Советую почитать: