Хранилища данных,
OLAP, CRM: информация
 
 На главную | Книги | Ссылки | Рассылка | Письмо автору | RSS

Совет №1
Руководство по проектированию выразительной витрины данных для анализа журнала посещаемости веб-сайта


Материал опубликован с разрешения компании Ralph Kimball Associates
Автор оригинала: Ральф Кимбал (все статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь.

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

Размер журнала посещаемости огромен. Даже коммерческие серверы со средней загруженностью могут ежедневно генерировать до 100 миллионов записей о событиях на страницах сайта. Мы должны уменьшить количество данных до управляемых размеров для проведения наиболее важных видов анализа. В этом совете мы поищем способ НЕ выйти за пределы 100 миллионов записей, вместе с этим сохранив приемлемый уровень детализации для анализа поведения посетителей веб-сайта.

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

Рекомендуемая степень детализации таблицы фактов для анализа поведения посетителя:

Одна запись таблицы фактов = Одна сессия посетителя

Если в среднем каждая сессия состоит из 20 событий, то количество записей таблицы фактов сократится до 5 миллионов в день, что сравнимо с опытом построения хранилища данных для сети розничной торговли среднего размера.

Рекомендуемые измерения для данной таблицы фактов:

  • День веб-сервера (календарная дата как её фиксирует веб-сервер)
  • Время веб-сервера (начало сессии как количество секунд, прошедших с полночи на часах веб-сервера)
  • День посетителя (календарная дата с точки зрения посетителя сайта)
  • Время пользователя (начало сессии как количество секунд, прошедших с полночи на часах посетителя)
  • Посетитель (обобщённое понятие "Посетитель" для анонимных посетителей, уникальное генерируемое системой имя для незарегистрированных посетителей, принявших cookie и реальное имя для зарегистрированных посетителей)
  • Стартовая страница (идентификатор первой страницы данной сессии: страница, привлёкшая посетителя из другого места в web)
  • Последняя страница (идентификатор последней страницы данной сессии: может быть "убийцей" сессии)
  • Ссылающийся контекст (URL страницы, с которой посетитель попал на сайт, если известен)
  • Диагностика сессии (простое описание характера сессии)

Рекомендуемые числовые факты:

  • Количество посещённых страниц
  • Общее время пребывания на сайте (некоторая оценка, поскольку мы не можем знать реальные действия посетителя)

Эта модель может стать очень мощной базой для оценки поведения посетителя веб-сайта. Наиболее важное измерение - "Диагностика сессии". Вы должны разработать сложный процесс преобразования и загрузки данных для создания хорошей диагностики сессий из последовательностей детальных событий на страницах сайта.

Для продолжения знакомства с данным предметом можно ознакомиться со статьёй из архива журнала Intelligent Enterprise (к сожалению, адрес, указанный в оригинале, не существует - прим. перев.).
Ещё одна статья появится в журнале Intelligent Enterprise в январе 2000 года. В ней более подробно будут рассмотрены измерения "Страница" и "Диагностика Сессии".

Комментарии к совету №1

Я получил ряд интересных комментариев по поводу первого совета, который рекомендовал многомерную модель для сбора данных о посещаемости веб-сайта. Несколько человек спросили меня о том, почему я рекомендовал детализацию таблицы фактов на уровне завершённой сессии, в то время как в статье в журнале Intelligent Enterprise от 5 января 1999 года рекомендуется выбрать уровень детализации в одно событие на странице. Эти люди спрашивали меня, не изменил ли я своего мнения.

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

1) Запись в таблице фактов = отдельное событие на странице. Этот уровень, описанный в статье в журнале IE, может предоставить детальные карты и траектории каждого посещения сайта, если вы сохраняете каждую запись. Но для сайтов с очень высокой загрузкой это составит очень большой объём данных. Вы потратите всё своё время и деньги, собирая и сохраняя данные, а не анализируя их. Несколько человек рассказали мне о том, что статистические методы могут на тестовых выборках в 1% от всего объёма данных достаточно достоверно описать характер использования сайтов, что может помочь в принятии важных решений о том, как сайт используется, даже если в выборке не присутствует информация обо всех посетителях. Мне очень нравится это предложение. Вам, возможно, потребуется консультация опытного специалиста в области статистики для проведения репрезентативной выборки ваших данных.

2) Запись таблицы фактов = одна законченная сессия посетителя. Это уровень детализации, описанный в рекомендации №1. В этом случае вы можете реалистично собрать информацию обо всех посетителях, несмотря на то, что вы не видите полную траекторию их навигации по вашему сайту. Но вы можете провести широкий демографический анализ, а также анализ эффективности вашего сайта. Помните, что в Вашем распоряжении есть информация о стартовой и последней страницах, а также измерение "Диагностика сессии".

3) Запись таблицы фактов = страница сайта за календарный день. Этот уровень детализации является одним из похожих на него уровней агрегации, которые могут пригодиться для оценки общей картины посещаемости отдельных частей вашего сайта. Очевидно, что преимуществом данного уровня детализации является сильно сокращённый объём данных, но, как и в случае с любой агрегированной таблицей фактов, вы подавляете некоторые измерения, описывающие поведение, такие как "Посетитель" и "Диагностика сессии".

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

По этой теме можно также почитать:


Для удобства отслеживания новых публикаций на сайте рекомендую подписаться на рассылку или подписаться на канал RSS.

Если вы нашли в сети интересные ссылки на ресурсы по технологиям хранилищ данных, OLAP, CRM или data mining, и хотите поделиться ими с другими, присылайте их. Я с удовольствием размещу их на этом сайте.

 

Популярные страницы:

Советы разработчику хранилищ данных

OLAP

Моделирование

Книги

Книги на русском языке

Бесплатные книги

Производители OLAP

CRM

Производители CRM

Управление метаданными

Коллекция ссылок


Найти: на

[ На главную | Книги | Ссылки | Рассылка | Письмо автору | Реклама на сайте ]

© Константин Лисянский, 2001-2008.

SpyLOG Rambler's Top100 Rambler's Top100

Используются технологии uCoz