Почему веб-аналитика, такая как Google Analytics, использует измерения и метрики вместо оператора SQL? - PullRequest
5 голосов
/ 10 августа 2010

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

Почему причина этого? Я думаю, что у него нет интерфейса SQL (или простой загрузки журнала веб-сервера)? Если да, то как операторы SQL переводятся в Измерение, Метрики (и Сегмент и Фильтры)?

Кажется, что метрики, как правило, являются "агрегатами", такими как count () или среднее (), а Dimension, как правило, является самими зарегистрированными значениями (такими как Browser == IE или Country == Австралия), что соответствует значениям group by. Фильтры похожи на условные, а как насчет сегмента?

Похоже, что если мы укажем Dimensions, то он автоматически сделает group by и отобразит это поле. Обычно считается () или сумма (). Что если мы хотим вместо этого average(*)? А что, если мы хотим, чтобы это показывалось, но не хотим, чтобы оно показывало group by?

пример веб-сайта для эксперимента: http://code.google.com/apis/analytics/docs/gdata/gdataExplorer.html

Ответы [ 5 ]

7 голосов
/ 18 августа 2010

Использование терминов «Измерения» и «Метрики» предполагает, что Google использует базу данных OLAP, а не реляционную базу данных .... SQL используется для реляционных баз данных: OLAP использует MDX или собственные языки запросов (если Oracle).

С http://en.wikipedia.org/wiki/OLAP

Ядром любой системы OLAP является куб OLAP (также называемый «многомерный куб» или гиперкуб).

Он состоит из числовых фактов, называемых мерами , которые классифицируются по измерениям .

3 голосов
/ 23 сентября 2010

Полагаю, если вы задаете такой вопрос, вы, вероятно, уже давно прошли через просмотр некоторых из готовых отчетов, таких как простые просмотры страниц. Если это все, что вы делаете, то вы значительно упускаете смысл и мощь веб-аналитики. Веб-аналитика в целом (не только GA) - это анализ тенденций в данных с течением времени. А сами данные получают, следуя определенным правилам и поведению, как заранее определенным, так и определяемым пользователем.

Большая часть данных для отчетов не может быть легко извлечена из прямого запроса к базе данных, потому что данные основаны на аннотациях, таких как "xyz over time" и агрегированных данных. Например, концепция «области действия» для измерений и метрик, где переменная и / или значение будут сообщать данные об одном просмотре страницы / событиях, или в течение посещения (сеанса), или даже в течение определенного пользователем времени. (например, «сделать это последним за месяц» или «сделать это последним, пока не произойдет какое-либо событие», например, при извлечении определенной переменной или типа переменной).

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

Посмотрите на отслеживание кампании в качестве примера. Все начинается с одного значения var =. Когда пользователь щелкает ссылку и переходит на страницу с этим значением var = в URL, код отслеживания захватывает это значение и начинает присваивать не только данные о странице (URL, время, тип браузера, список и т. Д.). и на), но также и все другие данные, собранные из пользовательского кодирования. Затем есть другие параметры, которые вы можете применить к нему, такие как привязка цены за клик или какой-то взвешенный показатель, определение успеха в достижении цели или события и т. Д. ... на основе других правил (первичное сопоставление с указанием последнего клика и т. Д. ..). Список вещей, которые входят в игру, и то, что считается, можно продолжать и продолжать и продолжать. Попробуйте сами и сделайте эти строки запроса к базе данных. Теперь вымойте, сполосните и повторите, потому что это был всего лишь один код кампании. У меня были клиенты с тысячами кодов кампаний, и каждый день добавлялось много новых. Да, и, кроме того, настройка или создание новых запросов в зависимости от того, как вы хотите, чтобы в реальном отчете отображались данные. Перекрестные ссылки и разбивка по XYZ. Глядя на последовательности и сценарии на основе этих данных. И это только для кампаний, одна вещь из многих.

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

3 голосов
/ 20 августа 2010

Вероятно, он был разработан внутри компании с использованием собственных технологий, таких как Big Table и Map-Reduce. Отображение и агрегирование являются сильными сторонами алгоритмов типа Map-Reduce, поэтому имеет смысл, что данные будут агрегироваться по разным измерениям, подобным этому.

Если вы хотите узнать о них больше, я бы предложил следующие статьи из Википедии:

2 голосов
/ 10 августа 2010

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

Я не совсем уверен, что данные Google Analytics хранятся в SQL-формате (например, столбцы и строки из таблиц). Я читал, что они разработали свой собственный внутренний способ хранения этих данных.

1 голос
/ 09 декабря 2011

Мы задали себе подобный вопрос. Похоже, что многие API веб-аналитики являются запоздалой мыслью и часто являются прямым отображением функций пользовательского интерфейса соответствующего продукта. С Infunl (Отказ от ответственности: я являюсь соучредителем) мы создаем API веб-аналитики с гибким языком запросов, синтаксически похожим на SQL, но с высокой степенью оптимизации для структуры агрегации и сокращения отображений. Кроме того, он предлагает множество встроенных функций, специально предназначенных для веб-аналитики, таких как этапы конверсии, когортный анализ, поддержка сплит-тестирования и гибкая группировка и сегментация контента.

...