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

Меня зовут Екатерина Левитина, в 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

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

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

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

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

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

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

Настройте бэкапы дисков по расписанию

Сделайте расчет под нужный объем и количество копий.
Рассчитать

Что еще почитать по теме

T-Rex 25 апреля 2022

Первые телефоны, мини-ПК и плееры: истории про любимые гаджеты из прошлого

Собрали в подборку воспоминания о девайсах из прошлого, которые запали в душу и по которым сильно скучаем.
T-Rex 25 апреля 2022
Сергей Ковалев 21 апреля 2022

Скрипты по сусекам: инструмент для контроля количества серверных комплектующих

Рассказываем про самописный скрипт, который стал дополнительным инструментом управления постоянно меняющимися цифрами наличия комплектующих.
Сергей Ковалев 21 апреля 2022
Дарья Маташина 15 апреля 2022

Как провести код-ревью: советы по применению

Разбираемся, кому и когда нужна (и не нужна!) дополнительная проверка кода, и каких ошибок избежать на старте.
Дарья Маташина 15 апреля 2022

Новое в блоге

Сравнение способов организации мультиклауд-решений

Рассказываем о типах мультиклауд-решений и схемах подключения к зарубежным облакам

Готовые кластеры Kubernetes: легкий старт, автоматизация и другие преимущества перед self-hosted

Рассказываем, чем отличается Managed Kubernetes от самостоятельного развертывания инфраструктуры. Объясняем, кому подойдет решение.
T-Rex 18 мая 2022

Что такое терминальный сервер и зачем он нужен

Разбираемся, что такое терминальный сервер, чем он похож на VDI и как подобрать сервер под роль терминала.
T-Rex 18 мая 2022