Привет, я Дина Симкина, директор по аналитике Авито. Я отвечаю за то, чтобы аналитика помогала бизнесу принимать правильные решения. В статье я расскажу, кого мы в компании называем аналитиками данных и чего от них ждём в зависимости от профессионального уровня.

В разные эпохи развития нашего проекта в качестве основного хранилища которое было как источник данных для аналитики у нас были хранилища MySQL, ElasitcSearch, Exasol и ClickHouse. Последний нам очень нравится и вообще вызывает дикий восторг как инструмент для работы с большими массивами данных, но если посчитать итоговую стоимость владения с учётом внедрения кластера, обучения и поддержки — лучше подумайте два раза, прежде чем тащить его в ваше стек. На наших объёмах данных вложенные усилия окупаются, но если бы мы были чуть меньше, то, наверное, экономика не сошлась бы.

Главная проблема ClickHouse — это практическое отсутствие удобных и стабильно работающих инструментов для эксплуатации и большое кол-во решение рядом в погоне добиться того же пользовательского опыта как при работе с классическим RDBMS (MySQL или PostgreSQL). Вам придется приложить не мало усилий чтобы понять как эффективно применить clickhouse для ваших задач анализировать придется много: начиная от вопросов развертывания до выбора оптимальных моделей данных под профиль вашей нагрузки, в общем доступе не так много рекомендаций по выбору конфигураций под разные типы задач.

С другой стороны, его киллер-фича — это возможность работать с огромными массивами данных невероятно быстро для решений в этой области, то что раньше нам приходилось делать в Spark или через другие реализации map reduce, теперь мы можем делать внутри clickhouse. И бесплатно, потому что такими же плюсами обладают многие MPP решения вроде Vertica или Exasol. Но ClickHouse открытый, и за это мы платим налог на использование не прогнозируемым объемом поддержки или развития системы. Не всем это подходит: например, есть опыт компаний, которые сначала было влезли в это дело, потом поняли, что это не то — и взяли платные продукты с платной поддержкой с экспертизой в решении архитектурных задач именно их продуктами. В платных продуктах есть готовые инструменты, которые понятно, как применять.

Привет!

У нас есть огромные ночные отчёты по продуктовым метрикам, которые с утра попадают их владельцам. Пару лет назад они собирались обычным Cron'ом, но это оказалось очень нестабильной историей. Cron требует учёта определенных нюансов и дисциплины: если отчёт не собрался, то нужно перезапустить скрипт. А не собраться он может по многим причинам: одна из MySQL-баз не ответила, или не ответил опрашиваемый сервис, или сервер, на котором работает Cron, ночью перезагружался или вышел из строя. В большинстве своём такие отчеты создавались аналитиками, которые обычно всего этого не учитывали. Потому что они аналитики и это не их задача. Поэтому мы начали искать варианты, которые упростят жизнь всем.

И нашли.

В финальном решении используется планировщик Airflow с его возможностью взаимодействия с кластером Kubernetes. Система получилась гибкая и надежная и упрощает жизнь конечным потребителям. Для разработки таких систем есть мы, техническая команда из четырёх человек, называемая Data Team, а конечные потребители – аналитики, продакт-менеджеры и техлиды.

В интернете кто–то неправ

Случайно выяснил, что существует непонимание того, что такое АБ–тест и как его проводить. Поэтому небольшая статья с базовыми принципами и примерами как делать не надо может быть полезна. Советы рассчитаны на читателя только начинающего знакомство с АБ–тестами и проект с небольшой аудиторией. Если у вас большая аудитория, то вы и так знаете как проводить тесты.

Мой опыт проведения АБ–тестов связан с мобильными приложениями, поэтому какая–то специфика может прорваться несмотря на намерения писать только о базовых вещах.

Определение

АБ–тест — это способ понять стал ли ваш продукт лучше при изменении его части. Скажем, у вас есть гипотеза, что какое–то изменение увеличит ключевую метрику продукта больше чем на 10%. Вы берёте новых пользователей и одной половине даёте контрольный вариант продукта, а другой — с реализованной гипотезой. Дожидаетесь пока разница между значениями метрики станет статистически достоверна, то есть не изменится при продолжении теста с вероятностью 90–95%. Как только результаты достоверны — оставляем победителя и запускаем следующий тест.

О производительности react

React не зря считается очень производительным фреймворком. Он позволяет создавать быстрые динамические страницы с большим количеством элементов.

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

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

Практика общения с аналитиками показала, что лаконичная консоль или лист программы в RStudio IDE как удобный инструмент начинает восприниматься людьми, воспитанными в подходе WYSIWYG, далеко не с первого дня. Продукты PowerBI\Tableau\Qlik, активно использующие этот подход, хорошо известны в российском информационном пространстве и зачастую аналитики пытаются соотнести R+Shiny с этими продуктами.

Привет, Хабр! Меня зовут Слава Волков, и я фронтенд-разработчик в Badoo. Сегодня я хотел бы немного рассказать про сбор статистики с фронтенда.

Мы знаем, что аналитика позволяет оценить эффективность работы любого веб-сайта, улучшить его работу, а значит, повысить уровень продаж и усовершенствовать взаимодействие пользователей с сайтом. Проще говоря, аналитика – это способ контроля над процессами, происходящими на веб-сайте. В большинстве случаев для обычных сайтов достаточно установить Google Analytics или «Яндекс.Метрику» – их возможностей вполне достаточно.

Но как быть, когда стандартных средств мониторинга недостаточно? Или когда собираемая статистика должна быть интегрирована в вашу собственную систему аналитики для отображения полноценной картины происходящего между разными компонентами? В таком случае, скорее всего, вам придется разработать свою систему. А вот как лучше отправлять статистику с ваших веб-сайтов, какие проблемы могут при этом возникнуть и как их избежать, я расскажу в этой статье. Заинтересовались? Добро пожаловать под кат.

2 марта я выступал с докладом на Data Science Meetup, который проходил в нашем офисе. Я рассказал об опыте создания алгоритма по схлопыванию похожих вакансий в поисковой выдаче. По ссылке вы можете ознакомиться с отчетом о прошедшей встрече, там же будут доступны записи выступлений и ссылки на презентации. Для тех же, кто предпочитает воспринимать информацию в текстовом виде, я написал эту статью.

Мы столкнулись с проблемой, когда в поиске по вакансиям выдача заполнялась одинаковыми вакансиями от одного работодателя. Например, по запросу «водитель» посетитель мог получить 30—40 вариантов одной и той же вакансии на одну и ту же позицию.