Как мы улучшили бета-тест B2B сервиса с помощью продуктовой аналитики: кейс
Привет! Меня зовут Екатерина Левитина, я менеджер продукта в Selectel. В тексте расскажу, как и зачем в компании решили использовать Amplitude — систему продуктовой аналитики для анализа поведения пользователей в интерфейсе.
Начну с контекста и опишу, как измеряли продуктовые показатели раньше, почему решили внедрить «новинку» и как выстроили процесс. Если с инструментом вы хорошо знакомы — смело скролльте до кейса. Там рассказываю, как запустили и анализировали новый сервис — бэкапы, или резервное копирование, по расписанию.
→ Кстати, если у вас есть истории из практики или мнение по теме, пишите в комментариях.
О Selectel и нашей панели управления
Selectel — компания с большим количеством сложных продуктов для построения IT-инфраструктуры. Для разных бизнес-задач предлагаем разные решения: например, выделенные и облачные серверы, managed-сервисы вроде кластеров Kubernetes и облачных баз данных, услуги по обеспечению информационной безопасности (защита от DDoS) и отказоустойчивости (резервное копирование).
→ О том, как устроены дата-центры Selectel, рассказываем и показываем в видеоэкскурсии.
Со всеми продуктами и услугами клиенты работают через панель управления my.selectel.
Продуктовая аналитика до Amplitude
С помощью систем продуктовой аналитики нам важно отслеживать в интерфейсе:
- создание новых объектов (например, серверов, дисков, кластеров баз данных);
- паттерны поведения клиентов (какие фичи и как часто используют);
- конверсии (как справляются с созданием и настройкой форм).
До внедрения Amplitude работали с Google Analytics, Яндекс.Метрикой и Qlik, выгружали базы данных. Эти инструменты и сегодня отвечают на наши вопросы, но не всегда удобны для анализа эффективности отдельных сервисов компании.
Например, аналитика в Google Analytics и Яндекс.Метрике построена на базе сессий. Такой подход неудобен, когда нужно проанализировать действия конкретных пользователей в продукте. Также в этих системах большой объем дополнительного функционала для анализа маркетинговых активностей — это усложняет работу и требует времени на обучение интерфейсу.
Другая проблема связана с выгрузкой баз данных. Аналитики выполняют эту задачу недостаточно быстро, а менеджеры продуктов и UX-проектировщики не могут это сделать сами: нет нужных доступов и не владеют SQL.
Решили, что нам нужен инструмент, который позволит продактам и проектировщикам самостоятельно выбирать и анализировать данные, оперативно генерировать новые идеи и готовить эксперименты.
«Обкатка» инструмента и советы из практики
Процесс внедрения Amplitude разделили на несколько этапов — это помогло выстроить прозрачную работу с инструментом, а также ввести его для всех команд постепенно.
Старались подойти к процессу системно, учитывая «ошибки прошлого». Так, в работе с Google Analytics раньше применяли локальный подход — у разных команд работали свои правила, как называть и описывать метки, хранить и систематизировать данные. Это со временем привело к путанице — например, было сложно отследить, какие события устарели, а какие еще актуальны.
Здесь решили продумать и унифицировать важные сущности на старте — создали словарь, где зафиксировали формулировки и описали правила. Чтобы учесть все по максимуму, привлекли специалистов разных команд. Каждый отвечал за свой «кусок» и предлагал идеи, метрики и возможные пользовательские сценарии. Результаты опубликовали в общей базе знаний в Confluence.
Если решите пойти похожим путем и захотите внедрить новый инструмент продуктовой аналитики, делимся тремя важными советами из практики ↓
Не начинаете работу с нейминга и расстановки событий*
*действий пользователя в интерфейсе
В проектировании системы событий отталкивайтесь от продукта и задач пользователей. Пропустите все через смысловой фильтр двух вопросов: «Зачем я это буду отслеживать?» и «Как буду использовать?» После разделите события на виды — например, намерение пользователя (шаг в процессе решения задачи) и совершенное активное действие.
Помните про контекст — одни и те же действия и объекты могут «вызываться» в разных частях продукта
Если пользователь может решить задачу разными способами, создайте одно событие, а в свойствах укажите, где и как он совершил действие.
В панели управления my.selectel настроить план бэкапов можно как из раздела «Диски», так и из раздела «Бэкапы». Для нас в Amplitude это одно и то же действие, но свойство — event_place — разное. Такой подход позволяет отслеживать, из какого раздела пользователи чаще создают план бэкапов, и не плодить похожие события.
В названии событий отталкивайтесь не от интерфейса, а от задач пользователей
В нейминге лучше не использовать названия компонентов интерфейса: он может динамично меняться. Пользователи и задачи — более стабильные сущности.
Кейс: работа с Amplitude при запуске бета-теста нового сервиса
В 2021 году мы запустили новый продукт — бэкапы по расписанию. Это сервис облачной платформы Selectel, с помощью которого можно настроить автоматическое резервное копирование данных.
Пример работы продукта: у пользователя есть облачный сервер с сетевыми дисками и необходимо, чтобы данные на них регулярно и стабильно сохранялись в надежном месте. Для этого он создает расписание бэкапов и настраивает их по удобному плану, чтобы в случае ошибки или сбоя восстановить все без потерь.
Первое время сервис работал в режиме бета-теста и был бесплатен для пользователей: они могли протестировать новый продукт, а мы — глубже исследовать интересные клиентам задачи, собрать и реализовать идеи для улучшений.
Какие данные отслеживали:
- количество пользователей в динамике (в сумме и по регионам);
- количество созданных расписаний бэкапов;
- конверсию формы настройки резервного копирования;
- восстановление данных из резервной копии (последний шаг воронки);
- кто совершает целевые действия и целевые события (эта информация нужна была для поиска респондентов и проведения глубинных интервью).
Продумали события, завели их в систему и построили дашборды для визуализации.
Какие результаты получили:
- Нашли узкие места формы и сгенерировали идеи, как увеличить конверсию. Часть проблем была на стороне восприятия интерфейса — например, сложные и непонятные поля, часть — на технической стороне. Выяснилось, что в форме был баг, из-за которого она «залипала».
- С помощью инструмента User streams отследили, как пользователи проходят по шагам внутри продукта. Так, заметили, что они не понимают, что делать после восстановления данных из бэкапа. Сейчас работаем над дополнительными подсказками в интерфейсе — они лучше навигируют по процессу и помогут решить цели клиентов.
- Увидели, что пользователи попадают на сервис только через основной раздел. Дополнительные страницы и точки входа популярностью не пользуются. Эта информация помогла принять решение о распределение сил — направили их на улучшение основного экрана обращения к сервису. Ненужные куски кода поддерживать не будем.
Также использовали Amplitude как способ поиска заинтересованных в разговоре клиентов — для проведения глубинных интервью. Так получили один из самых важных инсайтов: значительная часть пользователей включала сервис, но не тестировала — не доходила до ключевого с точки зрения ценности продукта этапа воронки.
От продукта, ценность которого вы не испытали, проще отказаться, чем от того, что реально решает вашу проблему. Наша задача сейчас — сократить промежуток между тем, как пользователи включили сервис, и получили ценность.
Другой инсайт связан с визуализацией пользы: людям недостаточно знать, что бэкап сделан. Они хотят видеть, за какое конкретно время это произошло — понимать скорость копирования.
Вместо выводов
Чем раньше внедрите в продукте аналитику, тем быстрее сможете понять, как он работает, какие есть проблемы у реальных пользователей и что делать дальше. В итоге сэкономите время команды, сократите риск «переделок» и ускорите релизы.
Инструментов по работе с данными сейчас немало, но не все могут полно ответить на вопросы о поведении пользователей. Другой важный критерий при выборе — скорость получения ответов на вопросы команды. Для быстрых решений нужен соответствующий сервис.
Планы по развитию сервиса
Бэкапы по расписанию вышли из беты в коммерческий релиз. Сервис доступен для сетевых дисков виртуальных машин. В ближайших планах — реализовать поддержку инкрементальных бэкапов (так копируются только файлы, которые изменились со времени предыдущего резервного копирования) и предоставить больше опций для надежного хранения резервных копий.
Подпишитесь на блог Selectel, чтобы не пропустить новые обзоры, новости и кейсы из мира IT.
Читайте также: