За последние полтора года мы усердно работали с нашей командой из 10 человек над проектом с открытым исходным кодом под названием Цельк:

  1. Собирать данные продуктовой аналитики в сверхструктурированном формате с потрясающими инструментами для разработчиков; а также
  2. Анализировать эти очень структурированные данные быстро в обычном блокноте, используя готовые модели данных или создавая свои собственные, и, при желании, совместно использовать анализы в других инструментах, таких как BI.

Мы снабжаем часть моделирования библиотекой с интерфейсом, подобным Pandas (называемым Бах), и это переводит все операции в SQL, работающие прямо в любом хранилище данных SQL.


Почему мы начали этот проект

Мы много работали над обеими сторонами продуктовой аналитики; как разработчики, так и специалисты по данным. И мы всегда сталкивались с одними и теми же проблемами:

  • Как фронтенд-разработчик, инструменты отслеживания не помогают в сборе правильных данных. Каждая точка данных является пользовательской реализацией, и в вашей среде IDE нет документации или линтинга, помогающего отслеживать правильные свойства и типы. Возможно, в большой электронной таблице Excel есть план отслеживания, но он, скорее всего, неполный и устаревший. И как только группа данных начинает работать с полученными данными, они постоянно запрашивают изменения/дополнения для вариантов использования, о которых они не думали заранее, а это означает, что вы все время возвращаетесь к реализации.
  • Как специалист по данным, вы должны сначала потратить большую часть своего времени на очистку, подготовку и преобразование данных, прежде чем вы сможете перейти к фактическому моделированию. И вы должны повторять этот цикл для каждого приложения и варианта использования моделирования, потому что каждый заново изобретает свой собственный формат данных. Это означает, что вы также не можете делиться и повторно использовать модели данных с другими. И затем, как только вы закончите, вам все еще нужно перевести вашу модель в готовую к производству версию.

Кому это нравится?

Кому это нравится?

Ключевой вопрос здесь в том, что существует множество отличных инструментов для сбора данных или моделирования, но нет ничего, что на самом деле связывало бы их.

Разрыв между сбором данных и моделированием

Сбор данных и моделирование не связаны


Что мы создали, чтобы попытаться исправить это

Набор тесно интегрированных инструментов для преодоления разрыва между сбором данных и моделированием:

  1. Ан открытый формат данных который подходит для любого варианта использования пользовательского интерфейса продукта и аналитического моделирования.
  2. SDK трекера для современных фреймворков с отличной поддержкой разработчиков.
  3. Ан ‘открытый модельный хаб’: библиотека Python с коллекцией готовых моделей данных.
  4. Бах: библиотека Python, которая запускает модели и операции непосредственно в любом хранилище данных.

Подробнее о каждом из них ниже.


1) Открытый формат данных, который подходит для любого варианта использования пользовательского интерфейса продукта и моделирования.

Мы называем это открытая таксономия аналитикии мы приглашаем всех внести свой вклад в это.

Это попытка создать универсальную общую структуру для аналитических данных. До сих пор мы работали с вариантами использования данных и аналитики более чем 50 компаний, чтобы определить его, и убедились, что он охватывает все это. Конечно, он также расширяем для любых пользовательских вариантов использования.

Одна вещь, которую мы также рассмотрели с таксономией, — это знание того, где именно произошло событие в пользовательском интерфейсе, потому что почти каждый вопрос о данных начинается с этого. Мы называем это «Осведомленность об интерфейсе». Например, предположим, что у вас есть веб-сайт с основным разделом и кнопкой внутри него; когда вы нажимаете кнопку, эта точная иерархия пользовательского интерфейса фиксируется в так называемом РасположениеКонтекст. Таким образом, специалист по данным всегда может связать события с тем, где они произошли в пользовательском интерфейсе, даже если они со временем меняются.

См. небольшую часть таксономии на скриншоте ниже:

Таксономия открытой аналитики: несколько событий

Таксономия открытой аналитики: несколько событий

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


2) Tracker SDK для современных фреймворков с отличной поддержкой разработчиков

Мы постарались максимально упростить жизнь фронтенд-разработчика.

В настоящее время у нас есть SDK для React, React Native, Angular, а также простой JavaScript. Скоро появятся полные SDK для Vue и Next.js, и в нашем списке есть и другие. Мы стремимся иметь SDK для каждой популярной платформы/фреймворка, поэтому инструментарий идеально подходит для каждой из них.

Что касается инструментария, таксономия точно предписывает, что и как отслеживать, поэтому вам не нужен план отслеживания. Вы можете просто поменять местами любой компонент или элемент HTML в своем приложении с его аналогом Objectiv, который поставляется с SDK (например, Отслеживаемая кнопка для кнопки), или если у вас есть свои компоненты, вы можете их обернуть. Это будет автоматически отслеживать все, со всеми необходимыми данными и местоположением пользовательского интерфейса.

Пример ссылки, которая отслеживается при переходе по ней со всеми необходимыми данными и местоположением пользовательского интерфейса, автоматически добавляемыми

Пример ссылки, которая отслеживается при переходе по ней со всеми необходимыми данными и местоположением пользовательского интерфейса, автоматически добавляемыми

Ваши собственные компоненты, к которым вы добавили отслеживание, также можно легко повторно использовать в любом месте вашего приложения. SDK автоматически применит местоположение пользовательского интерфейса и отследит его.

Помимо этого, есть несколько инструментов, которые помогут с проверка по таксономии прежде чем он попадет в базу данных, см. ниже.


Валидация: в IDE

Все компоненты SDK поставляются с определениями TypeScript, поэтому вы получите встроенную документацию по каждому компоненту. Вы также получаете линтинг для любых проблем, например, чтобы убедиться, что вы используете правильные поля для компонента и правильные типы данных.

Линтинг в IDE для решения проблем с проверкой

Линтинг в IDE для решения проблем с проверкой


Проверка: в приложении для обеспечения осведомленности о пользовательском интерфейсе.

Допустим, вы добавили две кнопки с одинаковым текстом и ссылкой на экран, но не отслеживаете раздел, в котором они находятся. они, вероятно, будут преследовать вас позже :)).

Итак: предупреждаем об этом заранее, в консоли браузера, при загрузке страницы (при регистрации компонента).

Проверка «осведомленности о пользовательском интерфейсе» в консоли браузера

Проверка «осведомленности о пользовательском интерфейсе» в консоли браузера

Чтобы исправить это, SDK упрощает отслеживание раздела, в котором находятся кнопки, поэтому они уникальны.


Проверка: в приложении, чтобы убедиться, что правильные данные отслеживаются

Даже если у вас есть индивидуальный кейс для отслеживания, вы все равно не одиноки: вы получаете те же инструменты проверки, что и в обычном SDK. Например, если вы не применяете правильные данные, вы получите предупреждение, как показано ниже, в консоли браузера.

Проверка отслеживаемых данных в консоли браузера

Проверка отслеживаемых данных в консоли браузера

Сообщения очень описательные. Здесь говорится, что RootLocationContext отсутствует в стеке местоположений этого Прессевент, со ссылкой на справочную документацию. На самом деле это одна из ключевых точек данных, фиксирующая местоположение пользовательского интерфейса верхнего уровня, где произошло это событие, например, домашняя страница. Кроме того, есть ссылки на документацию, относящуюся к вашей платформе (в данном случае React), в которой рассказывается, как решить эту проблему.

Эти типы сообщений запускаются для любых данных, которые отсутствуют, дублируются или являются избыточными.


Валидация: сквозное тестирование со снимками

После того, как у вас есть отслеживание, вы хотите убедиться, что оно не сломается при разработке вашего приложения. Для этого наши SDK поддерживают тестирование с любой уже имеющейся у вас инфраструктурой непрерывной интеграции, использующей моментальные снимки. Например, мы используем Cypress для нашего веб-сайта, и на снимке экрана ниже показан один из наших тестов.

Проверка сквозным тестированием с использованием моментальных снимков

Проверка сквозным тестированием с использованием моментальных снимков

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

Вы можете запустить это локально во время разработки или в CI. Например, мы запускаем наши тесты с действием GitHub при каждом нажатии.


Для серверной части: используйте Snowplow или Postgres.

Мы также подумали об Ops :-). Есть бэкэнд ‘Коллекционер’ который хранит данные в Postgres, например, для использования при локальной разработке или если вы хотите быстро настроить. Но есть и полная интеграция с Снегоочистителькоторый также без проблем работает с существующей настройкой Snowplow.


3) «Открытый концентратор моделей»: библиотека Python с коллекцией готовых моделей данных.

Для каждого продукта или проекта мы обычно проводим много одинаковых анализов, которые нам приходится создавать с нуля: количество пользователей, удержание, продолжительность сеанса и так далее. Чтобы сделать это намного проще, мы создали библиотеку Python с коллекцией готовых моделей данных, которые вы можете просто взять с полки, таких как матрица удержания, обнаружение воронки, логистическая регрессия и т. д. Ознакомьтесь с текущим (и растущим) списком моделей здесь..

Мы называем это открытый модельный хаби, как и в случае с таксономией, мы приглашаем всех внести свой вклад, чтобы он мог охватить все варианты использования аналитики.

# show a retention matrix, monthly, with percentages
retention_matrix = modelhub.aggregate.retention_matrix(
    df, 
    time_period='monthly',
    percentage=True, 
    display=True)
retention_matrix.head()
Войти в полноэкранный режим

Выйти из полноэкранного режима

Пример модели из открытого концентратора моделей, работающей в блокноте Jupyter.

Пример модели из открытого концентратора моделей, работающей в блокноте Jupyter.

Собирая данные в соответствии с таксономией открытой аналитики, вы можете повторно использовать свои модели и делиться ими с другими; вы даже можете совместно использовать модели из разных наборов данных и извне, из разных компаний.


4) Bach: библиотека Python, которая запускает модели и операции непосредственно в любом хранилище данных.

Последняя часть — это библиотека Python, которая называется Бах это позволяет вам создавать модели данных для любого набора данных, как и в случае с Pandas. Разница в том, что под капотом каждая операция транслируется в SQL, который выполняется непосредственно в хранилище данных, поэтому вы работаете с полным набором данных (хотя вы также можете переключаться между ним и образцом с помощью одной команды).

# generate descriptive statistics of a DataFrame
# directly queries the database
df.describe(include='all').head()
Войти в полноэкранный режим

Выйти из полноэкранного режима

Мы сохранили его интерфейс почти таким же, как у Pandas, поэтому вам почти не нужно учиться. Кроме того, в него добавлены некоторые дополнительные операции, облегчающие работу с данными, собранными в соответствии с таксономией открытой аналитики, например, создание определенного кадра данных из базы данных.

Поскольку он переводит все в SQL, после того, как вы закончите создание модели, ее запуск в производство — это просто вопрос экспорта полученного SQL в любое решение, такое как dbt, инструмент BI, такой как Metabase, и т. д. По мере создания моделей непосредственно в полном наборе данных, вы можете быть уверены, что он работает так же и в рабочей среде.

Вывод SQL из моделей запускается непосредственно в BI-инструменте, таком как Metabase.

Вывод SQL из моделей запускается непосредственно в BI-инструменте, таком как Metabase.

Цель Bach — быть на 100 % независимым от хранилища данных, чтобы вы могли беспрепятственно переключать любую созданную вами модель на другую базу данных. В настоящее время мы поддерживаем PostgreSQL, Google BigQuery и (очень скоро) Amazon Athena. Далее идут Databricks, RedShift, Clickhouse и т. д.


Куда мы хотим пойти с проектом

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

В конечном счете, мы хотим облегчить жизнь как разработчиков, так и специалистов по обработке и анализу данных (и, следовательно, нашу собственную жизнь :)), и иметь возможность тратить больше времени на то, что им нравится.


Проверьте это и дайте нам звезду 🙂

Надеюсь, вам понравится. Ознакомьтесь с проектом на GitHub и, пожалуйста, поставьте нам звездочку, чтобы другие тоже могли нас найти!