Chief Data Officer

Теперь ещё и в продукт ищем крутых аналитиков данных! Скидывайте клёвые резюме в личку: @stovm

Вакансий пост :) мы растем Senior Product Analyst (Growth) at Simple Simple is a mobile product with over 15 million unique downloads, that offers judgment-free, gentle guidance toward balanced nutrition, a healthy relationship with food, and ultimately, improved health and well-being. Cyprus or remote (EU time zone). Relocation package. Job description. More details in Ksenia Boiarshinova’s post on LinkedIn.

Всем привет! Тут вакансия прилетела от глубокоуважаемого @vgrigorash Кому интересно и отзывается, пишите прямо ему. ESN - компания которая занимается созданием и развитием новых инновационных продуктов в индустрии медиа и развлечений. Наш первый продукт - социальная медиа платформа, на которой пользователь не только смотрит/слушает, но и активно взаимодействует с контентом. Цель продукта – активировать пользователя и превратить его в репитера и создателя контента в видео/аудио-вселенной. Senior Product Analyst / Старший Продуктовый Аналитик Обязанности: - Выстраивание процессов для обеспечения сквозной продуктовой и маркетинговой аналитики; - Проработка и запуск продукта внутренней экосистемы аналитики, с последующим ее развитием; - Анализ инкрементального эффекта от введения / разработки новых продуктов и фичей; - Участие в процессе развития внутренней системы сбора, хранения и анализа данных; - Выполнение ad-hoc аналитики и запросов по необходимости; - Участие в разработке и развитии системы отчетов / метрик для мониторинга жизнедеятельности продуктов; - Анализ поведения пользователей и продуктовых данных, создание значимых и применимых выводов; - Взаимодействие с продуктовой командой, помощь в идентификации внутренних и внешних точек роста продуктов; - Генерация гипотез на основе данных; Основные требования: - Опыт работы в продуктовой аналитике от 3 лет; - Опыт внедрения направления продуктовой аналитики с нуля; - Высшее образование в сфере математики, статистики, экономики или информационных технологий; - Опыт работы продуктовым или маркетинговым аналитиком от года (b2c apps, games); - Уверенное знание методов статистического анализа, умение видеть за числами физический смысл, находить причины и следствия; - Опыт работы с аналитическими системами (GA, Amplitude, GTM, Firebase, etc); - Уверенное знание SQL (PostgreSQL, Clickhouse будет плюсом); - Опыт работы с Python (Pandas, Numpy, Prophet, etc.); - Опыт работы с BI системами (Tableau, PowerBI, etc) будет плюсом; - Исключительная внимательность к деталям;

Нашёлся 🥳

Head-а аналитики, кстати, тоже ищем. Head, найдись 🙂

Всем привет! Ultimate Guitar растёт и мы на проект ищем продуктового аналитика, который возьмет на себя весь стэк аналитических задач команды роста и которому предстоит работать над поиском инсайтов, а точнее много думать о данных связанных с пользователями - какие данные нам необходимы и что мы можем из них извлечь. А также уметь строить модели для автоматизации работы с данными. Что мы ждем от кандидата Не менее 3-х лет опыта в аналитике на проекте с большими данными; Уверенное владение SQL; Уверенное владение Python и необходимыми статистическими пакетами; Опыт применения методов машинного обучения для анализа данных; Отсутствие страха перед data engineering; У нас сложные, но интересные задачи по созданию крутого и по-настоящему полезного продукта для музыкантов из разных стран по всему миру. Кого заинтересовало, не стесняйтесь, пишите мне в директ: @stovmasyan

Уже совсем скоро расскажу про то, как подходить к составлению структур данных. Уверен, эта конференция намного полезней любых курсов и статей, так как доклады идут напрямую от специалистов ведущих компаний индустрии. https://aha.matemarketing.ru/

Добавил свои контакты 🙂

Всем привет! Давно я тут не писал, потому что с головой ушёл в продукт - это безумно интересно, аналитика очень помогает. Но продукт у нас не один - их много и все крутые. Было бы разумно организовать аналитику на уровне выше - а именно такую аналитику, процессы, структуры данных и подходы, которые применимы ко всем продуктам компании, чтобы каждый отдельный продукт не изобретал велосипед. А потому у меня для вас уникальная вакансия - она для супер амбициозных, опытных и заряженных желанием специалистов. Head of Analytics Задача: организовать продуктовую аналитику на уровне множества продуктов. Единую и универсальную, быструю, красивую. Что мы ждём от кандидата: - 3 года опыта в роли ведущего аналитика или Head на крупном и успешном продукте с опытом выстраивания эффективной команды аналитики и процессов вокруг - уверенное владение SQL, Python и статистическими пакетами, умение применять ML в реальных аналитических задачах - умение реализовать A/B тестирование не только на уровне t-test-а, а много глубже - уверенный пользователь ClickHouse - а также хороший пипл менеджемент (найм, увольнение, персональное развитие) Что конкретно предстоит делать, могу рассказать подробней в личке, но там полный спектр - от people management и придумывания структур данных до реализации CUPED тестов и мониторингов аномалий. Ещё мы ищем аналитика в команду рекламы и сильного аналитика в команду продукта Ultimate Guitar. Так что готовы принять сразу троих 🙂 Пишите, если вы такой или знаете таких ;) tg: @stovmasyan facebook: stovmasyan

Привет! Меня порой спрашивают, что почитать по статистике и теории вероятностей. Учился я на Мат-Мехе СПбГу, на чистой математике, на кафедре теории вероятней и математической статистики. Затем учился в аспирантуре по тому же направлению. Образование это очень хорошее, фундаментальное, но часто бывает оторванным от практики, - то есть тебя сразу окунают в глубины глубин абстракций, оставляя один на один с фантазиями о том, как и где применять полученные знания. Такой подход в целом про нашу школу преподавания и он имеет свои плюсы и свои минусы, но 100% не очень подходит для самостоятельного освоения дисциплины, - потому что с первых страниц конспектов или книг бесконечное ощущение, что очень сложно и очень непонятно. На самом деле всё не очень сложно и достаточно понятно, а если преподнести красиво и вкусно, то ещё и очень увлекательно. Так, например, есть совершенно потрясающий курс лекций от Harvard University. Когда я впервые увидел эти лекции, то осознал, что такое очень крутой преподаватель и в тот же момент понял, какая это невероятная по сложности работа - преподнести материал ёмко, красиво, весело, понятно, без ошибок и при этом удерживать внимание аудитории. Конечно, в этом курсе нет претензии на то, чтобы вырастить учёных, - есть цель объяснить слушателям всё от определения вероятности до цетральной предельной теоремы и её следствий, пройдя при этом через случайные величины, их свойства, распределения разные и т.д. В общем, если вы боялись, но всегда хотели попробовать или пробовали, но не получалось, вот точка входа в увлекательный мир теории вероятностей и математической статистики. https://www.youtube.com/watch?v=KbB0FjPg0mw&list=PL2SOU6wwxB0uwwH80KTQ6ht66KWxbzTIo

Таким образом, резюмируя, - не нужно экономить на месте, жертвуя скоростью. Скорость - самое главное в аналитике, скорость фильтрации данных и подготовки datasets для дальнейшей аналитики - то, чем не стоит жертвовать. А потому используйте денормализацию в столбцовых базах данных!

Всем привет! Сегодня я хочу поговорить про денормализацию данных. Нормализация предназначена для приведения структуры базы данных к виду, обеспечивающему минимальную логическую избыточность. Всю начальную теорию так или иначе придумал Эдгар Кодд, работавший в IBM. Когда я ещё только учился на Мат-Мехе, мне было известно лишь о 4-х нормальных формах, но сейчас есть и 5-я и 6-я и я даже знаю тех, кто реализовал аналитическую СУБД на уровне 6-й нормальной формы. Подробнее о каждой форме нормализации вы можете почитать сами, я же остановлюсь на том, почему 6-я форма ужасна с точки зрения аналитики. Итак - 6-я нормальная форма - это «декомпозиция до конца» - избавление от любой избыточности, подход, который упрощает поддержание целостности базы данных, однако работа с самими данными представляет из себя ад. Представьте, что для того, чтобы получить 3 свойства объекта, вам необходимо не только сделать 3 JOIN-а, но ещё и следить в условиях за версионностью этих самых свойств. Мало того, что организация 6-й нормальной формы - процесс трудоёмкий, он ещё и усложняет дальшейшую работу с данными. В реляционных базах данных так или иначе нормализация более чем оправдана, однако в колоночных аналитических СУБД сценарий работы совершенно другой - так как JOIN-ы дорогие, а транзакционность не требуется. Более того, в колоночных базах данных, например, в ClickHouse происходит поколоночное сжатие данных, а потому денормализация - хорошая затея. Теперь подробней про неё… Представим, что у нас есть события переходов пользователя по сайту: time, user_id, screen_from, screen_to, event И представим, что у нас есть таблица с информацией о пользователях - date, user_id, age, sex, country, city Мы хотим получить в группировке по странам, как пользователи переходят с какого-то экрана на другой, предполагая, например, найти проблемы с переводами или качеством выдачи, - видя разницу в поведении при переходе с одного экрана на другой. Переходов при этом может быть достаточно много, как и самих пользователей, и как следствие JOIN станет очень дорогим. Идея денормализации заключается в том, чтобы иметь «расширенную» таблицу: time, user_id, age, sex, country, city, screen_from, screen_to, event То есть в таблице уже есть вся интересующая нас информация о пользователе - это и есть идея денормализации, - создании избыточности данных ради скорости доступа к ним. Как вы понимаете, если пользователь совершил 100 действий (переходов), то вероятнее всего у него будет 100 строк с одинаковыми age, sex, country, city, однако, как я говорил, при поколоночном сжатии это не такая большая проблема, особенно если сортировка данных содержит в себе user_id - то есть много одинаковых данных лежат рядом и подряд, а соответственно и сжатие работает много лучше. Идею денормализации данных можно расширить до «хотим в событии иметь всё». То есть не только информацию о пользователе, но и дополнительную информацию об объекте взаимодействия, а также контекст, в котором происходит взаимодействие. Возможно, даже свойства связи объекта и субъекта. Например, если это событие подписки, то можно дополнить колонками типа had_subscription или last_subscription_date - говорящими о том, была ли у пользователя когда-либо подписка, чтобы, например, не перемалывать всю историю для определения того, что пользователь впервые покупает подписку. Где предел денормализации? На самом деле это большое искусство, которым можно овладеть, продумывая прежде основные и дополнительные аналитические сценарии, которые будут происходить над таблицей. В ВКонтакте я создавал таблицы вплоть до 150 колонок для сырых данных, а также были таблицы и на 1000 колонок для агрегированных - но это ВКонтакте. Большинству компаний, которые я консультировал, такая сильная денормализация не была нужна, а потому зачастую обходились 30-60 колонками.

Прошу прощения за то, что давно ничего не публиковал. Дело в том, что я ушёл из ВКонтакте и стал CPO в замечательной команде Ultimate Guitar, - в первый месяц был очень занят, но по мере появления свободного времени обязательно начну делиться интересной аналитикой и мыслями на тему… Уже скоро 🙂

В начале 20 века на свет появился Фрэнк Рамсей - математик, который за свою, к сожалению, недолгую жизнь дал математике достаточно много нового и познавательного. На одном из экзаменов на Мат-Мехе мне пришлось доказывать теорему Рамсея, - приятного в этом мало, но теорема весьма интересная. Строгую формулировку тут приводить не имеет смысла - она слишком сложная, а простая, тем временем, звучит так - полный беспорядок невозможен - упорядоченные конфигурации неизбежно присутствуют в любой большой структуре. Неслучайно, что на звёздном небе мы находим знакомые нам фигуры. Этот математико-философский посыл переносим и на работу с большими данными - можно попасть примерно в такую же ситуацию, - мы начинаем видеть знакомые структуры безотносительно того, имеют эти структуры под собой какую-либо объективную причину или нет. Ещё хуже обстоят дела, когда исходные данные отчасти грязные и зашумлённые, когда есть внутренние корреляции, которые мешают смотреть объективно на метрики. Потому, зачастую, аналитику первым делом нужно из большой кучи данных выделить "правильное" со многих точек зрения подмножество. Это достигается в первую очередь путём фильтраций, группировок, - SQL наиболее приспособлен к таким операциям, а потому овладение SQL запросами является, на мой взгляд, первым шагом на пути начинающего аналитика. Нужно уметь свободно крутить-вертеть данные на уровне SQL запросов, - не бояться синтаксиса, понимать возможности. Подготовка хорошего и правильного dataset-а - важнейший этап, - именно он позволяет с уверенностью приступать к поиску зависимостей. Всё это, конечно, переплетается с моим постом про колоночные базы данных, - именно они позволяют существенно (в 10-1000 раз) ускорить процесс подготовки данных, а аналитику дают возможность проверять больше гипотез за единицу времени

Послушал я вот нашего президента, посмотрел я вот на графики. Пожалуй, 4 графика говорят вот о чём: - либо у нас самое крутое тестирование в мире - либо у нас самая крутая медицина в мире - либо у нас что-то радикально не то со статистикой Я очень склоняюсь к третьему варианту. Независимо от этого, - пик не пройден... За такое же время все другие страны прошли максимум, а мы - нет. Оставайтесь, пожалуйста, дома.

Поступило несколько вопросов, связанных с ClickHouse, как с базой данных для хранения - так что сегодня мы немного углубимся в техническую сторону вопроса. Зато я опровергну некоторые мифы, которые витают среди тех, кто по каким-либо причинам сомневаются в необходимости попробовать эту базу данных. Вопрос/миф: но в ClickHouse ведь очень плохо с join-ми (то есть связыванием таблиц) На самом деле в ClickHouse всё хорошо с join-ами, если правая таблица помещается в памяти. Однако есть простые хитрости, как обойти и это ограничение. Например, можно нарезать левую и правую таблицу по модулю. Поясню, представим, что мы делаем join двух таблиц по полю user_id. Мы можем сначала отфильтровать данные в левой и правой таблицах по модулю некоторого числа - cithHash64(user_id)%100=i и для каждого i от 0 до 99 произвести операцию пересечения или дополнения таблиц - в результате на каждой итерации вы будете объединять небольшие куски данных и не будете упираться в память, но при этом обойдёте всю таблицу - правда намного эффективней и быстрее, если у ваших таблиц указан одинаковый ключ семплирования - про семплирование я обязательно расскажу в отдельном посте. У нас ВКонтакте есть некоторые скрипты, которые объединяют (в основном left join-ми) более 20 таблиц за раз. Вопрос: в ClickHouse нет оконных функций, к которым мы все привыкли. Как быть? Во многом правда, что их нет, - однако есть некоторые но. Чаще всего об оконных функциях в аналитике вспоминают, когда хотят построить воронки, то есть когда у вас есть некоторая последовательность событий во времени (a1, a2, a3, a4, a5...), а хочется на выходе получить пары (a1, a2), (a2,a3), (a3,a4) и т.д. На самом деле задача не очень тривиальная и зачастую стоит начать с того, чтобы отсортировать ваши события по времени, - после того, как они отсортированы во внутреннем запросе, можно применить трюк. Для начала собрать события в массив с использованием функции groupArray(event), собирая события, группируя, например, в пользователя: group_by user_id. В итоге для каждого пользователя мы получили некоторую последовательность действий в массиве, где каждый следующий индекс идёт позже во времени, а значит события в массив лежат отсортированные по времени. Осталось нарезать этот массив: SELECT user_id, arrayJoin(arrayMap(i -> [x[i], x[(i + 1)]], arrayEnumerate(arraySlice(x, 1, -1)))) AS pairs FROM ( SELECT 1234 AS user_id, ['start', 'registration', 'main_data', 'confirm_email', 'main_page'] AS x ) FORMAT TabSeparatedWithNames user_id pairs 1234 ['start','registration'] 1234 ['registration','main_data'] 1234 ['main_data','confirm_email'] 1234 ['confirm_email','main_page'] Как видно выше, я разбил массив из 5 элементов на 4 пары элементов. Не очень удобно и очевидно, но возможно. Стоит помнить, что это затратно по памяти, а потому сначала стоит нарезать по модулю или по сэмплу, если данных много :) В относительно последних версиях ClickHouse появилась возможность использовать функцию neighbor, которая позволяет получить доступ к значению в колонке column, находящемуся на смещении offset относительно текущей строки. В общем-то это и есть частичная реализация оконных функций LEAD()/LAG(). В любом случае, ClickHouse не стоит на месте и развивается и в будущем, уверен, появится больше прекрасных возможностей.

Где же хранить данные, чтобы потом их анализировать? Данные в общем случае нужно прочитать, затем обработать, а затем исследовать. Можно было бы хранить данные где угодно, - хоть в текстовом файле, однако тогда мы бы тратили много времени на чтение и обработку. Потому обычно данные хранят всё же в каких-нибудь базах данных в некоторых табличных структурах, где строки - это события, а колонки - это некоторые свойства события. Например, таблица может выглядеть таким образом (колонки): time | user_id | screen | event , где event может принимать значения go (переход), back (переход по нажатию “назад”). Какую же базу данных выбрать для хранения подобных событий? Аналитический сценарий работы с данными имеет важную особенность - нам как правило нужно небольшое количество “свойств” событий, - например, чтобы посчитать аудиторию, которая оказалась на конкретном экране, нам достаточно было бы прочитать 2 колонки - screen и user_id, а time и event нам не нужны. Специально для того, чтобы не вычитывать (не тратить время и ресурсы) все данные, а только те колонки, которые нужны в дальнейшем исследовании, были придуманы колоночные (столбцовые) базы данных, в которых данные хранятся на диске поколоночно. В отличие от классических реляционных баз данных, в колоночных плохо с транзакционностью, в них в общем случае невозможно каскадное удаление и они плохо дружат с изменением уже имеющихся данных. Однако аналитику всё это не требуется, - ему нужна лишь бескомпромиссная скорость. Бонусом от некоторых столбцовых баз мы получаем поколоночное сжатие данных, а значит тратим меньше места на диске и экономим деньги. Мы ВКонтакте используем hdfs в качестве медленной базы, в которой мы выполняем тяжёлые и долгие операции, и ClickHouse кластер в качестве быстрой аналитической базы, - запросы к нему в 100-1000 раз быстрее аналогичных поверх hdfs. И я был бы голословным, если бы не привёл конкретный пример запроса к одной из таблиц (названия изменены) SELECT uniq(id) AS u, count() AS events FROM table FORMAT Vertical Row 1: ────── u: 112 844 330 events: 1 586 980 513 963 1 rows in set. Elapsed: 12.976 sec. Processed 1.59 trillion rows, 6.35 TB (122.30 billion rows/s., 489.19 GB/s.) В итоге за 13 секунд мы обработали 1.6 триллиона строк, посчитав уникальное кол-во значений в колонке id и общее кол-во строк в таблице. Быстро или нет - решать уже вам 🙂

Пусть побудет тут. Больше 40 источников для поиска статистики: https://vc.ru/media/121834-bolshe-40-istochnikov-dlya-poiska-statistiki?fbclid=IwAR1HmiZmtZz7SdStIMYDFI19KMHwShH0SYuKz7vWM1-lCfRjhu1x0xxOTbA

Что такое анализ данных и зачем он нужен? Анализ данных - это в первую очередь исследовательская деятельность. Даже если вы просто смотрите на график роста заболевемости COVID-19 и делаете какие-либо выводы, - это исследовательская деятельность в её самой наглядной форме. График - это удобно, но не всегда правильно и правдиво. Правдивость нам может обеспечить в том или ином виде математика, которая помогает нам, например, определять недостоверность данных, ставить различные статистические тесты. Таким образом, анализ данных - это не просто исследовательская деятельность, но ещё и подкреплённая мощным статистическим аппаратом. Исследовательская деятельность нужна для того, чтобы проверять разные наши гипотезы - например, прошли мы пик эпидемии или нет, или похожи ли сценарии развития эпидемии в разных странах друг на друга. В исследовательской деятельности очень(и это я подчеркну) важно понимать ситуацию целиком, - нужно много данных, а потому первые пункты, с которых стоит начать: - сбор информации - структуризация информации К этим пунктам необходимо отнестись с предельным вниманием, так как от того, какую информацию собирать и в каком виде, где её хранить и как её извлекать, зависит половина успеха. В крупнейших компаниях зачастую есть специализированные отделы Data Engineer специалистов, которые занимаются исключительно инфраструктурными задачами сбора и хранения данных, однако подобное отделение нужно только в случаях действительно огромных потоков данных из разных источников - но этой теме я, пожалуй, уделю отдельный пост. Какую информацию собирать и в каком виде? От этого зависит, во-первых, что вы будете хранить и что сможете анализировать. От этого зависит также сколько денег вы потратите на носители (хотя не только от этого) информации. Тут важно помнить и о безопасности данных, если речь идёт о хранении чего-то super sensitive. Наконец, стоит учитывать тот факт, что чем более продумана схема данных, тем проще с ней будет работать и изменять её при необходимости, обеспечивая консистентность данных в вашей базе. Где её хранить? От этого зависит "сжатие" данных на диске (мы ведь хотим по возможности сэкономить на жёстких дисках), скорость работы с данными, язык, на котором мы будем работать с этими данными - искать, фильтровать, агрегировать, сканировать. Можно хранить как в текстовых файлах (спойлер, - это плохой вариант), так и в реляционных базах данных, можно хранить в распределённых файловых системах типа hdfs, в колоночных базах данных и много ещё где можно хранить... И то, как хранить и где, напрямую диктуется количеством данных, бюджетом и требованиями к консистентности, безопасности и скорости обработки этих данных. Для аналитики ВКонтакте мы используем ClickHouse и hdfs. Но подробней об этом и многом другом в следующей публикации, в которой мы поговорим о том, почему для аналитики важно иметь одновременно медленную и быструю базы данных.

Всем привет! Меня зовут Сергей и я Head of Analytics ВКонтакте. Это канал для аналитиков, CEO, CPO, разработчиков и маркетологов. Тут будет всё - от интересных аналитических исследований до конкретных рецептов по организации данных, использованию технологий, - весь спектр полезных решений из реальной жизни.