Привет, Хабр!Меня зовут Витя, в Selectel я работаю проектировщиком интерфейсов. В нашей команде анализом решений, связанных с пользовательским образом, занимается дизайнер. Такой подход позволяет быть ближе к пользователям и проектировать сценарии взаимодействия, продумывая метрики, на которые мы будем смотреть в перспективе, и оценивать их эффективность. Возможно, вы читали мои статьи и знаете, как мы используем PostHog в работе.

За долгую практику работы с сервисом накопилось большое количество кейсов, когда PostHog помогал мне получать и обрабатывать данные. Хочу поделиться знаниями с начинающими дизайнерами, аналитиками и продактами.

Мы используем PostHog для отслеживания ключевых метрик продуктов: конверсии, посещаемости, распределения выбора пользователей в различной функциональности, проведения тестирования и поэтапной выкатки фичей.

Дашборды: собирайте метрики, чтобы они рассказали полноценную историю

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

Управление подпиской можно найти в меню дашборда. Чтобы с дашбордами было проще работать, рекомендую использовать описание и теги.

Группировка данных: смотрите на картину в общем

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

Использование регулярных выражений (regex) в фильтре URL-события просмотра страниц поможет отфильтровать ID, метки UTM и т. д., чтобы получить нужные данные с минимумом погрешностей.

Анализируйте пути пользователей (User Paths) с помощью опции Wildcard Groups. Она позволяет обобщать данные метасимволом звездочка (*) и смотреть на ключевые сценарии.

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

Также упростить анализ пользовательских путей поможет опция Path Cleaning Rules, которая позволяет задать правила очистки URL на уровне проекта, используя регулярные выражения (regex) вместо метасимвола звездочка (*).

30+ бесплатных курсов на IT-темы в Академии Selectel

Для начинающих и опытных специалистов.

Изучить →

Когорты: разделяйте и анализируйте пользователей

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

Когорта формируется, например, по условию выполнения или невыполнения события или другому критерию, которые доступны в выпадающем списке.

Для более тонкой настройки обратите внимание на логическое объединение критериев — это может быть обязательное совпадение (логическое И) или одно из (логическое ИЛИ).

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

Когорты, часть вторая: анализируйте множество пользователей

Когда вы настраиваете критерии попадания пользователей в когорты, можете задавать не только совершение каких-либо действий, описанных в событиях, но и вхождение в другую когорту. Или наоборот — исключение пользователя из когорты. Для этого в критериях есть опции In cohort и Not in cohort. 

Рассмотрим пример, когда вам нужно получить список пользователей, которые выполнили сначала одно действие (когорта 1), а затем другое, но вместе с выполнением первого. 

В таком случае мы не учитываем последовательность совершения действий, как это бы происходило с формированием когорты при выполнении действия 1 и действия 2 по отдельности.

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

Статистические когорты: получайте больше информации

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

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

Фича-флаги: управляйте доступностью функциональности

Фича-флаги (feature flags) — это мощный инструмент, который позволяет гибко управлять доступностью функциональности для ваших пользователей. Как часто вы сталкивались с тем, что кому-то из ваших знакомых доступна дополнительная функциональность в интерфейсе, а вам нет? Именно за такое поведение отвечают фича-флаги.

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

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

В наборе условий могут когорты пользователей. Вспоминаем, что когорты могут быть динамическими, и получаем дополнительную гибкость в управлении доступом. Кроме этого, можно дать доступ не на всю когорту, а на ее часть. Например, на скриншоте видно, что в наборе 1 определен доступ для 20% пользователей из когорты. Если увеличить это значение до 40%, то PostHog автоматически их посчитает и добавит нужное количество пользователей.

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

Плейлисты: упростите рутинную работу по просмотру записей

Один из самых продуктивных способов выявить проблемы, с которыми сталкиваются ваши пользователи, — это посмотреть на ваш интерфейс их глазами. В PostHog есть записи экранных сессий того, как пользователи проходят запланированные вами сценарии. Каждый раз заходить в аналитику и отфильтровать нужное событие может быть утомительно, поэтому рекомендую использовать плейлисты.

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

Еще одна удобная опция плейлиста в том, что он позволяет закреплять интересующие вас записи, например, для последующего анализа или показа коллегам.

Иными словами, плейлисты — это простая функциональность, которая позволяет экономить много времени и сосредоточиться на важном.

Действия: группируйте события для более глубокого анализа

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

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

Другим сценарием использования Actions может быть набор разных пользовательских событий (Custom event), выполнение которых можно объединить в одно и использовать в аналитике.

Аннотации: упростите понимание и аналитику данных

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

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

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

Бонусная фича: делитесь данными с остальными членами команды

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

Бывает, что не у всех членов команды есть доступ в PostHog. Тогда можно использовать возможность встраивания графика в вашу внутреннюю документацию. Для этого перейдите в опции графика и выберете «Поделиться» или «Встроить». Полученную ссылку можно добавить в доступное для всей команды место. 

Заключение

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

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