Понятная разметка — лучший друг любого продуктового аналитика. То, как собираются данные, какие есть события и какие у них свойства, во многом определяет сколько боли будет в вашей работе. По важности — одна из топовых задач.
Осложняет дело ещё и тот факт, что кроме вас это никому не нужно.
За время моей практики я попробовал разные методы проектирования разметки. Здесь расскажу как я обычно планирую ивенты и их параметры, пошагово. Может вам будет полезно и вы попробуете такой подход в своей работе.
Погнали ????
Используемые термины
На случай, если читать будут совсем начинающие, приведу небольшой словарик.
Приложение — здесь я буду называть приложением любой продукт, не важно это мобильное приложение, веб-апп или сайт;
Разметка — процесс, при котором разные действия в приложении помечаются некоторыми метками для дальнейшего анализа;
Событие, ивент — то самое действие в приложении. Описание ивентов и есть разметка;
A-ha момент — момент “озарения” у юзера, когда он понимает ценность приложения и из рядового пользователя становится лояльным;
Онбординг — стартовый экран приложения, который обучает пользователя или рассказывает с чем он столкнётся дальше;
Подходы
В проектировании событийной аналитики популярны два подхода:
Целевой — в таком подходе мы фокусируемся на целях и планируем сбор определённых событий, для их достижения. К плюсам этого метода можно отнести низкую ресурсозатратность в плане объёмов данных. Некоторые трекеры (например, Amplitude) очень сильно отъедает бюджеты на больших объёмах. Кроме того, такую сетку событий легче контролировать, т.к. событий не очень много и каждое из них обдумано. Главный минус — такая разметка очень больно реагирует на нестандартные запросы, когда хочется изучить что-то, заранее не заложенное. Придётся размечать это что-то отдельно и ждать пока данные соберутся.
Экстенсивный (его ещё называют проактивным) — в этом подходе мы стараемся разметить как можно больше всего, не следуя строгому плану. Несмотря на кажущуюся простоту подхода, иногда сложно начать, особенно когда приложение большое с сотнями элементов. Сбор вообще всего расширяет поток данных и требует большего объёма хранилища, а большая часть событий, скорее всего, никогда не понадобится. Но главный плюс здесь противоположен целевому подходу — всегда есть доступ к данным по любому запросу.
Я предпочитаю комбинировать эти два подхода, проектируя основу по целям, а менее значимые вещи раскидывая проактивно. В статье расскажу как я это делаю.
Анализ приложения
Первый шаг в задаче на разметку — это анализ приложения с точки зрения его структуры и юнит-экономики.
В идеале иметь развёртку по экранам, её можно запросить у дизайнеров. Если её нет, то можно поковыряться и набросать самостоятельно. Это наш первый компонент в будущем проекте.
Второй компонент — карта метрик и какие-то базовые опорные точки. Нам важно понимать какие метрики мы можем посчитать в событийной аналитике, например базовые — DAU (за что мы цепляемся при включении юзера в DAU: кто-то считает любое действие платного юзера, у кого-то это любой визит даже без ивентов, а где-то вообще включены в расчёты получения пушей), или важные конверсии.
Под опорными точками я имею ввиду события, которые как-то классифицируют юзеров. Например, что у нас является aha-моментом, по каким признакам мы отделяем активного юзера от рядового и т.д. Не всегда эти точки можно определить до анализа, но если что-то явно вырисовывается логически — стоит включить в список.
Планирование основной воронки
Лучше всего начать с основной воронки. Возьмём для примера всем понятный маркетплейс. Его единственная цель — продавать товары юзерам. Значит ключевыми шагами во флоу юзера здесь будут:
Регистрация;
Добавление товара в корзину;
Покупка.
К менее важным, но дополняющим можно добавить ещё просмотр каталога и просмотр карточки товара. Эти события уже можно выписать отдельным списком, пока черновиком.
Ключевых воронок может быть больше одной, в зависимости от продукта. Выписываем их все отдельно.
Посмотрите на своё приложение глобально. Скорее всего, его можно разделить на несколько составных частей, типа “микросервисов”. В том же маркетплейсе это могут быть:
Магазин — сюда можно включить каталог, товары, отзывы и т.д.;
Система заказа — эта вся часть, покрывающая корзину, оплату и доставку;
Личный кабинет — настройки, профиль, персональные скидки и т.д.;
Поиск — обычно поиск это довольно глобальная история, который можно рассматривать как отдельный мини-продукт;
Поддержка — тикеты, чаты, оценка саппорта;
Онбординг — маленький, но гордый кусочек продукта.
Обычно такие глобальные вещи легко придумать. Сильно детализировать не стоит, это чисто схематическое разделение. Оно нам нужно, чтобы было проще концентрироваться на отдельных группах событий.
Теперь, когда у нас есть составные части, можно подумать над их целями, если они есть. Например, задача поиска — показать тот товар, который нужен юзеру, онбординга — не потерять по пути всех юзеров упростить жизнь юзеров в дальнейшем, а вот у кабинета ярко выраженной задачи нет.
Для каждой цели нужно придумать критерии их достижения. Например, мы считаем, что товар в поиске правильный, если юзер добавил его в корзину. В таком случае, кроме события корзины, которое у нас уже выписано в основной воронке, нам стоит добавить событие использования поиска. Всего одно событие на весь поиск? — спросит кто-нибудь. Да, и оно будет нести в себе тонну информации благодаря параметрам. Но об этом чуть позже.
Таким образом, пробежав по каждому “микросервису”, можно нарыть ещё какой-то пул событий. Включаем их все в нашу таблицу.
Параметры юзера
Из чего вообще состоит качественная строка ивента?
Название события, время его совершения, какая-то ценность и т.д. Но кроме этого — кем событие совершено, откуда этот юзер, это новичок или старый юзер, платящий или нет, активный или редкий гость и т.д. Вот эти характеристики называются параметрами юзера. Наверное, любой, уважающий себя трекер, схватывает базовые вещи по дефолту. К базовым обычно относятся: платформа, девайс, страна, город, провайдер, ОС, язык и т.д.
Часто полезно прикручивать к юзерам агрегированные данные — сколько в целом юзер принёс денег на покупках, сколько покупок у него на текущий момент, средний чек юзера. Этими данные можно считать отдельно и обогощать ими витрину событий. Очень поможет в разного рода сегментациях.
Главное — не забыть тянуть в витрину событий внутренний ID юзера, если он есть. Мы здесь не маркетингом занимаемся, который меряет потоки “голов”, у нас всё-таки user-based аналитика. Трекер из коробки обычно не вкурсе ваших внутренних наименований.
Параметры события
Вот мы и подошли к главному. Трекер передаёт не просто название события, а ещё и ряд сопутствующих ему параметров. Технически, не все параметры передаёт трекер, что-то цепляется с бэка, но нам не важно откуда, важно что именно берётся.
Разные трекеры позволяют обрабатывать параметры по разному, например GA со своим подходом через event-action-label требует одного подхода в планировании, а Segment позволяет создавать неограниченное количество пар ключ-значение. Некоторые трекеры сваливают все параметры в один json, что, в целом, тоже удобно.
Итак, что нам с этим всем делать. Вернёмся к нашей таблице.
Возьмём первый ивент регистрации. Какую инфу даёт нам этот ивент сам по себе? Количество рег. Зная количество юзеров на старте, можно вытащить конверсию в регу.
Посмотрим внимательнее на процесс реги в приложении. Есть ли у нас разные методы регистрации? Альтернативные методы через google или apple id? Возможны ли ошибки при нажатии кнопки OK? А может это вообще не регистрация, а повторная авторизация? — Всё это — заготовки для создания параметров события.
Теперь, посмотрев на чуть более детальный ивент регистрации, мы можем прийти к двум выводам:
Чтобы задетектить ошибку, мы должны отправлять событие в момент клика по кнопке OK, а не тянуть его после успешного открытия следующего экрана;
Имя события “Регистрация” не достаточно отражает его смысл, надо переименовать, например в логин.
И обратите внимание на открывшиеся новые возможности — теперь кроме конверсии в регу мы можем оценить частоту ошибок, построить топ методов логина, отделить новые реги от повторных авторизаций, исследовать ошибки в разрезе методов логина.
Вернёмся к событию поиска. Какие параметры можно передать с ним? Какие фильтры были установлены, в какой категории вёлся поиск, время поиска, поисковый запрос… Можно передать любую настройку. А если дотянуть базовые параметры событий и юзеров то открывается практически безграничный простор для исследований. И это всё всего на одном событии.
Планирование событий с конца флоу
Небольшой лайфхак по минимализации количества событий.
Допустим, у вас есть встроенный опросник. В приложении появляется кнопочка “Пройти опрос”, при клике открывается страница с вопросом и выбором варианта. После выбора варианта кнопка далее, ведущая к следующему вопросу. Допустим их 5. В конце опроса кнопка “Отправить”.
Как разметить весь опросник? Можно писать отдельными событиями нажатие кнопки старта, кнопки далее и финальную кнопку завершения. Итого 3-6 ивентов.
В таких ситуациях я мыслю с конца — триггеры события опроса здесь — кнопка отправки результатов, если опрос пройден, или закрытие опроса, если юзер не дошёл до конца.
В параметры можно передать:
Статус — опрос завершён полностью или скипнут;
Порядковый номер вопроса — 1, 2, 3, 4 или 5. Это полезно, если команда начнёт экспериментировать с перестановкой вопросов;
Индикатор вопроса — чтобы мы понимали о чем речь, например вопрос “Ваш возраст” = age и т.д.;
Ответ — какой вариант выбрал юзер или что написал;
В итоге мы можем как построить воронку проходимости всего опросника, так и найти на каких вопросах чаще всего откалываются юзеры, чтобы принять решение о том, можем ли мы добавить вопросов, или его лучше укоротить, а так же отдельно проанализировать каждый вопрос или построить кластеры юзеров, в зависимости от их ответов. И опять это всего по одному событию.
Проверка разметки
Когда базовая разметка готова, самое время провести её стресс-тест. Попробуйте закидать её вопросами бизнеса, поищите слабые места, может ли такая структура отвечать на большинство вопросов, или нужно что-то добавить?
Полезно привлечь на этом этапе продактов, они замечательно креативят вопросы.
Времянки
Базовая разметка — это кор, на нём держится вся событийная аналитика.
Тем временем продукт развивается, внедряются новые фичи. Обычно их уже нельзя выделить в новые “микросервисы”, а поисследовать хочется. В таких ситуациях я стараюсь накидать всё, что можно, собрать каждый клик в этой фиче. Эти события можно сразу пометить временными, т.к. скорее всего они понадобятся только на релизе фичи. И вот здесь как раз будет полезно покрутить данные со всех сторон. В процессе исследования станет понятно что более важно, а что менее, что переносим в кор, а что удаляем в целях экономии ресурсов.
Не бойтесь удалять неиспользуемые события. Порядок в разметке — порядок в голове.
Заключение
Между подходами “Собираем всё, до чего можем дотянуться” и “Собираем только то, что нужно” полно холиваров в интернетах, каждый выбирает сам.
Мне нравится этот комбинированный метод потому, что он идейно опирается на целевой подход, стараясь объяснить “а зачем нам это”, но работает как сужение проактивного метода, когда мы стараемся зацепить как можно больше информации используя свойства, при этом минимизируя количество ивентов.
В конце хочу пригласить в мой тг-канал. Там я пишу про продуктовую аналитику для тех, кто понятия не имеет что делать на работе. Присоединяйтесь, если это про вас.
Материалы
Карл Андерсон — Аналитическая культура
Evren Eryurek & — Data Governance: The Definitive Guide
Личные эксперименты в разных компаниях ????