Бета-тест сервиса с помощью продуктовой аналитики. Кейс

Как провести эффективный бета-тест B2B сервиса с помощью продуктовой аналитики

Екатерина Левитина Екатерина Левитина Менеджер продуктов 23 марта 2022

В кейсе рассказываем, зачем решили использовать Amplitude — систему продуктовой аналитики для анализа поведения пользователей в интерфейсе нового сервиса.

Изображение записи

Меня зовут Екатерина Левитина, в Selectel я развиваю сервис бэкапы, или резервное копирование, по расписанию. В тексте расскажу, как и зачем в компании решили использовать Amplitude — систему продуктовой аналитики для анализа поведения пользователей в интерфейсе.

Начну с контекста и опишу, как измеряли продуктовые показатели раньше, почему решили внедрить «новинку»‎ и как выстроили процесс. Если с инструментом вы хорошо знакомы — смело скролльте до кейса. Там рассказываю, как запустили и анализировали B2B сервис.

О Selectel и нашей панели управления

Selectel — компания с большим количеством сложных продуктов для построения IT-инфраструктуры. Для разных бизнес-задач предлагаем разные решения: например, выделенные и облачные серверы, managed-сервисы вроде кластеров Kubernetes и облачных баз данных, услуги по обеспечению информационной безопасности (защита от DDoS) и отказоустойчивости (резервное копирование).

Со всеми продуктами и услугами клиенты работают через панель управления my.selectel.

Интерфейс панели.

Продуктовая аналитика до Amplitude

С помощью систем продуктовой аналитики нам важно отслеживать в интерфейсе:

  • создание новых объектов (например, серверов, дисков, кластеров баз данных);
  • паттерны поведения клиентов (какие фичи и как часто используют);
  • конверсии (как справляются с созданием и настройкой форм).

До внедрения Amplitude работали с Google Analytics, Яндекс.Метрикой и Qlik, выгружали базы данных. Эти инструменты и сегодня отвечают на наши вопросы, но не всегда удобны для анализа эффективности отдельных сервисов компании.

Например, аналитика в Google Analytics и Яндекс.Метрике построена на базе сессий. Такой подход неудобен, когда нужно проанализировать действия конкретных пользователей в продукте. Также в этих системах большой объем дополнительного функционала для анализа маркетинговых активностей — это усложняет работу и требует времени на обучение интерфейсу.

Другая проблема связана с выгрузкой баз данных. Аналитики выполняют эту задачу недостаточно быстро, а менеджеры продуктов и UX-проектировщики не могут это сделать сами: нет нужных доступов и не владеют SQL.

Решили, что нам нужен инструмент, который позволит продактам и проектировщикам самостоятельно выбирать и анализировать данные, оперативно генерировать новые идеи и готовить эксперименты.

Екатерина Левитина, 
менеджер продукта в Selectel

«Обкатка»‎ инструмента и советы из практики

Процесс внедрения Amplitude разделили на несколько этапов — это помогло выстроить прозрачную работу с инструментом, а также ввести его для всех команд постепенно.

Старались подойти к процессу системно, учитывая «ошибки прошлого»‎. Так, в работе с Google Analytics раньше применяли локальный подход — у разных команд работали свои правила, как называть и описывать метки, хранить и систематизировать данные. Это со временем привело к путанице — например, было сложно отследить, какие события устарели, а какие еще актуальны. 

Здесь решили продумать и унифицировать важные сущности на старте — создали словарь, где зафиксировали формулировки и описали правила. Чтобы учесть все по максимуму, привлекли специалистов разных команд. Каждый отвечал за свой «кусок»‎ и предлагал идеи, метрики и возможные пользовательские сценарии. Результаты опубликовали в общей базе знаний в Confluence.

Словарь из нашей базы знаний.

Если решите пойти похожим путем и захотите внедрить новый инструмент продуктовой аналитики, делимся тремя важными советами из практики:

Не начинаете работу с нейминга и расстановки событий*

*действий пользователя в интерфейсе

В проектировании системы событий отталкивайтесь от продукта и задач пользователей. Пропустите все через смысловой фильтр двух вопросов: «Зачем я это буду отслеживать?»‎ и «Как буду использовать?»‎ После разделите события на виды — например, намерение пользователя (шаг в процессе решения задачи) и совершенное активное действие.

Помните про контекст — одни и те же действия и объекты могут «вызываться»‎ в разных частях продукта

Если пользователь может решить задачу разными способами, создайте одно событие, а в свойствах укажите, где и как он совершил действие.

В панели управления my.selectel настроить план бэкапов можно как из раздела «Диски»‎, так и из раздела «Бэкапы»‎. Для нас в Amplitude это одно и то же действие, но свойство — event_place — разное. Такой подход позволяет отслеживать, из какого раздела пользователи чаще создают план бэкапов, и не плодить похожие события.

Екатерина Левитина, 
менеджер продукта в Selectel

В названии событий отталкивайтесь не от интерфейса, а от задач пользователей

В нейминге лучше не использовать названия компонентов интерфейса: он может динамично меняться. Пользователи и задачи — более стабильные сущности.

Кейс: работа с Amplitude при запуске бета-теста нового сервиса

В 2021 году мы запустили новый продукт — бэкапы по расписанию. Это сервис облачной платформы Selectel, с помощью которого можно настроить автоматическое резервное копирование данных.

Пример работы продукта: у пользователя есть облачный сервер с сетевыми дисками и необходимо, чтобы данные на них регулярно и стабильно сохранялись в надежном месте. Для этого он создает расписание бэкапов и настраивает их по удобному плану, чтобы в случае ошибки или сбоя восстановить все без потерь.

Первое время сервис работал в режиме бета-теста и был бесплатен для пользователей: они могли протестировать новый продукт, а мы — глубже исследовать интересные клиентам задачи, собрать и реализовать идеи для улучшений.

Какие данные отслеживали: 

  • количество пользователей в динамике (в сумме и по регионам);
  • количество созданных расписаний бэкапов;
  • конверсию формы настройки резервного копирования;
  • восстановление данных из резервной копии (последний шаг воронки);
  • кто совершает целевые действия и целевые события (эта информация нужна была для поиска респондентов и проведения глубинных интервью).

Продумали события, завели их в систему и построили дашборды для визуализации.

Какие результаты получили:

  • Нашли узкие места формы и сгенерировали идеи, как увеличить конверсию. Часть проблем была на стороне восприятия интерфейса — например, сложные и непонятные поля, часть — на технической стороне. Выяснилось, что в форме был баг, из-за которого она «залипала»‎.
Старая и новая версии формы. 
  • С помощью инструмента User streams отследили, как пользователи проходят по шагам внутри продукта. Так, заметили, что они не понимают, что делать после восстановления данных из бэкапа. Сейчас работаем над дополнительными подсказками в интерфейсе — они лучше навигируют по процессу и помогут решить цели клиентов.
  • Увидели, что пользователи попадают на сервис только через основной раздел. Дополнительные страницы и точки входа популярностью не пользуются. Эта информация помогла принять решение о распределение сил — направили их на улучшение основного экрана обращения к сервису. Ненужные куски кода поддерживать не будем.

Также использовали Amplitude как способ поиска заинтересованных в разговоре клиентов — для проведения глубинных интервью. Так получили один из самых важных инсайтов: значительная часть пользователей включала сервис, но не тестировала — не доходила до ключевого с точки зрения ценности продукта этапа воронки.

От продукта, ценность которого вы не испытали, проще отказаться, чем от того, что реально решает вашу проблему. Наша задача сейчас — сократить промежуток между тем, как пользователи включили сервис, и получили ценность.


Екатерина Левитина, 
менеджер продукта в Selectel

Другой инсайт связан с визуализацией пользы: людям недостаточно знать, что бэкап сделан. Они хотят видеть, за какое конкретно время это произошло — понимать скорость копирования.

Вместо выводов

Чем раньше внедрите в продукте аналитику, тем быстрее сможете понять, как он работает, какие есть проблемы у реальных пользователей и что делать дальше. В итоге сэкономите время команды, сократите риск «переделок»‎ и ускорите релизы. 

Инструментов по работе с данными сейчас немало, но не все могут полно ответить на вопросы о поведении пользователей. Другой важный критерий при выборе — скорость получения ответов на вопросы команды. Для быстрых решений нужен соответствующий сервис.

Планы по развитию сервиса

Бэкапы по расписанию вышли из беты в коммерческий релиз. Сервис доступен для сетевых дисков виртуальных машин. В ближайших планах — реализовать поддержку инкрементальных бэкапов (так копируются только файлы, которые изменились со времени предыдущего резервного копирования) и предоставить больше опций для надежного хранения резервных копий.