метрики с фронтенда

[viribus-issue-bot]

1. Во всем фронтенде Твой ФФ (включая рейтинг) надо прокинуть счетчик Яндекс.Метрики (инструкция). Мы пока не понимаем, что он сможет логировать сам и как это будет биться с нашими данными, но это будет хорошим альтернативным мерилом
2. В рейтинге надо фиксировать следующий действия:
   • Использование поиска как разовое действие
   • Использование каждого отдельного вида фильтров и сортировок
   • Открытие каждого отдельного препода
   • Оставление отзыва
   • Время пребывания отдельного юзера на каждой подстранице (это уже менее обязательно, но тоже здорово)

Issue open by Михаил Парфенов via telegram message.

[hevben]

1. Месячная/недельная/дневная конверсия из разных экранов (главная, экран препода, экран оставления коммента) в оставление коммента. Обоснование: показывает вовлеченность/активность пользователей. Интересно посмотреть, как метрика меняется сезонно. По сути, одна из целевых. Низкая конверсия из предпоследнего этапа в последний может говорить о проблемах.
2. Sticky factor (среднемесячный, может быть скользящий). Обоснование: тоже показывает вовлеченность. Но я лично с ней почти не работал, трудно делать выводы.
3. Карта кликабельности кнопок на разных экранах. MAU, общее число нажатий, конверсии. Интересно посмотреть, куда люди вообще тыкают и чем пользуются. Вещь очень наглядная. Как пример: когда кнопки дублируются (например, кнопка "назад"), одна из них может оказаться более востребованной
4. Для сервисов, которые доступны не только через сайт (написание заявлений, я хз, что доступно не только через сайт, и есть ли такое): MAU сервиса, MAU сервиса через интерфейс сайта. Доля второго относительно первого. Показывает, на какую долю пользователей можно повлиять именно через сайт.
5. Для каждого препода: количество появлений в поиске (после поиска), количество кликов, доля второго относительно первого. На основании этой метрики можно вообще ранжировать преподов в результатах поиска
6. На некоторые из метрик (как и на весь дашборд) можно навесить фильтр: анонимные / неанонимные / все пользователи.

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

Что для этого нужно:

1. Нажатия на все возможные кнопки (с указанием того, на каком экране это произошло). Если факт нажатия на все кнопки можно определить косвенно, то не надо. Но похоже, что нельзя.
2. Логировать появление преподов в списке после поиска (но это скорее к беку)

[Zimovchik]

Хочется фиксировать после поиска сколько страниц пролистал пользователь, и на какого препода после поиска первым кликнул(эффективность сортировок и рейтингов)

[BatuevIO]

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

[BatuevIO]

Так, после того, как мы решим вопрос о регистрации юзера, надо понять, какие данные вам нужны. Пока что я написал функции отправки данных через ручку /marketing/v1/action, вопрос в том, что отправлять в additional data. Мой вариант такой, подтвердите или поправьте, пожалуйста:

1. Использование поиска как разовое действие, событие "used search":

• Строка поиска ("Иванов")

2. Использование каждого отдельного вида фильтров и сортировок, событие "changed filter or order":

• Название фильтра ("Математический анализ") или сортировки ("mark_general")
• Возрастание/убывание (true/false для сортировки, null для фильтра)

3. Открытие каждого отдельного препода, событие "open lecturer page"

• Id препода (123)
• Страница поиска (123)
• Номер в поиске (123)

4. Оставление отзыва, событие "sent review"

• Id препода (123)

5. Время пребывания отдельного юзера на каждой подстранице, отправляется при покидании страницы, событие "time spent on page (ms)"

• Ссылка на страницу ("/lecturer?lecturer_id=5636" или "lecturer"?)
• Время на странице (12345 ms)

6. Нажатие на кнопку, событие "clicked button"

• Название кнопки ("return", уникальное для каждой, кроме списков)
• Экран, где кнопка ("main_page")

[parfenovma]

1. В additional data предлагаю класть жсон с двумя полями:
   { "event": название события, например rating.search.input или что-то в этом духе "data": мета информация, соотв. событию, например "Иванов", id лектора, информация про сортировку }
   так же для остальных кликов (rating.sort. ... rating.lecturer. ... итд. Удобно будет селектить все события если там будет additional_info->event ilike '%rating%'
2. время на странице вычислять не надо, это можно будет вычислить по кликам и не грузить фронт

[BatuevIO]

"event": название события, например rating.search.input

Названия норм!

Там вообще уже есть поле "action", я думал в него писать. Или удобнее будет все писать в additional data?

Фронт от одного вычисления на страничке не помрет, но как хотите)

[parfenovma]

а давай в action писать что это именно клик, а не переход

Там вообще уже есть поле "action", я думал в него писать. Или удобнее будет все писать в additional data?

[BatuevIO]

а давай в action писать что это именно клик, а не переход

Там вообще уже есть поле "action", я думал в него писать. Или удобнее будет все писать в additional data?

Я думал в action писать как раз rating.search.input, rating.lecturer и т.д.