Для того, чтобы развивать продукты в нужном (и прибыльном) направлении, необходимо тщательно отслеживать поведение пользователей и их реакцию на те или иные изменения. Мы в Skyeng уделяем много внимания аналитике, и в этой статье расскажем про то, как с помощью чего отслеживаем показатели наших мобильных приложений Aword и Words.
Зачем нам аналитика
Для того, чтобы понимать, все ли в порядке с нашими продуктами и правильно ли они развиваются, мы используем некоторое количество показателей (метрик), за которыми неустанно следим. Метрики могут быть ключевыми и очевидными (деньги для мобильного приложения Aword) или не такими основополагающими, но все равно важными: количество активных пользователей в неделю, количество установок, конверсии в оплату, средний чек, возвращение пользователей, периодичность использования на разных этапах и т.д. У любого продукта есть набор метрик, позволяющих определить, в правильном ли направлении движется его развитие.
Сейчас для нас особенно важны метрики продукта Aword (iOS, Android): это новый продукт, он продолжает активно развиваться, и мы должны держать руку на пульсе. Например, мы делаем обновление – выкатываем новые алгоритмы, меняем какой-то экран, добавляем какую-то фичу – нам важно видеть, как это сработало, поняли и приняли ли пользователи новинку. Разумеется, мы проводим опросы пользователей, читаем обращения наших клиентов, но мы делаем продукт для огромного количества людей, с каждым из которых не поговоришь. Поэтому для нас метрики – это своего рода «объективный показатель», некое число, на которое можно уверенно опереться. Если мы выкатываем какую-то фичу, на которую потратили кучу времени и ресурсов, а про нее узнали и начали использовать 2 процента нашей аудитории – это очень плохо. Это значит, что либо мы изначально приняли неправильное продуктовое решение и это новшество никому не нужно, либо как-то неправильно его преподнесли.
В случае с веб-приложениями у нас уже есть опыт, накопленный с образовательной платформой Vimbox: мы знаем, как следить за их эффективностью, у нас есть базы запросов, есть внутренняя статистика. Когда мы начали планировать организацию аналитики по мобильному приложению, быстро поняли, что сделать это будет не так просто. Мы оказались перед дилеммой: взять разработчика аналитики в штат, или же использовать сторонние ресурсы. В случае развивающегося бизнеса, существующего на инвестиции, второй вариант предпочтителен; политика нашей компании предусматривает максимальное использование сторонних решений, пока есть такая возможность. В конце концов, у коммерческих систем аналитики есть штат классных разработчиков, а не один человек, как было бы у нас. Важно также, что у них есть поддержка.
Аналитических систем для мобильных приложений очень много, и в них можно быстро запутаться. Мы не знали, какие из них хорошие, какие плохие, каким из них можно доверять, каким не стоит, как они трекают события и т.д. Пришлось сесть и начать разбираться. Мы поставили сразу кучу систем – порядка десятка – и сравнивали их результаты. Мы консультировались с экспертами. В итоге пришли к выводу, что у нас всегда должно быть как минимум две аналитические системы, разделенные по сфере оценки.
Продуктовая: все значимые действия пользователя должны создавать обсчитываемое событие. “Значимые” действия могут быть разными на разных этапах развития приложения, но их должно быть достаточно для составления четкой картины. Пользователь нажал кнопку «начать» – нам отправляются данные. Вышел из приложения – отправляются данные. Начал тренировку, закончил – все отправляется. С помощью этих данных мы делаем выводы по продуктовым решениям, вносим какие-то изменения: меняем размер расположения элементов, порядок прохождения экранов и их количество, цвета, тени, шрифты и т.д.
Маркетинговая: более сложная схема, позволяет смотреть, откуда пришел пользователь, с какой рекламной кампании, зарегистрировался или нет, оплатил или нет, можно оценивать эффективность каналов рекламы. Выглядит стандартно, как в вебе, но на самом деле не совсем: есть неочевидные вещи, сложные штуки, для понимания которых пришлось перелопатить огромное число разных аналитических систем. Но это тема отдельной статьи, которую мы обязательно напишем (и ускоримся, если вы напишите в комментариях, что она вам интересна).
Выбор продуктовой аналитической системы
При выборе инструмента для нас было важно, чтобы он был недорогим или бесплатным. Поэтому сразу отпала Mixpanel, знаменитая система продуктовой аналитики, которая делает все, что нужно, очень хорошо, но у которой в тот момент были не самые щадящие условия подписки: через три месяца триала она становилась платной и дорогой — в нашем случае $999/мес.
Остались Facebook Аnalytics, AppMetrica, Amplitude и adjust.
adjust быстро отвалился, потому что он больше подходит для маркетинговой аналитики, не дает возможности анализировать мелкие события: нажатия кнопок, действия пользователя; плюс у него ограниченный по времени триал.
Система аналитики AppMetrica оказалась для нас не очень удобной. Поскольку у нас первое время параллельно работало несколько аналитик, мы имели возможность сравнивать данные. При анализе часто возникала ситуация, когда сперва показатели всех систем примерно одинаковы, а потом по какому-то событию у AppMetrica внезапное расхождение процентов на 20-30. Тем не менее, AppMetrica работает у нас в качестве запасной боевой. Она не грузит систему, в целом неплоха, но не очень настраиваема. Нам нужно строить воронки по событиям и по пользователям, знать, что каждый из них сделал – установил приложение, запустил, начал тренировку, закончил, начал еще одну и т.д. В AppMetrica мы можем увидеть, например, что приложение установили 600 человек и 200 запустили. Но мы не знаем, входят эти 200 в первые 600, или это старые пользователи. Нет возможности увидеть, является ли одно число подмножеством другого. Но она бесплатная, что для нас важно.
От Facebook Analytics мы более-менее отказались, потому что данные сильно разнились с другими аналитиками: по одному событию расхождение составляло 10-25%. Ее преимущество в том, что, если трекать события по пользователям, можно настраивать рекламные кампании в FB и «Инстаграме» по этим событиям. Можно, например, запускать рекламу только на тех пользователей, которые прошли тренировку ровно 3 раза. Плюс к этому, есть возможность lookalike – запуска рекламы на людей, похожих на наших пользователей (любит собачек, водит машину, смотрит «Симпсонов», в этом духе). Эта аналитика бесплатная, в ней можно строить воронки, трекать события и деньги, это одна из немногих аналитик, умеющих работать и с продуктовыми, и с маркетинговыми метриками. Но числам мы не очень доверяем, к тому же она очень грузит систему (которая у нас и так передает много данных).
Наконец, Amplitude. Очень круто трекает события, есть возможность интеграции с другими системами: Optimizely, Slack, куда она может присылать метрики, что очень удобно. Ну а самое главное – достоверные числа (на основе нашей собственной базы данных), масса возможностей настройки; в платном виде позволяет использовать собственные запросы sql. Ключевое для нас – есть воронки, точные цифры, можно измерять деньги. Мы используем эту аналитику и в бесплатном для студентов школы Words, и в платном «внешнем» приложении Aword, в одном в качестве ключевой метрики трекаются изучаемые слова, в другом – деньги, а результаты мы видим в одной системе. Также в Amplitude можно трекать не только события, но и данные о пользователях; получив эти данные, система приписывает ее ко всем последующим событиям. Однако пользовательская информация отправляется из нашей базы данных не сразу при регистрации, а лишь спустя некоторое время, поэтому мы не всегда имеем возможность сегментировать по типам пользователей их первые шаги.
В итоге остановились на продуктовой аналитике при помощи Amplitude (в связке с Optimizely, см. ниже) и на маркетинговой в AppsFlyer. Все системы аналитики, если они хорошие, платные и дорогие. Amplitude, например, стоит 2000 долларов в месяц, и это не расширенная версия. Однако у неё есть удобный, который нам очень подошел. Пробная версия Amplitude ограничена не количеством месяцев бесплатной работы, а количеством событий, которые можно потрекать внутри приложения за определенный период. Поэтому можно лавировать и выбирать, какие события отслеживать. За счет этого мы почти всегда помещаемся в ограничение бесплатного плана Amplitude (10 млн событий в месяц).
Эксперименты
Запускаем мы свои эксперименты двумя путями. Первый, простой – через Optimizely. Это крутой инструмент, его любят разработчики, не нужно сильно заморачиваться на тему кода. Можно легко создать несколько вариантов решения, чью эффективность надо сравнить: например, можно сделать один и тот же экран, но с кнопками разных цветов. Эксперимент идет в параллели, половина пользователей отправляется в одну версию, другая – в другую. По статистике можно делать выводы: например, возвращались чаще с красной кнопки, а с синей зависали в приложении больше.
Но этих результатов обычно мало, нам в том числе. Нам надо было смотреть, как пользователь двигается по воронке, что пользователи делали после того, как нажали на условную синюю/красную кнопку. Поэтому у нас есть второй способ экспериментов, где пригодился Amplitude (эти две системы встраиваются друг в друга). Данные из эксперимента Optimizely мы интегрируем с системой аналитики Amplitude, где имеем возможность видеть, что дальше произошло с пользователями, которые видели кнопку определенного цвета.
Optimizely тоже не самый дешевый инструмент, триал заканчивается через два-три месяца, мы постарались уместить в это время максимальное количество экспериментов. Теоретически их можно осуществить на собственном бекенде, просто раздавая каждому пользователю свойство «красная» или «синяя кнопка», а потом в Amplitude выбирать их смотреть статистику. С Optimizely это можно делать на фронтенде.
Примеры
Экран подписки
У нас был довольно долгий путь пользователя от момента установки приложения до момента совершения покупки. Прежде, чем он увидит экран с предложением выбрать тариф для продления подписки, он должен был пройти несколько тренировок, учить слова. Мы решили сократить этот путь и позволить пользователю ознакомиться с вариантами подписок сразу после прохождения первой тренировки, показав pop-up с соответствующим предложением.
Как следствие, мы увеличили посещение этой страницы пользователям в среднем в 2 раза и увеличили конверсию в оплату на несколько процентов. Проверяли результаты мы с помощью AppMetrika. После успешного эксперимента было принято решение оставить такой Pop-up.
Окно регистрации
В первоначальном варианте у нас было серое окно регистрации нового пользователя. Мы не стали уделять этому моменту особое внимание, сместив акцент на более важные элементы приложения. Спустя какое-то время мы вернулись к этому вопросу и сделали нормальный, яркий вариант, принесший свои плоды.
Конверсия в регистрацию увеличилась на 13% до 95%. Измерения проводились с помощью Amplitude.
Выводы
Использование аналитических систем позволяет нам оценивать результаты вносимых в мобильное приложение изменений. Чтобы улучшать приложение, надо обладать конкретными цифрами; делать новые фичи дорого, а выяснить, насколько они нужны (или оказались оправданы), без аналитики невозможно. Теперь мы можем смотреть результаты экспериментов, запущенных в параллели, видеть результаты любой фичи, которую мы выкладываем, и повышать качество приложений на основе цифр из аналитических систем.
Традиционно напоминаем, что у нас есть интересные вакансии. Особенно сейчас интересна позиция Full-Stack разработчика — это работа мечты! Скорее, скорее кидайте нам свои резюме!
Автор: Skyeng
