Как разметить приложение с нуля: разбираем на примере приложения «Пятёрочка»

Команда X5 Tech, которая отвечает за аналитику приложения в «Пятёрочке», поделилась опытом, как выбрать трекер, фреймворк и архитектуру разметки, написать правила и словари.

Как выбрать трекер для работы

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

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

Трекер AppMetrica соответствовал всем требованиям команды.

¹Native + web-view

Что такое разметка

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

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

С чего начать

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

Алфавит разметки

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

Фреймворк разметки

Распространённый: Object_Action

Представляет собой разметку по модели «Объект_Действие» (button_click) или «объектДействие» (buttonClick).

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

Объект (Object) — каждая сущность в приложении или на сайте. Каждый объект соответствует определённым параметрам.

Так как объектов может быть много, их нужно группировать по определённому типу — вводить классы. Например:

• Объект — кнопка
• Действие — нажатие
• Всё вместе — «кнопка_нажатие»

На латинице:

• Объект — button
• Действие — click
• Всё вместе — button_click

В разметке действие будет самим событием, а объект — его первым параметром.

В результате разметка превратится из «Объект_Действие» в «Действие_Объект».

При этом некоторые специалисты привыкли записывать в событие и действие, и объект. Например, так:

Такой вариант тоже возможен, но не подходит для трекеров с ограничением количества уникальных названий для событий. Например, clickButton, clickBanner займут два уникальных места, а просто click с параметром object (button или banner) — одно.

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

Расширенный фреймворк

Предыдущий фреймворк можно обогатить двумя важными обязательными параметрами — Субъект и Пространство.

«Субъект_Пространство_Действие_Объект» | Subject_Space_Action_Object

Субъект (или актор) — источник действия. Например, пользователь (user) или система (system). Допустим, пользователь кликает, а система возвращает ошибку.

Пример: пользователь кликнул где-то на кнопку — user_пространство_click_button.

Пространство — это команда, отвечающая за конкретный размеченный участок приложения. Актуально для приложений типа «Пятёрочки», где разные части приложения поддерживаются отдельными командами разработки. Этот параметр помогает понимать, чьи события анализируются и к кому обратиться, если что-то пойдёт не так.

Пример: пользователь нажал кнопку в рамках той части приложения, за которую отвечает команда Delivery — user_delivery_click_button.

Аналогично для действий системы: приложение показывает экран после его открытия вами — system_delivery_view_screen.

В таблице запись будет следующей:

Как и в случае с объектом, субъект и пространство будут обязательными параметрами события.

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

1. Что произошло?
2. На что было воздействие?
3. Где (в ведомстве какой команды) произошло?
4. Кто это сделал?

Обязательным для внедрения должен быть параметр Screen — конкретное место в приложении, где совершаются события. Этот параметр также позволит разграничить события, например, нажатие кнопок с одним и тем же названием, таким как «Принять», когда они находятся в разных местах приложения.

Опционально можно ввести параметр Section — раздел, который содержит в себе несколько экранов — Screens.

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

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

Для быстрой фильтрации, но, главное, для более удобной коммуникации с разработкой ввели обязательный параметр event_id, в который записывается уникальный id события через согласованный формат (camelCase), собираемый на базе всех прочих параметров: logTapUser.

Правила разметки

Нужны для единообразия и дополнительного контроля передаваемых данных. Приведём пример важных правил, которые используются в приложении «Пятёрочка»:

1. Не передавать персональные данные в события и его параметры.
2. Использовать только нижний регистр во всех наименованиях. Слова разделяются нижним подчёркиванием (snake_case).
3. Использовать латиницу; названия событий, параметров и значений писать на английском языке.
4. Использовать для названий событий и параметров согласованные внутри команды аналитиков словари.
5. Вводить новые названия только после обсуждения с командой.

Словари разметки

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

Имена событий

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

Имена параметров

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

По описанному выше фреймворку заданы шесть обязательных параметра: object, subject, space, section_name, screen_name, event_id. Остановимся подробнее на параметре object.

Параметр object может принимать следующие значения:

• button
• screen
• banner
• widget
• warning

Отличить один объект от другого, например кнопки, позволяют их названия. Его можно написать через нижнее подчёркивание, но это нарушает саму логику использования параметров, потому что расширяет их содержание. Логичнее вынести это содержание в другой параметр, например name. Варианта 3:

1. object_name
2. класс_name — button_name, screen_name
3. name

Третий вариант (name) допустим, но в нём нет указания, к чему он относится, поэтому теряется читаемость события.

Чтобы не упереться в лимиты, используйте первый вариант — object_name. При этом команда X5 Tech сама использует класс_name, жертвуя лимитами для читаемости.

Значения параметров

Параметры могут принимать сколько угодно значений без ограничений. При этом важно понимать, что было объектом действия: button, icon или widget. Для этого необходимо подготовить словарь значений с определениями для объектов и субъектов.

Словарь объектов

Словарь субъектов

Выше были заданы два сегмента: user и system. Хотя system можно уточнить до конкретного микросервиса, такое дробление на названия сложно поддерживать. Поэтому было решено остановиться на этом варианте.

Промежуточные итоги

Фреймворк разметки «Действие_Объект_Субъект_ Пространство_Секция_Экран» позволяет сформировать схему событий вида:

Как происходит разметка

Прежде чем начать разметку, важно подготовиться:

1. Узнать Ф. И. О. тех, кто отвечает за разные части приложения или сайта. Например, менеджера продукта или Product Owner. Внести их в отдельный раздел внутренней документации. Таблица может выглядеть так:

2. Распределить экраны приложения внутри команды аналитиков:

После этого можно переходить к разметке. Этот этап состоит из нескольких шагов

1. Разметка.
2. Ревью.
3. Внесение правок.
4. Составление ТЗ на внедрение.
5. Приём финальной работы.

Как работают аналитики

Для разметки аналитики «Пятёрочки» используют шаблон в Google Таблицах.

Он состоит из трёх вкладок:

1. Экраны/Виджеты — это описание всех экранов и виджетов.
2. Экран — это экран приложения (или страница сайта), который подвергается разметке.
3. Экран ТочкиВхода — это названия баннеров или виджетов в приложении, через которые можно попасть в этот экран.

Основная вкладка — Экран. Вот как она устроена для приложения «Пятёрочки».

В хедере есть два поля с URL экрана: Figma и Confluence. В Figma — актуальные макеты приложения, Confluence содержит внедрённую разметку на базе этой таблицы.

Поля «Дата добавления…», «Статус в Android/iOS», «Приоритет внедрения», «Субъект (Subject)», «Пространство (Space)» понятны. Поле «Индекс» позволяет ссылаться не на какие-то события в спредшите на строки, а на конкретный индекс.

Следующие три поля:

• «Событие» — действие
• «Описание события» — что сделалось и с каким объектом
• «Сценарий» — что происходит с пользователем и системой

К обязательным параметрам Object (string), Subject (string), Space (string) добавляются ещё два:

• Screen_name
• Section_name

Если читать таблицу выше, то получится, что в секции «Настройки» (settings) есть ряд экранов (screens). Один из них — это уведомления (notifications). За секцию и этот экран отвечает команда Example.

Вот как выглядит разметка главного экрана приложения «Пятёрочка»:

Первое событие, которое можно описать — это показ экрана:

Событие:

• Что произошло? — View (показ).

Параметры этого события:

• Что показалось? — Screen (экран).
• Какая команда отвечает? — Growth (название команды).
• Кто сделал это действие? — Экран показывает system.
• В какой части приложения? — В части главной страницы (main).
• Какой это был экран? — Главная страница (main).

Дополнительные параметры (необязательные, для примера):

• referrer — предыдущий экран;
• load_status — статус загрузки — успешно или ошибка (с указанием какой);
• load_time — время загрузки экрана.

Второе событие, которое можно описать, — это tap (нажатие) на виджет со штрихкодом. Это виджет карты лояльности. За него отвечает другая команда — команда Loyalty.

Событие:

• Что произошло? — tap (нажатие).

Параметры этого события:

• На что было нажатие? — На widget.
• Какая команда отвечает? — Loyalty (название команды).
• Кто сделал это действие? — Нажатие делает user.
• В какой части приложения? — В части главной страницы (main).
• Какой это был экран? — Главная страница (main).

Дополнительные параметры (необязательные):

• widget_name — название виджета

Что дальше

Разметка всех элементов на главной странице позволяет получить таблицу с событиями (как в шаблоне), которая отправляется на согласование в команду продукта. После всех согласований из таблицы формируется ТЗ для разработки на внедрение. В случае «Пятёрочки» оно выглядит так:

Чтобы сэкономить время на разметке, команда Х5 Tech использует скрипт. В рамках ТЗ на базе event_name и параметров собирается имя события в CamelCase — это уникальный индекс для разработчиков, который помогает ориентироваться в событиях, отправляемых приложением или сайтом.

А теперь коротко: из каких шагов состоит разметка

1. Выбрать алфавит.
2. Выбрать фреймворк.
3. Написать правила.
4. Составить словарь.
5. Определить имена параметров.
6. Добавить значения параметров.
7. Подготовить словари объектов и субъектов.
8. Список коллег и команд, которые отвечают за разные части приложения или сайта.
9. Распределить экраны приложения внутри команды аналитиков.
10. Подготовить разметку.
11. Провести ревью.
12. Внести правки.
13. Составить ТЗ на внедрение.
14. Принять финальную работу.