GoPractice разработали симулятор работы с SQL для продактов
Зачем он нужен и чем может быть полезен профессионалу.
У многих продакт-менеджеров есть два способа узнать, как люди пользуются продуктом: коробочное аналитическое решение или аналитик в команде. Но оба подхода к работе с данными существенно ограничивают возможности и эффективность продакт-менеджера (а заодно мешают аналитику заниматься своей, а не чужой работой).
Третий и более сложный путь — обращаться к данным напрямую, без посредников и в любое время. Для этого нужно уверенно владеть SQL. Чтобы научить продакт-менеджеров и других участников продуктовой команды справляться с такими задачами, команда GoPractice разработала симулятор SQL для продуктовой аналитики. На примере данных маркетплейса специалистов обучают разбираться, где лежат данные, как именно они хранятся, какие в них есть особенности и что с ними можно делать. Как создавали симулятор SQL и чем он поможет продактам — читайте в этом материале.
Как возникла идея
Три года назад нашим первым и единственным образовательным продуктом был «Симулятор управления продуктом на основе данных», который обучал управлению продуктом на раннем этапе — от идеи к достижению product/market fit.
Симулятор решал не только образовательную задачу, но и объединял студентов в продуктовое сообщество, для которого мы стремились создать еще больше ценности. Так возникла мысль о создании других образовательных продуктов. Но прежде, чем переходить к реализации, нам нужно было понять, какие именно профессиональные темы больше всего востребованы нашими студентами.
Оказалось, что наиболее высокий спрос был у Python и SQL, а также темы управления ростом продукта (о ней мы поговорим позже).
Проблема с обучением Python заключалась в том, что интерес к теме был в большей степени обусловлен хайпом. Python — самый популярный язык программирования в мире. Но, на наш взгляд, в продуктовой работе он востребован гораздо меньше, чем например, SQL.
С SQL ситуация иная: его незнание действительно снижает эффективность тех, кто работает над продуктом или маркетингом, потому что они вынуждены постоянно обращаться к аналитикам даже по простым запросам. Это отнимает время у всех участников процесса.
Даже те, кто владеет SQL на базовом уровне, часто не могут применить его в работе — не хватает навыков, чтобы переложить имеющиеся знания на реальные продуктовые задачи.
Поэтому уже на этапе проработки идеи мы договорились, что не будем делать курс с выдуманными абстрактными задачами, а сосредоточимся на прикладных ситуациях, иллюстрирующих реальную работу над продуктом или маркетингом. Для этого мы взяли несколько десятков кейсов из общения со студентами, в которых им мог бы пригодиться SQL, а затем анализировали их, чтобы понять, стоит ли разбирать их в нашем симуляторе.
В ходе опроса мы узнали, с какими задачами люди обращаются за помощью к своим коллегам, какие аналитические инструменты хотели бы освоить и для каких задач использовать. Мы просили привести примеры реальных рабочих задач, с которыми наши студенты недавно сталкивались, и объяснить — как они решали их, не владея самостоятельно необходимыми навыками. Дальше мы оценивали каждый кейс, отбирали самые приоритетные и частотные задачи. Именно они легли в основу нашего образовательного продукта.
Очень много данных
Ключевым элементом — и самой трудоемкой частью в создании симулятора — стал датасет, на основе которого будут обучаться студенты. Перебрав много разных вариантов, мы пришли к решению, что датасет маркетплейса лучше всего подойдет для иллюстрации популярных практических задач, которые мы собрали на прошлом этапе.
Такой датасет хорош, во-первых, за счет количества различных переменных внутри продукта: покупатели, продавцы, товары, категории. Это позволяет создать комплексную картину работы с реальным продуктом.
Во-вторых, маркетплейс дает наиболее широкий набор кейсов, которые можно решить как с точки зрения продукта, так и с точки зрения бизнеса в целом. Важную роль сыграл и опыт работы Олега в компании, развивающей международный маркетплейс.
На основе этого датасета студенты должны разобраться:
как и где лежат данные;
- как их изучать;
- как их чистить;
- как проверять результаты;
- как решить задачу с помощью подручных средств, даже если не получилось написать идеальный запрос;
- как считать продуктовые метрики.
Вся работа над датасетом заняла несколько месяцев, а с учетом доработки данных — больше года. Каждая итерация для генерации данных занимала десятки часов, а учесть нужно было огромное количество факторов.
У нас есть маркетплейс, в него пришел пользователь. Какой у него источник трафика? Из какой он страны? Что и когда он купил, на какую сумму? Когда он возвращался в продукт? И так далее. И это лишь один пользователь, а их будут десятки тысяч.
Затем надо внести данные о продавцах, о товарах, когда они появились на площадке, кто их купил. Все эти данные должны быть реалистичными, отражать реальную работу крупного маркетплейса и быть взаимосвязанными — то есть если пользователь покупает товар, то значит этот товар должен быть в наличии у конкретного продавца в определенный момент. Важно было учитывать и наличие истории, внутренних взаимосвязей и логики в данных.
Дополнительно мы проработали сезонность, например как меняется Retention пользователей в зависимости от дня недели, месяца или сезона, учли, как меняется активность в покупателей в зависимости от времени суток.
Датасет намеренно приближен к реальному, поэтому в нем есть неточности, дубликаты данных, несуществующие пользователи и прочие баги, с которыми студентам нужно учиться разбираться. В реальной жизни маловероятно построить такую базу данных, в которой всего этого бы не было. Поэтому лучше научиться работать с такими данными на раннем этапе.
Как строили обучение
Самой сложной частью в создании симулятора стал дизайн глав: разложить комплексные темы и задачи на логичные составляющие, менять темп прохождения, чередовать сложные главы с простыми.
Ключевым в дизайне глав было выстроить для студентов понимание того, как устроены таблицы и почему нужно использовать именно такой запрос, чтобы получить нужный результат.
Курс построен таким образом, что мы умышленно повышаем сложность заданий немного быстрее, чем даем студентам все новые инструменты для их решения. Это ведет к тому, что пользователи решают задачи с помощью старого инструментария, что может приводить к сложными, громоздкими и неэффективными решениям. Уже после этого мы мы рассказываем о новых конструкциях, которые позволяют решить задачу намного элегантнее. Цель в том, чтобы студент понимал, что любую задачу можно решать разными способами, но также начинал чувствовать на интуитивном уровне, зачем нужны те или иные функции или операторы.
Другим важным подходом стало то, что мы для многих заданий пошагово показываем, как конкретно запрос отрабатывает поверх таблицы. Это позволяет людям визуализировать процесс работы запросов и понять их намного лучше.
Первые версии симулятора мы обкатывали в Google Docs и Zeppelin с тестовыми группами. На этом уровне структура глав еще очень сильно менялась, а существенную часть образовательной работы выполняли мы сами.
По мере того, как мы понимали, как правильно доносить до студентов новые знания и навыки, симулятор начал приобретать все более устойчивую форму.
Как симулятор SQL стал частью симулятора роста — и обратно
Еще на этапе опроса, перед началом работы над SQL-симулятором, мы выяснили, что нашей аудитории интересна тема управления ростом и масштабирования продукта уже доказавшего свою ценность. И тема эта значительно сложнее и многообразнее, чем тема первого симулятора от GoPractice.
Потратив огромное количество сил и ресурсов на создание истории и датасета для SQL симулятора, мы решили объединить два направления работы и интегрировать накопленный для SQL-симулятора материал и личный опыт в то, что впоследствии стало «Симулятором управления ростом продукта» (прочитать подробнее о нем можно здесь).
Логика была такая: если в первом симуляторе сработало обучение управлению продуктом с комбинации с работой в аналитическом инструменте Amplitude, то во втором симуляторе тоже можно подключить инструмент для аналитики, в частности SQL, который студент изучает параллельно с теорией.
Стало понятно, что обучение SQL и обучение управлению ростом продукта — это две разные задачи, для разных сегментов аудитории. Поэтому «Симулятор SQL для продуктовой аналитики» стал самостоятельным продуктом.
При этом SQL по-прежнему выполняет в симуляторе роста важную роль, позволяя самостоятельно изучать данные в процессе прохождения. Но для тех, кому изучение или использование SQL неактуально или неинтересно, мы сделали задания с SQL опциональными — всегда можно воспользоваться уже готовым запросом, чтобы получить и изучить необходимые данные.
Понять, что симуляторы лучше развести как самостоятельные продукты, нам помог фидбек от тестовых когорт. Общение со студентами по итогам тестов позволило вычистить огромное количество мелких ошибок и переделать структуру симулятора, чтобы качественнее доносить знания и навыки до студентов.
Что есть в симуляторе, а чего нет — и почему
Целью нового симулятора было обучить SQL на уровне, который позволит решать типичные продуктовые задачи, связанные с продуктом или маркетингом. В этом помогли эксперты и фидбек студентов, которые сразу применяли знания на практике и делились новыми задачами. Так цикл повторялся несколько раз.
Наиболее частыми запросами, которые нашли отражение в симуляторе, стали:
- Задачи по подсчету кривой Retention
- Расчет верхнеуровневых метрик (DAU/WAU/MAU)
- Подсчет количества новых пользователей, продаж, прибыли
- Расчет LTV, сегментация или выгрузка пользователей по условиям
- Подсчет ROI для каналов привлечения и многие другие
При этом мы намеренно отказались от некоторых тем, например манипуляции данными с использованием SQL: удаление, изменение или добавление данных, создание таблиц и так далее. Это важный пласт знания об SQL, но, на наш взгляд, он в гораздо меньшей степени актуален для продактов, маркетологов, а иногда и аналитиков, потому что за целостность данных в базе и минимизацию ручного вмешательства отвечают программисты.
Результат работы
По итогам разработки симулятора мы получили:
- Около 4,5 миллионов записей о пользователях маркетплейса
- 130 тысяч записей о продавцах, которые сгенерировали 8 миллионов записей о товарах
- Десятки миллионов записей о просмотрах и покупках товаров пользователями, и других данных
- Общий размер смоделированной базы — 15 гигабайт
От наших партнёров мы получили первые отзывы о симуляторе.
До 15 ноября читатели vc.ru могут купить курс с 15% скидкой по этой ссылке. Студенты не ограничены по времени прохождения, доступ ко всем материалам сохраняется и после завершения симулятора. Если при регистрации или логине вы не увидели скидку, то напишите на [email protected].
Sql придумали как язык для бухгалтеров, специально максимально доступный, даже синтаксис подобен разговорной речи.
Учебники по нему есть замечательные.
Учил sql oracle ещё давно по учебнику Фейерштейн С., Прибыл
Максимально доступная подача информации с примерами, которые прилагались к учебнику. Я с трудом представляю более простую и понятную подачу чем дана в этой книжке.
В чем конкретно ваше преимущество?
Это отчасти правда. Но много ли вы знаете бухгалтеров, способных овладеть SQL? Видимо бухгалтеры 80х не чета нынешним.
Да что там бухгалтеры, многие разрабы не могут вполне SQL овладеть, боятся его как чёрт ладана, прячутся за всякими убогими ORMами.
Ну если разработчик не способен овладеть SQL, то что-то я сомневаюсь в том, что он вообще профпригоден к этой сфере (ИТ)...
Есть куча областей где он вполне может работать без знаний SQL
Это правда. Но все же SQL, действительно, очень простой язык, так что вопрос про профпригодность все равно всплывает
Соглашусь с вами.
Тем не менее какой нибудь фронтэндщик с хорошим опытом, я считаю, имеет полное право послать нах любого и отказаться от таких тестов на профпригодность ))
Интересный миф про бухгалтеров, это по версии самих бухгалтеров? )
SQL появился в начале 70-х, да еще и в лаборатории IBM, так что при всем уважении ко всем бухгалтерам мира, он в принципе не мог быть придуман для бухгалтеров.
Сколько стоит ?
А цена? в личку писать :)
Классная шутка, но продактам эскюэль не нужен, он нужен продуктовым аналитикам. Задача продакта - не вытаскивать сырые данные, а работать с ними.
Это если он есть...
Если аналитика нет, то тогда вытаскивать сырые данные запрягаем разраба, в любом случае не царское это дело - в эскюэле запросы писать)
да. разрабу же делать нечего кроме как писать запросики по типу select count для эффективных менеджеров, которые не могут час потратить чтоб самому научиться этому
Как правило разрабы не сильно загружены. Эффективный менеджер в состоянии напрячь и заставить сделать это.
да, эффективный менеджер однозначно крутая профессия. я же говорю, час потратить на изучение чего-то, чтобы в будущем не отвлекать разработчиков, а делать это самостоятельно — это сложно, здесь эффективному менеджеру надо мозги напрячь, которых обычно нет. бывает
Тоже плохие новости. Такие дорогие сотрудники и не сильно загружены
Дело в скорости. Представьте что вы за час сможете десяток гипотез проверить, если самостоятельно будете писать запросы. Причем гипотезы могут рождаться одна из другой. Представьте, сколько займет времени десяток циклов гипотеза->задание разрабу->разработка->исправление ошибок->анализ->новая гипотеза.
Ваш конкурент-продакт, владеющий SQL, вас обойдёт.
ждем 2 дня
У меня плохие новости для вас. Вы неэффективны))
Лол. Вы живёте в идеальном мире.
Говорю вам как продакт, который в экселе с помощью кучи формул строит продуктовую аналитику. Потому что в компании ни аналитика, не нормальной визуализации данных. Хорошо, что сырые данные хоть вытащить можно
Куда стыдливо спрятали цену? Показывайте.
даешь цены)
Зачем симулятор, если есть доступный SQL? Если вам не нужен именно SQL, то зачем его здесь поминать? Если мы хотим анализировать данные, то может сразу и рассматривать соответствующие продукты?
Думается, что основная ценность данного продукта — в наличии готовой сложной базы и заданий к ней.
Чем отличается от sql-ex.ru которому уже точно более 10 лет?
Без понятия :) Я ни тем, ни другим не пользовался
Ребята - крутые продакты GoPractice, вы хоть с формой регистрации в мобильный версии что-нибудь сделайте, посмотрите, посчитайте.
Сапожники без сапог.
я продакт, прошел этот курс. Помогает иногда что-то самому вытащить из данных или поправить запрос, хоть в команде и есть 2 аналитика.
Не могу сказать, что SQL - критический скилл для продакта, но навык работы с данными точно is a must, который качается в т.ч. при написании запросов
Можно примеры?
например, для приоретизации бэклога - считаю размеры сегментов, воронки.
Еще пример, собранный аналитиком отчет engagement-matriх смотрел по разным когортам. Это очень удобно, когда на возникшую в голове гипотезу тут же можно получить ответ, и думать дальше.
Gopractice лучшие! Спасибо за этот курс! А то пришлось покупать у другой команды productdo, которая сделала жалкую породию на Gopractice, при этом совершенно ужасная и не понятная подача.
А зафиг симулирoвать, если можно в контейнере запустить настоящие Postgres, Марию, Influx, Victoria Metrics, и т.д. и т.п., а сверху пришлёпнуть учебно-тренировочный GUI?
Вот и я в непонятках. Любому аналитику достаточно сдампить рабочую базу и сидеть извращаться с ней как душе пожелается. Зачем эмуль то вообще нужен?
А под какую СУБД у вас SQL? Oracle, MSSQL, PostgreSQL?
PostgreSQL
Хах!
Примечательно, что SQL изначально создавался для менеджеров и аналитиков, не знакомых спрограммированием. Чтобы они легко и просто могли получать нужные им данные из баз данных, обращаясь к ней на очень простом языке
SELECT MAX(name), SUM(salary) FROM Customers WHERE salary > 2000 and currency = 'USD'
- это важный момент, так как сейчас можно встретить SQL-код на несколько тысяч строк (не считаю что это хорошо, но видеть такое приходилось)
Давай не будем сравнивать ранний SQL и то, во что он превратился, будучи уже ориентированным на программистов, а не на менеджеров. У нас не все программисты понимают что такое оконные функции и как работать с курсорами и транзакциями, не говоря уже о триггерах и хранимых процедурах...
- ну вот как раз менеджеру может быть интересно создать какое нибудь представление для сбора отчетности, навесить триггер или запускать хранимку
И повесить базу, потому что она слишком большая, под аналитический запрос не созданы индексы и тд.
Мечты работать с базой у менеджеров об это часто разбиваются - доступ к полной базе никто не даст
С курсорами лучше не работать, вот и не знают поэтому)
Ой, ну это база и гуглится в момент, а хранимые процедуры вообще бед практис, так что не надо тут.
чоблять? какая ещё бэдпрактис? Ты с луны свалился или зумер обычный?
Комментарий удален модератором
И все-таки, где цена?
Комментарий удален модератором
Комментарий удален модератором
стоило в начале разобраться с проблемами в заданиях в симуляторе, прежде чем запускать новый продукт