Что такое данные о событиях?

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

Почему важна структура данных событий?

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

  • Значение данных: бизнес понимает данные.
  • Качество данных:бизнес доверяет данным и, следовательно, выводам, полученным на их основе.
  • Управление данными.Компания может контролировать, кто может собирать или использовать какие данные и как.

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

Распространенные способы структурирования данных о событиях

Давайте рассмотрим, что вы сейчас делаете: читаете этот пост в блоге на веб-сайте Snowplow. Чтобы перейти к этому сообщению в блоге, вы могли просмотреть нашу домашнюю страницу, а затем перейти к блогу. Там вы прокручивали, пока не увидели интересующую вас статью, и нажали на нее. Теперь, когда вы читаете это, вы, вероятно, прокручиваете и здесь. Когда это действие фиксируется, оно представляется в виде потока событий. И этот поток событий можно зафиксировать несколькими способами.

Сбор событий в виде неструктурированных данных

Самый простой способ захвата событий — в виде неструктурированного JSON; пары ключ-значение используются для записи информации, которую вы хотели бы захватить с каждым событием. В таблице ниже показано, как действия, описанные в предыдущем разделе, могут выглядеть как неструктурированные события:

Преимущества и недостатки этого подхода рассмотрены в следующей таблице:

Сбор событий по фиксированной схеме

Еще один распространенный способ регистрации событий, особенно среди пакетных аналитических решений, таких как Google Analytics, — это следование фиксированной схеме. указано конечное число столбцов, которые могут быть заполнены для каждого события. В таблице ниже показано, как действия, описанные в предыдущем разделе, могут выглядеть как события с фиксированной схемой:

Преимущества и недостатки этого подхода кратко изложены ниже:

Каким должно быть идеальное решение?

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

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

Как мы структурируем данные в Snowplow

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

Использование схем самоописания

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

Раздел «я» вверху содержит имя события, автора события, формат схемы и версию события, к которой оно относится. Вместе эти четыре свойства составляют ключ схемы, на который будет ссылаться код отслеживания и на основе которого конвейер будет искать схему в реестре схем Iglu.

Для каждого свойства в событии могут быть наложены правила проверки на тип данных, и в зависимости от типа могут быть наложены дополнительные правила на этот тип (например, размер). Описание может быть добавлено, чтобы объяснить, что означает свойство. А свойства могут быть необязательными или обязательными. Все эти правила будут проверены конвейером Snowplow.

Однако мы забыли некоторую информацию, которая была захвачена с помощью события прокрутки ранее. Следовательно, с помощью события прокрутки мы хотели бы отправить объект статьи. Сущность — это набор свойств, которые могут быть отправлены вместе с событием, но отделены друг от друга, чтобы их можно было использовать в разных событиях, и часто представляют реальную сущность, такую ​​как пользователь, страница, продукт или, в данном случае, статья. Схема объекта статьи будет выглядеть следующим образом:

Тот же самый объект статьи также может быть отправлен с событиями просмотра страницы и щелчка, где это уместно. Это гарантирует, что одна и та же информация последовательно фиксируется для всех событий. Схема объекта следует той же логике, что и схема события; однако соответствующий объект JSON будет добавлен в код отслеживания иначе. В частности, вот как будет выглядеть событие прокрутки с сущностью статьи, реализованное с помощью JavaScript:

А вот как это событие будет выглядеть в хранилище данных:

Давайте сравним это решение с критериями идеального решения, которые мы придумали ранее:

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

2. Мы также хотим добиться предсказуемости подхода с фиксированной схемой.

  • При таком подходе создаются данные весьма ожидаемой структуры, поскольку все структуры данных заранее структурированы.

3. Мы хотим, чтобы данные были описательными, чтобы их потребители понимали, что они означают, и мы хотим, чтобы это значение сохранялось с течением времени.

  • Помимо того, что события и сущности (а также их свойства) носят описательный характер, к ним можно добавлять описания, чтобы эффективно поддерживать смысл данных.

4. Мы хотим разработать способ, с помощью которого потребители данных (и другие заинтересованные стороны) смогут применять требования к данным.

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

5. И мы хотим иметь возможность изменять данные, которые мы собираем (и как) с течением времени.

  • Семантическое управление версиями позволяет вносить изменения без ущерба для чего-либо из вышеперечисленного.

Резюме

Структурирование данных о событиях с помощью версионных схем с самоописанием позволяет поддерживать значение данных, качество данных и управление данными. Мы в Snowplow считаем, что эти три фактора имеют решающее значение для извлечения реальной ценности для бизнеса из ваших данных. В частности, они гарантируют, что вы можете распространять данные в организации, поскольку существует общее понимание того, что это значит, ваш бизнес доверяет данным и, следовательно, выводам, полученным из них, и вы можете контролировать, какие данные собираются, и кто может получить к нему доступ. Эти факторы являются основой для того, чтобы стать компанией, ориентированной на данные, где все решения (будь то принятые человеком или машиной) основаны на данных.

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