Pull to refresh

Comments 14

очень интересно почитать про аналитику на python в junyper

Рассматривался ли вариант делать все A/B-тесты средствами Google Analytics или подобных решений?
Если (скорее всего) не хватило функциональности, то в какие именно реальные ограничения вы упёрлись?

привет, отличный вопрос!
коллеги, которые непосредственно строят А/В инфраструктуру поделились вот такой инфой
такой вариант рассматривался. Насколько я понимаю, там можно измерять абсолютные метрики, вроде абс. числа просмотров, абс. числа регистраций. Проблема возникает с конверсиями. Например, если мы измеряем конверсию поиска в отклик то нам нужно приджоинить отклик пользователя к поиску. Я не уверен, можно ли такое сделать в гугл-аналитикс — просто не знаю. Может быть и можно.
Но мы в наших метриках джоиним с учетом того, что соискатель видел эту вакансию в поисковой выдаче.
Ну то есть, помимо факта поиска и факта отклика на какую-то вакансию, мы требуем, чтобы эта вакансия была в поисковой выдаче. Такое, я практически уверен, гугл аналитикс не умеет делать. то есть, используя наши логи, мы в теории можем более «тонко» выполнять джоин.

Плюс есть вопрос безопасности и надежности, что если гугл лежит (или скажем РКН заблочил GA?)
Так же хотелось полного контроля над процессом, чтобы можно было кастомизировать под себя. Мы четко можем сказать как работает та или иная метрика и проследить ее по логам. Плюс по тем же логам мы считаем любые кастомные метрики вручную.
Для расчета метрик в GA надо отправлять лишнюю бизнес-информацию о юзере к примеру, а это же конфиденциально.
Плюс лишний поход вовне, дольше загрузка страницы. У нас признак работает фича или нет долетает вплоть до бэкенда, поэтому на фронт отдаются уже готовые страницы с фичей или без, а пускать GA внутрь периметра безопасного прода нельзя.
почему вы не хотите использовать подсчет на уровне приложения. к примеру, сессии. это с виду более монолитно будет и более точно.

Вы имеете в виду сразу складывать счетчики в сессию юзера?

В случае обычной БД мы извлекаем данные из нее и отправляем клиенту, который делает какой-то анализ и возвращает аналитику результат.
ЧТО?? Я поздравляю IT специалистов компании hh! Пропустить 20 лет развития клиент-серверных технологий для этого надо быть настоящим специалистом. Про хранимый в БД код в виде процедур, да даже просто про SQL запросы передаваемые в БД — не слышали? И про кластеры БД тоже не слышали?
Спасибо за наводку — обязательно изучим.
Спасибо,
Хорошо объясняете в двух словах популярные технологии, что оно умеет и как вы это используете.
Получается очень понятно.

Спасибо за статью. Почему выбран был Hadoop, а не elasticsearch? Да, больше мороки с трансформацией логов, зато аналитика проще.

отчасти причина в наличии экспертизы по hadoop, elasticsearch мы как раз сейчас пробуем тоже, как накопим опыт, сможем сравнить и поделиться

Рассматривали ли вы комбинацию кафка + вертика? Проблемы с синком других баз в вертику решены, а SQL-диалект, похожий на постгрес, помощнее чем у многих решений будет.

добрый день. не рассматривали. дело в том, что технологий много, провести анализ всех (а зачастую это значит их реально поставить и сравнить) довольно трудоемко. причем у всех технологий есть плюсы и минусы, так что в любом случае выбор — это компромисс.
за идею спасибо, возможно посмотрим в ту сторону, если будут проблемы.
А как-то отслеживается ситуация, когда, например, человеку пришла рассылка, он щелкнул по ссылке, увидел, что ему не интересно читать, и тут же закрыл вкладку? Т.е. есть привязка понятий «человек читал страницу» (т.е. хотя бы находился на ней больше, скажем, 10 секунд, и, желательно, скролил контент) или «дочитал почти до конца» (проскролил минимум почти до конца, желательно с учетом скорости скрола — чтобы именно «читал», а не просто нажал End).
нет, мы отслеживаем целевые действия на страницах — к примеру отклик, либо переход на какие-то другие страницы.
Sign up to leave a comment.