Почему веб-аналитика, такая как Google Analytics, использует параметры и показатели вместо выражения SQL?

Question

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

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

Похоже, что показатели имеют тенденцию быть «агрегатами», такие как кол () или среднее (), и измерение имеет тенденцию быть сами регистрируемые значения (например, браузер IE == или Страна == Австралия), который совпадает с значениями group by. Фильтры похожи на условные, а как насчет сегмента?

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

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

Answer 1

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

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

Answer 2

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

От http://en.wikipedia.org/wiki/OLAP

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

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

Answer 3

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

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

• http://en.wikipedia.org/wiki/Bigtable
• http://en.wikipedia.org/wiki/Map_reduce

Answer 4

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

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

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

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

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

Answer 5

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