Часто при общении с другими вебмастерами разговор заходит о посещаемости их серверов. Задав вопрос о среднем количестве посетителей в день или об эффективности поставленной на каком-то сервере ссылки, иногда поражаешься услышанному ответу: "Ну, я точно не знаю - по Рамблеру около 300 человек в день, но он ведь не точный". Или того хуже: "А как это узнать?". Удивительно, но встречаются весьма профессиональные вебмастера, которые ничего не слышали или просто не задумывались о файлах посещений (лог-файлах). С другой стороны даже те, кто их анализирует и извлекает большое количество информации, не подозревают, что информации в них гораздо больше, чем они предполагали. Поэтому я решил рассказать вам о том, что можно и чего нельзя из них извлечь, как можно использовать полученные данные, какие инструменты можно для этого использовать.

Что же такое эти загадочные лог-файлы? Это обыкновенные текстовые файлы, в которые построчно записывается информация о каждом запросе файла у Веб-сервера. Сразу хочу объяснить тем, кто не знает подробностей работы HTTP протокола - для каждого отдельного файла браузер должен сгенерировать отдельный запрос. Представим, что мы запрашиваем HTML страницу, которая содержит пять графических элементов. В этом случае браузер сгенерирует шесть запросов к серверу, и в лог-файле появятся шесть новых строк. Помимо этого сервер помещает в лог-файл информацию и обо всех неудачных запросах, например, к несуществующим документам. То есть, строго говоря, в лог-файл помещается информация обо всех корректных запросах, полученных сервером. Справедливости ради отмечу, что некорректные запросы тоже регистрируются, но в другом файле - файле регистрации ошибок. Небезынтересный технический аспект: запрос регистрируется не в момент его прихода, а только после его полной обработки.

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

Строка лог-файла обычного формата выглядит так:

194.220.198.72 - admin [23/Feb/1999:22:48:05 +0300] "GET /admin/ HTTP/1.0" 200 9059

Все поля записи разделяются пробелами (если значение заключено в двойные кавычки, или в случае с датой в квадратные скобки, то оно воспринимается как одно поле), если значение у поля отсутствует, то ставится дефис.

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

В комбинированном формате в запись добавлены еще два поля - адрес документа, по ссылке с которого попали на этот ресурс и идентификатор программы-клиента (user-agent) (она размещена на двух строках для удобства восприятия, на самом деле это одна строка):

194.220.198.72 - - [23/Feb/1999:22:48:46 +0300] "POST /cgi-bin/hd.cgi HTTP/1.0" 200 293 "http://webclub.ru/" "Mozilla/4.07 [en] (X11; FreeBSD 2.2.8; Nav)"

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

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

Адрес источника запроса

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

Некоторые анализаторы вводят такое понятие, как сессия. Под сессией они подразумевают последовательность запросов с определенного адреса с задержкой между ними не более 20-30 минут. Таким образом, если с одного адреса заходили утром и вечером, то это будет считаться двумя сессиями. Но, в связи со всем вышесказанным, это понятие не корректно. Правда в сервере Apache существует возможность протоколирования сессий с использованием cookies - при первом обращении посетителю выдается cookie, которая сохраняется до следующего перезапуска браузера.

Анализируя поле источника запроса, можно построить три достаточно информативных зависимости:

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

Имя авторизации

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

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

Время

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

Запрос

Поле запроса является основополагающим при анализе посещаемости узла. Как я уже упоминал, сервером регистрируются все запросы к серверу (хиты). Вряд ли вам требуется иметь информацию о запросах к элементам оформления документов (картинкам, звукам, таблицам стилей, файлам с внешними сценариями и т.п.), поэтому при построении большинства отчетов "лишние" записи надо игнорировать. Поэтому многие анализаторы вводят такое понятие, как показы страниц. Вебмастер сам указывает, какие именно файлы считать страницами. В простейшем случае это *.html и *.htm. Далее под хитами мы будем подразумевать именно показы страниц. Перечислим наиболее информативные зависимости, строимые на основе этого поля:

• Количество запросов к странице позволяет судить об относительной популярности одних страниц по сравнению с другими. Это позволяет выявлять непопулярные страницы и уделять им особое внимание.
• Количество запросов к разделу позволяет судить о популярности разделов узла. В общем случае разделом считается каталог первого или второго уровня, т.е. подразумевается, что каждый раздел узла находится в своем каталоге. Некоторые анализаторы помогают более точно разделять области узла на разделы. В этой зависимости есть одна хитрость, о которой надо помнить. Обычно зависимость отражает абсолютное число запросов, пришедшееся на конкретный раздел. Но это не совсем правильно, ведь в одном разделе может быть пять документов, а в другом пятьсот. Поэтому, если для первого раздела количество хитов равно, скажем, двадцати, а для второго - сорока, на самом деле получается, что первый раздел более популярен, чем второй, несмотря на абсолютное превосходство по количеству хитов второго раздела. Поэтому целесообразным является нормализовать зависимость, поделив количество хитов для каждого раздела на количество уникальных страниц в нем. При анализе этой зависимости наиболее важными для вебмастера являются наиболее популярные и наименее популярные разделы. Первые надо развивать более интенсивно, а для вторых прилагать наибольшие усилия, чтобы они стали популярными.
• Интересной разновидностью предыдущей зависимости является количество уникальных хостов для каждого раздела. Она определяется совместным анализом поля запроса с полем адреса. Эта зависимость четко показывает популярность разделов относительно друг друга. Можно пойти еще дальше, анализируя, какой процент посетителей ходит по всем разделам, какой заглядывает только в этот, какие разделы "родственные" и т.д.
• Если на вашем узле реализован какой-либо архив, то небезынтересным для вас будет знать, какие типы файлов пользователи скачивают чаще. Например, вы сможете узнать, какие виды архивов более популярны - ZIP, самораспаковывающиеся или GZIP-ed TAR (широко распространенный формат архивации для UNIX-систем). Может хранение сразу трех типов не оправдано и лишь расходует много места?

Основываясь на понятии сессии, некоторые анализаторы вводят еще несколько понятий: точки входа на узел, точки выхода и пути перемещения посетителей по серверу (тропинки). Пути перемещения строятся на основе информации о порядке просмотра страниц узла посетителем в течение сессии. Полученная информация объединяется по всем пользователям, и наиболее популярные последовательности считаются путями. Нахождение этих точек и путей нужно производить именно на основе адреса и понятия сессии, а не ссылающегося документа, иначе все пути будут состоять из одной-двух страниц, а точками выхода - почти все страницы нижнего уровня. Ведь кнопка браузера "Back" является неотъемлемым и весьма логичным элементом системы навигации узла. В связи с тем, что сессия является расплывчатым понятием, точки входа на узел, точки выхода и пути перемещения тоже являются ненадежными, но все же, при правильном построении и четких настройках, могут дать представление о поведении посетителей на узле, о правильности построения системы навигации.

Код ответа

Как правило, код ответа используется для определения необходимости использования данной записи в анализе, но и сам по себе он используется в нескольких отчетах:

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

Количество переданных байт

Сама по себе информация об объеме переданных данных является скорее ознакомительной, но совместно с другими данными она позволяет выявлять полезные факты:

• Отчет о наиболее активных с точки зрения объема скачанных данных хостах позволяет выявить подозрительных посетителей, особенно, если на вашем узле располагается ценная или продаваемая вами за деньги информация. В свое время именно благодаря этому отчету я выявил факт воровства программы телепередач с моего узла (www.telesputnik.ru). Мало того, что эта информация была весьма ценной т.к. требовала значительных усилий по подготовке, так еще нарушитель скачивал (очевидно, скриптом) программу передач почти каждую секунду, что увеличило трафик почти в два раза.
• При совмещении данных о количестве переданных байт для каждого файла с информацией о фактическом размере файла можно выявить, для каких файлов наиболее часто прерывается передача. Это может означать, что размер этих файлов слишком велик, и надо попытаться уменьшить его - разбить файл на два, если это документ или упаковать в архив, если это какой-то другой файл. Увеличение общего количества таких файлов может означать, что ваш сервер или канал перегружен, и посетители просто не дожидаются окончания и нажимают "Cancel".

Ссылающийся документ

Это поле является наиболее важным при анализе предпринимаемых вами действий по раскрутке узла. В нем содержится URL документа, ссылающегося на данный файл. Это поле содержит прочерк, если посетитель набрал адрес на клавиатуре, выбрал его из закладок или каким то другим образом самостоятельно ввел его. При анализе данного поля надо помнить две вещи:

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

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

При анализе этого поля интересными будут следующие зависимости:

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

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

Идентификатор программы-клиента

За корректность информации в этом поле ответственность также несет браузер. Поэтому, как и в предыдущем случае, в нем могут появляться весьма странные, иногда очень веселые записи. Связано это с тем, что значение этого поля очень часто может менять владелец программы-клиента - ваш посетитель. Анализ этого поля позволяет осуществлять техническое развитие вашего узла в правильном направлении:

• Анализ версий используемых браузеров позволит решить вопрос об использовании различных новых технологий на вашем узле, таких как DHTML, Flash и Java. Анализ соотношения производителей браузеров позволит оценить необходимость создания совместимой разметки и кода. Понятно, что такой анализ надо производить до, а не после введения новшеств.
• Анализируя используемые посетителями платформы, вы можете понять, необходимо ли настраивать автоматическую перекодировку, какие шрифты и графику какой сложности использовать. Известно, что на Маке могут возникнуть сложности с жестко прописанными шрифтами, а под Unix чаще работают с низкой глубиной цвета.
• Достаточно полезной будет также информация о том, как давно ваш узел индексировался популярными поисковыми системами и сколько документов при этом было ими просмотрено. Если какая-то поисковая система "забыла" про вас, вы это сразу заметите и сможете зарегистрировать в ней ваш узел еще раз.
• Информация об активности клиентов, целиком скачивающих ваш узел поможет определить момент, когда пора вводить дополнительные возможности получения материалов. Это могут быть специально подготовленные архивы материалов или облегченные версии документов, специально подготовленные для печати из браузера.