Вам нужна бережливая таксономия данных для масштабирования аналитики самообслуживания

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

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

Лучшие практики для обеспечения безопасности вашей продуктовой аналитики и таксономии данных в будущем

1. Вложите значительные средства в таксономию вашего первого продукта

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

• Бизнес-лидер (часто глава или вице-президент по продукту), который определит основной набор вариантов использования, которые должны быть охвачены продуктовой аналитикой.
• Технический руководитель (часто старший инженер), который будет заниматься технической стороной внедрения аналитики.

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

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

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

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

• События
• Свойства события (контекст событий)
• Свойства пользователя (контекст пользователя).

Ваша цель на этом этапе — сделать таксономию как можно более компактной в соответствии с приведенными выше вопросами. По нашему опыту, инструментов всего 20-30 событий достаточно, чтобы ответить примерно на 90% вопросов, которые постоянно задают команды.

Часто всего несколько мероприятий дают четкие ответы на распространенные деловые вопросы. Это даст вашей компании представление о реальном (а не просто предполагаемом ) пути пользователя и откроет новые идеи, такие как:

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

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

2. Держитесь подальше от низкоуровневых элементов пользовательского интерфейса

Отслеживание низкоуровневых и неважных элементов пользовательского интерфейса — это признак №1 немасштабируемой аналитики продукта, согласно нашему опыту в команде профессиональных услуг Amplitude. Часто это отражает инструментальный подход, который смешивает определения событий и свойств событий .

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

• Флажок установлен
• Кнопка нажата
• Переключить пролистнул
• Текст поля нажат

Если ваша первоначальная таксономия заполнена элементами пользовательского интерфейса, подобными приведенным выше, возможно, пришло время сделать шаг назад и перегруппироваться. Да, команда работала над улучшением процесса оформления заказа и корректировала эти элементы, но помните: цель этого процесса по-прежнему заключается в том, чтобы пользователи могли беспрепятственно перемещаться по нему. То, что бизнес хочет видеть в качестве пути пользователя в аналитике, скорее всего, это «Оформление заказа начато» → «Выбран способ оплаты» → «Выбраны детали платежа» → «Транзакция отправлена». Этот тип потока гораздо более информативен и масштабируем, чем что-то вроде: «Кнопка нажата» → «Выбран флажок» → «Нажат текст поля». Если вы все еще ищете детализацию при оценке конверсии между шагами, вы можете решить эту проблему двумя альтернативными способами:

1. Элементы пользовательского интерфейса инструмента в свойствах событий событий. Например, событие «Транзакция отправлена» может иметь свойство, указывающее, выполнил ли пользователь действие с помощью флажка, нажатия кнопки или другого элемента пользовательского интерфейса.
2. Используйте A/B-тесты, чтобы улучшить конверсию на шагах с высоким отсевом . Например, если вы наблюдаете большое падение между шагами 1 и 2, часто более эффективно запустить A/B-тестирование с измененным пользовательским интерфейсом и наблюдать за объективными результатами на вашем образце, а не проводить инструментирование нескольких элементов в процессе итерации.

3. Установите связь с бизнес-результатами

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

Благодаря хорошо инструментированной таксономии данных ваша команда может изучить множество факторов на пути пользователя, например:

• персоны
• общие пути
• влияние релизов на ключевые показатели
• драйверы конверсии
• пути пользователя
• и более

Мы видим, что команды, преуспевшие в продуктовой аналитике, всегда замыкают петлю между событиями, которые они отслеживают, бизнесом, которым они занимаются, и «игрой вовлечения», в которую играет их продукт.

(Игра на вовлечение относится к одной из трех основных «игр», в которых участвует ваш продукт: транзакция, внимание или продуктивность. Подробнее об этих методах читайте в книге Amplitude « Освоение вовлеченности ».)

Например, если ваш продукт попадает в «игру производительности», у вас может быть отличная воронка адаптации, но этой воронки недостаточно для достижения ваших бизнес-целей. Ваш продукт в конечном счете должен выполнять обещание производительности; это означает, что пользователи должны вернуться к использованию основных функций, которые повышают для них ценность (производительность). В дополнение к отслеживанию успеха вашего процесса адаптации, обязательно используйте аналитику продукта, чтобы оценить, как пользователи повторяют важные действия.

4. Не отслеживайте все сразу

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

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

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

От одного продукта к кросс-продуктовой аналитике

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

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