Repository navigation
метрики с фронтенда #63
Description
- Во всем фронтенде Твой ФФ (включая рейтинг) надо прокинуть счетчик Яндекс.Метрики (инструкция). Мы пока не понимаем, что он сможет логировать сам и как это будет биться с нашими данными, но это будет хорошим альтернативным мерилом
- В рейтинге надо фиксировать следующий действия:
- Использование поиска как разовое действие
- Использование каждого отдельного вида фильтров и сортировок
- Открытие каждого отдельного препода
- Оставление отзыва
- Время пребывания отдельного юзера на каждой подстранице (это уже менее обязательно, но тоже здорово)
Activity
- Месячная/недельная/дневная конверсия из разных экранов (главная, экран препода, экран оставления коммента) в оставление коммента. Обоснование: показывает вовлеченность/активность пользователей. Интересно посмотреть, как метрика меняется сезонно. По сути, одна из целевых. Низкая конверсия из предпоследнего этапа в последний может говорить о проблемах.
- Sticky factor (среднемесячный, может быть скользящий). Обоснование: тоже показывает вовлеченность. Но я лично с ней почти не работал, трудно делать выводы.
- Карта кликабельности кнопок на разных экранах. MAU, общее число нажатий, конверсии. Интересно посмотреть, куда люди вообще тыкают и чем пользуются. Вещь очень наглядная. Как пример: когда кнопки дублируются (например, кнопка "назад"), одна из них может оказаться более востребованной
- Для сервисов, которые доступны не только через сайт (написание заявлений, я хз, что доступно не только через сайт, и есть ли такое): MAU сервиса, MAU сервиса через интерфейс сайта. Доля второго относительно первого. Показывает, на какую долю пользователей можно повлиять именно через сайт.
- Для каждого препода: количество появлений в поиске (после поиска), количество кликов, доля второго относительно первого. На основании этой метрики можно вообще ранжировать преподов в результатах поиска
- На некоторые из метрик (как и на весь дашборд) можно навесить фильтр: анонимные / неанонимные / все пользователи.
Считаю всё, перечисленное выше, достаточно глубоким и избыточным. Если и делать, то скорее для прикола.
Что для этого нужно:
- Нажатия на все возможные кнопки (с указанием того, на каком экране это произошло). Если факт нажатия на все кнопки можно определить косвенно, то не надо. Но похоже, что нельзя.
- Логировать появление преподов в списке после поиска (но это скорее к беку)
Reacted by Mark Shidran and Ivan ZakharovХочется фиксировать после поиска сколько страниц пролистал пользователь, и на какого препода после поиска первым кликнул(эффективность сортировок и рейтингов)
Использование единичного поиска не очень понятно. Сейчас поиск совершается после ввода каждого нового символа. Правильно ли я понимаю, что мы хотим записать все события типа: "И", "Ив", "Ива", "Иван", "Ивано", "Иванов"? Триггерят ли это событие изменение фильтров и сортировок? Или это исключительно введение в поисковую строку запроса?
Так, после того, как мы решим вопрос о регистрации юзера, надо понять, какие данные вам нужны. Пока что я написал функции отправки данных через ручку /marketing/v1/action, вопрос в том, что отправлять в additional data. Мой вариант такой, подтвердите или поправьте, пожалуйста:
- Использование поиска как разовое действие, событие "used search":
- Строка поиска ("Иванов")
- Использование каждого отдельного вида фильтров и сортировок, событие "changed filter or order":
- Название фильтра ("Математический анализ") или сортировки ("mark_general")
- Возрастание/убывание (true/false для сортировки, null для фильтра)
- Открытие каждого отдельного препода, событие "open lecturer page"
- Id препода (123)
- Страница поиска (123)
- Номер в поиске (123)
- Оставление отзыва, событие "sent review"
- Id препода (123)
- Время пребывания отдельного юзера на каждой подстранице, отправляется при покидании страницы, событие "time spent on page (ms)"
- Ссылка на страницу ("/lecturer?lecturer_id=5636" или "lecturer"?)
- Время на странице (12345 ms)
- Нажатие на кнопку, событие "clicked button"
- Название кнопки ("return", уникальное для каждой, кроме списков)
- Экран, где кнопка ("main_page")
- В additional data предлагаю класть жсон с двумя полями:
{ "event": название события, например rating.search.input или что-то в этом духе "data": мета информация, соотв. событию, например "Иванов", id лектора, информация про сортировку }
так же для остальных кликов (rating.sort. ... rating.lecturer. ... итд. Удобно будет селектить все события если там будет additional_info->event ilike '%rating%' - время на странице вычислять не надо, это можно будет вычислить по кликам и не грузить фронт
- В additional data предлагаю класть жсон с двумя полями:
"event": название события, например rating.search.input
Названия норм!
Там вообще уже есть поле "action", я думал в него писать. Или удобнее будет все писать в additional data?
Фронт от одного вычисления на страничке не помрет, но как хотите)
а давай в action писать что это именно клик, а не переход
Там вообще уже есть поле "action", я думал в него писать. Или удобнее будет все писать в additional data?
а давай в action писать что это именно клик, а не переход
Там вообще уже есть поле "action", я думал в него писать. Или удобнее будет все писать в additional data?
Я думал в action писать как раз rating.search.input, rating.lecturer и т.д.
Metadata
Metadata
Assignees
Type
Projects
- Status