Веб-аналитика помогает подтверждать аналитические гипотезы в ходе доработки IT-решений. Например, на проекте нужно было понять, после какого этапа пользователь уходит с сайта. Гипотеза была такой: пользователь тратит слишком много времени на регистрацию и идентификацию личности, и не дождавшись окончания этапа, уходит с сайта.

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

Привет! Меня зовут Екатерина, я QA-специалист компании SimbirSoft. В этой статье расскажу, как нас подключили к задаче по внедрению и актуализации данных в системе продуктовой аналитики Amplitude:

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

Материал будет полезен аналитикам и QA-специалистам, маркетологам и всем специалистам, у которых есть потребность к отслеживанию поведения пользователей.

Для чего можно использовать Amplitude?

Сервис помогает:

Анализировать важные функции продукта и понимать, как клиент их использует и какие пути для этого проходит.
Отслеживать сессию конкретного пользователя в режиме реального времени.
Находить наиболее активных пользователей и определять их характерные черты.
Быстро увидеть возможные ошибки в продукте по основным воронкам.
Анализировать A/B-тесты.
Оценивать удачность новых фич в продукте по метрикам.

Для начала разберем принцип работы Amplitude:

Пользователь нажимает кнопку/заполняет поле формы в тестируемом ресурсе.
Приложение отправляет данные о событии на сервера Amplitude.
В системе Amplitude в режиме реального времени появляются данные о событии, совершенном пользователем.
Для каждого события приходит набор прописанных разработчиком параметров.

Как Amplitude использовалась на проекте?

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

Так или иначе, система сбора метрик в Amplitude была введена уже давно. Однако, у нас было несколько таблиц с ТЗ от аналитиков, которые содержали в себе неактуальные данные и также устаревшие события в системе сбора метрик.

Перед QA-специалистами стояли следующие задачи: сначала привести в порядок ТЗ, выявив необходимые изменения, а затем проконтролировать и проверить корректную настройку сбора метрик по актуальным данным.

Пример ТЗ:

Актуализацию сбора событий в Amplitude мы поделили на несколько этапов:

Этап 1

На этом этапе необходимо было «вручную» пройти каждый кейс, описанный аналитиками, повторить событие на UI-части сайта и выявить отклонения в данных Amplitude и в ТЗ. Параллельно с этим мы написали тест-кейсы для проверки большей части метрик.

В процессе поняли, что сложность задачи была недооценена, и подключили еще одного специалиста для актуализации ТЗ. Однако это не помогло ускорить процесс — задача продвигалась очень медленно. Решили дополнительно подключить минимум по одному QA-специалисту из каждой команды, поскольку по отдельности они гораздо быстрее свяжутся со своими аналитиками и будут более погружены в работу своей части приложения. Совместными усилиями мы обрабатывали заметки и исправления аналитиков, а также редактировали ранее созданные тест-кейсы.

Проблемы, с которыми мы столкнулись, и варианты решения:

Проблема разночтений в ТЗ.
Решение: сбор всей информации в одну таблицу и актуализация данных.
Долгая обработка информации одним человеком.
Решение: на каждом следующем этапе к задаче подключали всё больше специалистов. Таким образом, начиная со второй итерации, каждая команда работала со «своими» событиями. QA-специалисты могли напрямую обратиться к аналитику своей команды и быстрее уточнить информацию.

Этап 2

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

Этап 3

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

Проблема на этапе:

Изменчивые требования.
В силу того, что у заказчика быстро меняются цели, информация в ТЗ периодически устаревает. Поэтому часть из заведенных багов становится неактуальной.

Есть несколько вариантов решения проблемы изменяющихся требований:
• Вносим изменения в ТЗ и не исправляем событие, если недостающий параметр в Amplitude стал не актуален.
• Заводим баг-репорт для исправления дефекта, если недостающие\некорректные параметры актуальны и приоритетны.
• Вносим изменение в ТЗ и заводим задачу на доработку события после релиза. Если параметры нужно изменить, но они не приоритетны и задерживать релиз из-за них команда не будет.
Важно понимать, что решение зависит от приоритета события, который выставляется аналитиком.

Этап 4

Большая работа была проделана, чтобы автоматизировать проверки данных Amplitude. Команда тестирования приступила к созданию пошаговых тест-кейсов, чтобы команда SDET приступила к задаче по автоматизации тестирования.

Пример тест-кейса:

Проблема на этапе:

К смоук-тестам фич и релизов добавились проверки важных событий из Amplitude, что увеличило время релиза.
Решение: Все важные проверки были автоматизированы.

Этап 5

По мере готовности автотестов, их принимают QA-специалисты на соответствие ручным тест-кейсам.

Также готовые автотесты после приёмки используются при смоук-тестировании фич и релизов.

Собираем метрики событий в ручном режиме

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

Сначала нужно определить пользователя, которого мы собираемся отслеживать. У каждого из них есть уникальный ID, по которому Amplitude понимает, что «кнопку нажал конкретный пользователь».

На скриншоте видим, что в разделе «User Look-Up» есть поле «Search users», куда и вставляется идентификатор сессии необходимого пользователя.

Затем в реальном времени подгружается событие, которое отработало в данный момент. Например, пользователь открыл виджет чата, тогда я могу увидеть событие Open Chat в амплитуде.

В каждом событии определяем необходимые параметры. Например, можно увидеть, с какой страницы перешел пользователь, с какой платформы был запрос, версию сборки... и т.д. Нужные параметры аналитики прописывают в ТЗ.

Для отображения только нужных событий можно настраивать фильтры:

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

На сайте Amplitude мы просматриваем события и их параметры на UI. Если некоторые параметры не видны на UI, то их можно проверить с помощью запроса в Postman, есть ли эта информация в API.

Вывод

Полная актуализация сбора событий в Amplitude на нашем проекте заняла около полугода.

Для решения этой задачи задействовали всех QA-специалистов и аналитиков, по одному разработчику из каждой команды, а также выделенную команду SDET-специалистов.
В результате мы выстроили систему сбора действий, совершаемых пользователями, с актуальными событиями и их параметрами.

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

Авторские материалы для QA-специалистов мы также публикуем в наших соцсетях – ВКонтакте и Telegram.

Как с помощью Amplitude мы стали лучше понимать пользователей продукта