Привет! Меня зовут Евгения Новосилецкая, я аналитик в AGIMA AI. В нашей практике мы часто сталкиваемся с одной и той же проблемой: компании собирают огромное количество аналитических событий, но те зачастую плохо задокументированы или не задокументированы вообще. Поэтому понять, что и как работает, особенно новичку, сложно.
Работа с плохо организованными данными заставляет нас осознать важность правильного именования и документирования аналитических событий. По сути, это основа для получения точных и полезных данных, которые в конечном итоге помогают принимать обоснованные бизнес-решения и приносить прибыль.
В этой статье разберем 5 основных принципов, которыми мы руководствуемся при работе с событиями.
1. Единое место документации событий
Создайте единое место документации всех событий (будь то Notion, Confluence, Google-документ или система аналитики с встроенным трекинг-планом) и используйте только его как источник правды.
Часто случается, что аналитические события или их изменения описаны только в задачах на разработку или в документах разных продуктовых команд. Чтобы собрать всё воедино, аналитику требуется время. Знающий и опытный спец держит всё в голове, но, если приходит новый сотрудник, вопросов становится больше, чем ответов. Особенно, если вопросы касаются задач на пересечении деятельности нескольких продуктовых команд.
Единый источник документации позволяет работать с ним всем командам, эффективно вести разработку и вносить изменения. Структура может быть такой, с какой будет удобно вам или какую предоставляет система аналитики.
Обычно мы в таком документе выделяем три-четыре блока:
Data policy — правила и принципы работы с событиями (те же, что и в этой статье). После прочтения этого блока не должно быть вопросов, как создавать и читать события. Наша задача здесь — не оставить никому из команды пространства для воображения и всё стандартизировать.
Events — список событий с подробным описанием каждого из них, чтобы ни при разработке, ни при анализе не возникало разночтений. Обычно тут мы указываем название, описание, список параметров. Можно добавить статус и дату реализации/номер релиза.
Event Properties — справочник параметров событий с подробным описанием каждого параметра. Обычно тут указываем название, описание, обязательность, тип, возможные значения. Подробнее в пункте 5.
User Properties — справочник параметров пользователя. Принцип тот же, что и у параметров событий.
2. Единая нотация
Выберите одно соглашение о наименовании (нотацию) и придерживайтесь его.
Одна из самых частых проблем в аналитических данных — проблема с наименованием событий, параметров и их значений. Разные команды (iOS, Android) или разные разработчики могут выбрать нотацию по своему усмотрению, что при анализе данных может стать причиной неправильных результатов.
Пример. Команда для одной платформы реализовала событие через snake_case. В то же время другая команда сделала это через camelCase.
Другой пример. Значение параметра события на протяжении уже нескольких лет собирается как choose_and_play, ChoosePlay, Choose&Play, ChooseAndPlay. В документации не были указаны возможные значения для разработчиков, поэтому каждый реализовал как посчитал нужным. Аналитику при работе с событием приходится прокликивать или включать в запрос все 4 значения вместо одного. Хорошо, что этот момент уже задокументирован, и аналитик не упустит это при работе.
При этом недостаток в данных по платформе еще легко заметить. Но если это касается параметров и их значений и разных разработчиков на одной платформе, то сделать это будет уже очень непросто.
Обсудите с командой, какую нотацию выбрать для событий, параметров и их значений. В дальнейшем это может значительно сократить время как разработки и тестирования, так и анализа.
Ниже приведены наиболее используемые нотации:
all lowercase — page view;
snake_case — page_view;
camelCase — pageView;
Proper Case — Page View;
Sentence case — Page view.
Отдельно для событий, параметров, значений параметров можно выбрать разные нотации.
3. Структура в названии событий
Выработайте структуру названия события и именуйте события согласно ей.
Чтобы событие было легко интерпретировать, нужно понимать, по каким правилам оно написано. Для этого в команде следует договориться о стандартизированной структуре названий, которую будут понимать и соблюдать все участники.
Можно сказать, что идеального решения здесь не существует. Всё зависит от изначальной задачи трекинга: хотите ли вы покрыть событиями весь функционал или отслеживать только основные действия. От этого зависит степень детализации события. Просто выберите подход, который будет работать для вас самым удобным образом.
Обычно название события — это комбинация названия объекта, совершенного над ним действия и, при желании, категории события.
Объектом обычно выступают кнопки, формы, поля или другие объекты сайта или приложения.
Действие — способы, которыми пользователи могут взаимодействовать с объектами: click, view, swipe, create и другие. Определите заранее возможный список действий, чтобы при создании событий не нужно было думать об этом. Подумайте заранее и об используемом времени действия — click или clicked.
Как правило, мы работаем с крупными проектами, в которых аналитические события используются для многих целей, например для тестирования функционала и проведения экспериментов. Поэтому со временем каталог событий может разрастаться. Если вы не планируете ограничиваться только основными 10–15 событиями, то лучше к названию события добавить категорию. Это поможет вам легко идентифицировать и группировать события.
В качестве категории события мы используем название страницы сайта/экрана приложения или название функционального блока/фичи. Этот список тоже можно заранее определить и при развитии системы пополнять.
Порядок в названии тоже не так важен. Главное — его определить и ему следовать. Если вам удобнее указывать в названии события действие первым, то можете называть его так.
Примеры: Product page view, Clicked Add to cart, products_search_product_click, Basket Add discount Click
4. Понятные названия
Название события должно быть четким, понятным и легкочитаемым. Оно должно отражать логику события без необходимости изучения задачи на разработку.
Вдобавок к предыдущему пункту остается только добавить, что событие должно быть легко читать и понимать абсолютно всем, кто работает над сайтом или приложением, а не только знающим людям. Ведь часто это маркетинговые аналитики или новички, которые только погружаются в задачи. Категории, объекты и действия не должны быть общими. Они должны однозначно определять действие пользователя.
Например, не используйте названия типа button clicked , так как это слишком общее название. Как видите, у нас сразу возникает вопрос где была нажата кнопка и что это за кнопка.
Не следует использовать и аббревиатуры или специализированные термины, которые будут непонятны команде.
И в довершение к этому пункту хочется сказать, что ясность тут предпочтительнее краткости. Конечно, не всегда это правило можно соблюсти (ограничение в количестве символов ?), поэтому должен быть баланс между детализацией и абстракцией.
Еще пример. Не используйте названия событий типа message_5_shown — из него непонятно, что такое 5, какое сообщение было показано и где. Вместо него можно было бы использовать более говорящее событие вида product_out_of_stock_shown. Тут мы определили категорию события — страница продукта, объект — сообщение Out of stock, а также действие — сообщение было показано. Если сообщений на странице может быть несколько, можно для них определить одно событие — product_message_shown, а в параметре определить текст сообщения или его код, если потом будет возможность присоединить справочник кодов сообщений.
5. Единый справочник параметров
Определите список параметров всех событий и пользователей, максимально опишите их, укажите возможные значения параметров, их обязательность и тип. Переиспользуйте параметры в событиях.
Параметры — это контекст, в котором совершается событие. Они обогащают действия пользователей информацией и дают более полное представление о том, что пользователи делают на сайте или в приложении. Например, знать количество событий product view нам недостаточно. Мы бы хотели знать, какие именно продукты пользователи смотрят чаще или добавляют в корзину, совершают ли они эти действия залогинившись и имеют ли платную подписку в этот момент.
Поэтому важно определить, какие параметры вы хотите собирать с каждым событием, чтобы этот контекст был ясен. Будет неприятно узнать, что событие собиралось долгое время, а для решения поставленной задачи не хватает данных.
? Если у вас есть категории событий, то, возможно, для этих категорий применимы одни и те же параметры. Например, если это страница заказа, то возможный контекст всех событий этой страницы — ID заказа, его статус и способ доставки.
Название параметра, как и события, должно быть легкочитаемым и понятным. Как уже сказано в пункте про нотацию, проблема с параметрами и их значениями иногда возникает вокруг их наименования. Поэтому убедитесь, что это правило применяется и здесь.
Опишите назначение параметра как можно детальнее, чтобы не было разночтений.
Например, такое описание параметра как «message — сообщение на странице продукта» разными разработчиками может быть принято по-разному: один отправит в параметре текст сообщения, другой код или ID сообщения.
Часто у тестировщиков и аналитиков возникает вопрос, является ли параметр обязательным. В задании на разработку не указали, и непонятно, если в событии нет этого параметра, баг ли это. Чтобы избежать подобных вопросов, в справочнике параметров укажите для каждого параметра обязательность. А по возможности — и тип параметра.
Аналогично предыдущему вопросу, часто возникает вопрос о том, почему в значении параметра логируются разные наборы значений: в одних true/false, в других yes/no, в третьих 1/0. Где-то значение может быть указано на английском языке, где-то — на русском.
Помогите разработчикам и впоследствии аналитикам — заведите, если это применимо, список возможных значений параметра. Если значений много, укажите, из какого справочника их брать, пример или формат значения. Это облегчит труд каждого.
Пример. Наличие описания параметра как «order_status — статус заказа» зачастую не является исчерпывающим. Разными разработчиками оно может быть принято по-разному: один отправит Delivered, другой Доставлен, и оба будут правы. А работать с этим аналитику.
И последнее, но не менее важное: переиспользуйте одни и те же параметры в своих событиях, если они отвечают на одни и те же вопросы. Перед созданием нового параметра обязательно убедитесь, что такого параметра еще нет.
Исключите ситуации, когда в одном событии логируется параметр product_id, а в другом product , но с таким же значением ID продукта.
Заключение
Если соблюдать относительно простые правила наименования и документации событий, многих проблем в аналитике можно избежать еще на этапе ее проектирования. К тому же любой сайт или приложение имеет свойство меняться и расширяться. Это значит, что появится новый функционал, который потребует трекинга.
Преимущества хорошо построенного каталога событий и четко определенных правил работы с ним почувствуют все — от разработчиков до маркетинговых аналитиков. Это единый понятный источник правды для всей команды. С ним смогут работать в том числе и нетехнические специалисты. А для разработки и тестирования это будет детальное техническое задание.
Мы понимаем, что иногда разработчики и тестировщики могут не уделять аналитике событий должного внимания, потому что правильная работа сайта или приложения для них приоритетнее. Поэтому одна из задач аналитиков — облегчить им работу, насколько это возможно.
Еще один существенный плюс — онбординг для новых членов команды. Погружение в задачи будет гораздо легче, если под рукой будет источник, отвечающий на все или почти все вопросы.
Ну и в заключение хочется сказать, что собирать много данных — это, конечно, хорошо, но в первую очередь события и параметры должны быть полезными для анализа.
На этом всё, спасибо за внимание! Если у вас остались вопросы — задавайте в комментариях.