Иногда вижу, что дизайнеры и исследователи не знают, как подступиться к продуктовой аналитике. Они не понимают
а) как её настроить (что писать в ТЗ на настройку, какие события нужно отслеживать),
б) за какими метриками следить в настроенной системе и как с помощью аналитики улучшать продукт.

Я не продуктовый аналитик, но расскажу о своем опыте, так как не видел внятного базового объяснения для таких, как я, исследователей и дизайнеров.

Шаг 1 - понять целевое поведение в интерфейсе
Вы как дизайнер создаете или тестируете интерфейсы.
Допустим, вы работаете над чекаутом, дашбордом, или новой навигацией.

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

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

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

• Идеальный чекаут -> тот через который проходят все без потерь -> видим в аналитике последовательность страниц, в которой аудитория не уменьшается (воронка без сужения)
• Идеальный каталог -> люди быстро находят нужную информацию и переходят на нужную страницу -> среднее время на странице каталога низкое, после переходов на страницы второго уровня нет возвратов назад к каталогу
• Идеальный дашборд -> его регулярно используют для быстрой оценки ситуации -> высокое dau/mau (заходят много раз за месяц), короткое время на странице дашборда (т.к. быстро принимают решение, что делать дальше).

Часть событий отслеживаются аналитическими системами "из коробки" (посещения отдельных страниц, время на странице), часть нужно настраивать (заполнение отдельных полей, отслеживание системных ошибок).

Сначала может быть сложно описывать целевые сценарии с помощью событий. Если это так, попробуйте представить, как кто-то работает с интерфейсом оптимальным образом, что в этот момент пишется в логах? Это оно.

Шаг 3 - на основе событий подобрать метрики
Когда у вас есть целевое поведение, описанное в виде событий на сайте, вам легче придумать метрики, которые покажут качество интерфейса. Они отражают, насколько реальное поведение в продукте близко к целевому.

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

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

Используйте типовые подборки событий
Есть типовые способы описывать успешные сценарии и частые проблемы - воронка (успешность линейных сценариев), bounce rate (проблемы с маркетингом/плохая навигация), rage clicks (недостаток обратной связи в интерфейсе), конверсия форм (качество формы и понятность описания), графы для сложных и разветвленных сценариев (например тут https://t.me/uxread/144).

Есть даже типовые способы описывать успешные сценарии для разных продуктов. Вы можете погуглить metrics for content products, или типичные дашборды для eсommerce. Такие подборки не всегда хороши, но они дают понимание, как качество продуктов можно описывать в виде событий и метрик.

Подытожим
Чтобы понять, какие события отслеживать, составьте в уме цепочку:
Зачем продукт/интерфейс нужен -> как выглядит идеальный сценарий пользователя -> как этот идеальный сценарий можно описать в виде событий на сайте.

Если настраиваете аналитику для большого продукта, начните с нескольких ключевых сценариев.

#Frameworks