Веб-аналитика помогает подтверждать аналитические гипотезы в ходе доработки 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.