На старте очень важно определить события, которые вы будете отправлять и отслеживать — при этом сделать это важно даже до того, как вы начнете пользоваться какой-либо платформой событийной аналитики (event-based analytics). Речь идет о продуманной архитектуре событий для анализа поведения пользователей.
Перед вами перевод бесплатного курса от Amplitude «Data taxonomy playbook». Над переводом работали Георгий Бирюков, Ринат Шайхутдинов и Оля Жолудова.
Amplitude — система продуктовой аналитики, которая помогает анализировать поведение пользователей и подсвечивает идеи для совершенствования продуктов.
Среди клиентов Amplitude: Dropbox, PayPal, Autodesk, Atlassian, Walmart, Adidas, Intuit — более 50 000 клиентов по всему миру, среди которых 26 компаний из Fortune 100, Microsoft, PayPal, Under Armour, Hubspot, Autodesk, Booking.com и X/Twitter. У системы три тарифных плана: Starter, Growth, Enterprise. Стоимость Growth-плана достигает $36 000/за год. Starter — бесплатный. Компания основана в 2014 году.
Среди самых частых ошибок проектирования карты событий: пропущенные события, неверное присвоение имен и неправильное использование свойств — все это затрудняет анализ и мешает выжимать ценность из потоков данных.
Содержание:
- В первой части мы разберем как таксономия данных помогает исследовать опыт пользователей с вашим продуктом | Глава 1
- Во второй части мы подробнее затронем два ключевых элемента таксономии данных — события и свойства | Глава 2
- И наконец, в третьей части мы дадим несколько отраслевых рекомендаций по выстраиванию вашей таксономии данных с нуля | Глава 3
Если вам важно настроить систему аналитики в вашем проекте, то обратите внимание на материал Фатиха Коджа (Fatih Koca), руководителя направления аналитики стратегического планирования в Mixpanel: Метрики продукта: все о том, как выбрать подходящие для анализа, посчитать и улучшить продукт →
Ремарка о качестве данных
При настройке событий, очень важно, сразу же задать набор правил управления данными (data governance rules) и придерживаться его. Соблюдение таких правил обеспечивает продуманность таксономии* и будет гарантировать, что команда применяет инструмент аналитики (например Amplitude) с умом и скоро начнет извлекать из данных значимые результаты.
Таксономия — это табличка с перечислением всех событий, свойств и их описаний. Таксономия помогает ориентироваться в данных, которые собираются о пользователях и особенно полезна на старте при знакомстве с продуктом новеньким в продуктовой команде.
Общие моменты, которые следует учесть при формировании бизнес-правил:
- Убедитесь, что новые данные соответствуют вашим целям/сценариям использования/KPI (goals/use cases and KPIs).
- Следуйте согласованному порядку присвоения имен событиям.
- Названия событий должны иметь согласованный регистр и соответствовать рекомендациям по регистру и форматированию (casing and formatting guidelines).
- Рассмотрите возможность сократить длинные строки для улучшения читаемости.
Прежде всего, следите за тем, чтобы ваш подход был непротиворечивым. Например, если вы отслеживаете два события “Оформить Отправленный Заказ” ('Checkout Submitted Order') и “Оформить отправленный заказ” ('Checkout submitted order'), они будут рассматриваться как два разных события и их нельзя автоматически объединить. Кроме того, вы собьете с толку других участников команды, пользующихся аналитическим инструментом.
Также рекомендуем больше дельных практик управления событийной аналитикой в нашем видео.
Шаг 1. Определите краткосрочные бизнес-цели (business objectives)
Над чем сейчас работаете вы и ваша команда? Какова ваша общая цель? Зачем вы вообще применяете инструмент аналитики (например Amplitude)? Как инструмент аналитики может помочь вам достичь самых разных краткосрочных бизнес-целей.
Например, вот несколько типичных долгосрочных целей (goals) клиентов Amplitude:
- Корректировка продуктовой стратегии (Setting product strategy)
- Повышение ROI (Improving acquisition ROI)
- Вовлечение в целевое действие (Targeting engagement)
- Оптимизация конверсии (Optimizing conversion)
- Повышение Retention и LTV (Increasing retention and LTV)
После определения главной долгосрочной цели (overarching goal) вашей организации, следующий шаг — задать набор ключевых показателей эффективности (KPI). KPI — это метрики, на улучшении которых вы сосредоточитесь для достижения своей долгосрочной цели.
Предположим, что ваша краткосрочная бизнес-цель — оптимизировать конверсию. Вашими KPI могут быть:
- Улучшение конверсии онбординга (Improving onboarding conversion)
- Улучшение конверсии в покупку в конверсионной воронке? (Improving checkout funnel conversion)
Их важно определить до того, как начнете думать над таксономией данных, чтобы отправлять верные события для отслеживания KPI и достижения ваших целей.
Шаг 2. Соберите карту путей пользователей (user journey)
Приступая к созданию таксономии событий не забывайте о том, как конечный пользователь знакомится с вашим продуктом. Ваша таксономия должна помогать делать анализ на трех разных уровня:
- Счетчики событий (Event counters): среднее количество пользователей за день/месяц, общее количество покупок и так далее.
- Воронки и конверсии (Funnels and conversions): показатели удержания (Retention), конверсия воронки (funnel conversion), кривая опытных пользователей (power user curve chart).
- Поведенческая аналитика: влияние выполнения действий на другие метрики.
Важно разбираться в своем продукте настолько хорошо, чтобы представлять как выглядит путь типичного пользователя от новичка (casual user) до опытного пользователя (power user). Идея заключается в том, чтобы понять факторы, побуждающие пользователей переходить из одного состояния в другое.
Отслеживание четко определенных событий в этих ключевых областях поможет лучше проанализировать закономерности, которые помогают или препятствуют продвижению пользователей в вашем продукте.
Шаг 3. Изучите критические пути в продукте (critical paths)
В каждом приложении есть критические пути (critical paths). Критический путь — это последовательность действий, соответствующая цели вашего продукта.
Например, критическим путем в e-commerce может быть:
Search → Browse Products → Add to Cart → Checkout → Order Confirmation
Поиск → Просмотрел продукты → Добавил продукты в корзину → Оформил заказ → Подтвердил заказ
Для игрового продукта критический путь может начинаться, когда пользователь открывает приложение и ему предлагается зарегистрироваться, а затем пройти обучение по игре.
Вы можете разделить этот процесс или путь онбординга на серию событий: App Open', 'Registration - Personal Info Populated', 'Registration - Avatar Selected', 'Registration - Complete', 'Game Tutorial - Started', and 'Game Tutorial - Ended (прим. ‘Открытие приложения’, ‘Регистрация - Заполнение личных данных’, ‘Регистрация - Выбор аватара’, ‘Регистрация - Завершение’, ’Игровой туториал - Начато’ и ‘Игровой туториал - Пройден’).
Затем посмотрите и выберите тип отслеживания (tracking), который поможет лучше понять этот критический путь (critical path) и сценарии использования (flows) вокруг него. Например, недостаточно просто разобраться сколько людей оставили заказ или прошли туториал — но важно понять, какие факторы побудили их выполнить это критическое событие.
Проекты Amplitude и таксономия данных
Проект в Amplitude — это пространство, в котором собраны все данные о событиях вашего продукта. В вашей организации проектов может быть несколько. Однако крайне важно, чтобы в вашей организации было минимум два проекта Amplitude — тестовый и рабочий. Вы всегда должны перед внедрением в рабочий проект тестировать инструментарий, с целью выявить ошибки и хранить тестовые данные отдельно от тех, что на живом (production data).
Все данные, отправленные в один проект, будут независимы от другого. Ваше общее количество проектов будет зависеть от продуктов и бизнес-целей. Например, если вы хотите увидеть полную историю пользователя и понять что значит то, что он инициировал одно событие на устройстве iOS, а другое событие в веб-версии, инструментировать все нужно в рамках одного проекта.
Примечание: Amplitude на данный момент не поддерживает кросс-проектный анализ из коробки. Все данные в проектах хранятся отдельно, если в вашей организации нет аддона Portfolio.
Однако, если ваша компания:
- Хочет отслеживать данные для нескольких продуктов
- Создает принципиально разный опыт в разных платформах (веб и мобильная версия)
- Развивает отдельные независимые команды, отвечающие за каждую платформу или продукт
Тогда вам следует настроить несколько отдельных проектов для каждой команды (продукта, платформы и так далее). Это сделает вашу таксономию данных более прозрачной и легкой для понимания.
Это первая глава | Продолжение (Глава 2) →