Ошибка: Failed to parse the Currency Converter XML document.
$1 690.15
|
Ошибка: Failed to parse the Currency Converter XML document.
$3 807.23
|
Ошибка: Failed to parse the Currency Converter XML document.
$1 852.58
|
Сбор статистики вебмастером
Рано или поздно каждому вебмастеру приходит в голову идея подсчитать статистику посещений своего сайта. В простых случаях вполне хватает использования «внешних» служб таких, например, как Rambler или Rax, но при развитии сайта их возможностей очень быстро становится недостаточно. Разумеется, коммерческий сайт волне может (и чаще всего так и делает!) воспользоваться коммерческими же сервисами или купить модуль статистики от «Битрикс». А всем остальным остается только писать скрипты для обсчета статистики самостоятельно, тем более что часто это бывает проще, чем адаптировать чужой скрипт к своим потребностям...
Cначала немного о том, зачем нужна статистика. Как правило, вебмастера интересует общее количество посетителей, которые ходят на его сайт, и количество страниц, которые они смотрят это позволяет оценить популярность своего сайта и сравнить ее с конкурентами. Интересует также посещаемость разных разделов сайта и отдельных страниц из этих разделов это дает возможность планировать рекламные кампании. Интересует количество постоянных и новых посетителей сайта динамика этих цифр позволяет понять, правильно ли вы делаете то, что делаете. Интересуют всяческие подробности, вроде браузера, которым посетитель пользуется, операционной системы и тому подобного это позволяет в первую очередь оптимизировать сайт для наиболее популярных сочетаний. Интересует распределение количества посетителей по времени суток позволяет проводить служебные и ресурсоемкие действия в наименее напряженное время. Интересует, откуда посетители приходят. А также, возможно, различные дополнительные параметры, специфичные для каждого сайта.
Работу со статистикой сайта можно довольно легко разбить на три этапа: сбор данных о посетителе, анализ собранных данных и отображение статистической информации. У каждого из этих этапов есть свои тонкости, сложности и хитрости, при этом, чем более точные данные вы хотите получать, тем с большим количеством этих тонкостей и хитростей сталкиваетесь. Более того пожалуй, невозможно описать процесс создания идеальной статистической системы слишком уж выйдет громоздко и даже неработоспособно... Так что в этой статье мы ограничимся наиболее часто встречающимися вопросами.
Сбор данных
Основным источником данных о посетителе являются переменные окружения, которые сервер делает доступными для ваших скриптов. В PHP эти данные можно найти в массиве $_SERVER, в Perl посмотреть $ENV. Некоторую дополнительную информацию можно получить, если оформить счетчик в виде кода на JavaScript (по этой технологии работает большинство «внешних» счетчиков), впрочем, как правило эта информация вебмастеру не очень нужна.
Основной сложностью, которая встает перед вебмастером, является необходимость идентификации пользователя, чтобы как-то отличать новых посетителей от постоянных. Просто использовать IP-адрес недостаточно, так как довольно большое количество пользователей приходят через прокси, особенно из больших корпоративных сетей. Использование сочетания IP-адреса и поля HTTP_X_FORWARDED_FOR дает более правильные результаты, но не помогает, если посетитель использует динамический IP-адрес или находится за анонимным прокси-сервером. Запись идентификатора в cookie браузера позволяет еще более уточнить данные, но тоже не является панацеей cookie могут быть отключены или заблокированы какой-то программой. Таким образом, точно посчитать количество посетителей сайта не представляется возможным, но при использовании сочетания всех трех полей данные получаются достаточно приемлемыми.
После того как вы отобрали те переменные, которые собираетесь потом анализировать (и, возможно, провели какую-то предварительную обработку этих данных), их надо сохранить. Практика показывает, что пересчитывать статистику при каждом заходе посетителя на страницу не стоит это значительно загружает сервер и резко снижает достоверность результатов: например, если пользователь, недогрузив страницу, ее перезагрузит, то засчитаются два показа, хотя правильнее считать один.
Статические сайты в качестве источника данных для последующего анализа часто могут использовать access-log сервера, но для динамических это, как правило, неприемлемо, поскольку один и тот же скрипт может выводить разные данные в замисимости от множества параметров. Поэтому проще сформировать запись о посещении и сохранить ее самостоятельно для этой цели можно использовать базу данных или обычный файл в зависимости от ваших предпочтений и возможностей. Следует только учесть, что логи имеют свойство расти очень быстро, и предусмотреть их своевременную очистку. Практика показывает, что большинству сайтов хранение детальных логов в течение длительного времени не требуется, так что можно их достаточно безболезненно удалять, скажем, через месяц или неделю, а хранить только уже обработанные и сгруппированные результаты.
Обработка данных
При обработке данных следует учитывать, что чем больший период вы анализируете, тем точнее получаются результаты. Но, в то же время, обработка большого количества данных требует больше ресурсов и времени. Достаточно хорошо зарекомендовал себя следующий подход: периодически (скажем, каждые 10 минут или раз в час) запускается «грубый» подсчет статистики, который обрабатывает данные за время, прошедшее с предыдущего запуска и суммирует результаты с другими «грубыми» подсчетами. А раз в сутки (обычно ночью, когда загрузка сервера минимальная) запускается «правильный» скрипт, который обрабатывает данные за прошедшие сутки, сохраняет полученные результаты и удаляет старые данные из логов.
Типичными проблемами, возникающими при подсчете статистики, являются защита от накруток и организация хранения данных.
Абсолютно идеальных методов защиты от накруток не существует каждый придумывает что-то свое и держит алгоритм проверки в секрете иначе «злоумышленники» найдут способ его обойти. Но в качестве самой базовой меры можно предложить следующее: сгруппируйте данные по каждой странице, а потом отсортируйте их по посетителям и по времени. Таким образом, в списке будут видны посещения страницы каждым посетителем. Теперь, задав какой-то интервал времени (скажем, вряд ли пользователь возвращается на одну и ту же страницу каждые две минуты), вы сможете достаточно легко отсечь накрутчиков (только смотреть надо время с предыдущего посещения, а не с первого). Можно также отслеживать и резкие пики посещаемости, только при этом надо разобраться в причине вполне возможно, что какой-то популярный сайт поставил на вас ссылку...
Еще одной задачей, похожей на вычисление накруток, является выявление поисковых серверов и прочих роботов и анализ их деятельности. Для выявления большинства поисковых серверов можно использовать переменную USER_AGENT, а также диапазоны IP-адресов, этими серверами использующиеся. Всевозможные утилиты для автоматического скачивания сайтов вычислить сложнее (они обычно маскируются под «честный» браузер), но тоже можно например, по частоте обращений к сайту (ни один пользователь не читает по несколько страниц в секунду), по количеству просмотренных страниц и так далее.
Теперь осталось сохранить результаты. На первый взгляд ничего сложного. Но, как уже говорилось выше, статистика набирается постоянно, а выборка данных из какой-нибудь гигантской таблицы может весьма заметно загрузить даже мощный сервер баз данных. Проблемой это становится, правда, только для сравнительно больших сайтов, которым надо отслеживать статистику множества страниц. Например, программному архиву приходится вести статистику посещений и скачиваний каждой программы, а программ этих тысячи и тысячи... Выход здесь один группировка. Вместо того чтобы хранить все данные в одной таблице, можно эти таблицы создавать по необходимости скажем, на каждый месяц или неделю делается своя таблица со сводными данными. Ну и, разумеется, индексирование получившихся таблиц: так как статистические данные не изменяются со временем, то вы вполне можете создать множество индексов для каждой из них, оптимизировать физическое расположение таблиц и индексов на диске и больше о них не беспокоиться, зная, что скорость доступа и так будет максимальной...
Отображение результатов
Здесь у вебмастера большой простор для фантазии. Когда данные есть, метод показа их посетителю является, скорее, задачей дизайнера. Чтение подготовленных данных из базы тоже много времени не занимает, так что вполне безболезненно можно читать «грубые» данные из предыдущего пункта «на лету» и показывать их посетителю. Но если нагрузка на ваш сервер достаточно высока, то более эффективным методом будет запись результатов в файл (текстовый или графический) сразу после подсчета и включение этого файла в страницу. Веб-сервера изначально разрабатывались для работы со статичными файлами, и все механизмы кеширования файлов у них уже прошли многолетнюю обкатку.
Дополнительное замечание
Наверняка вы хорошо знаете, что такое дефрагментация дисков и зачем она нужна. Когда вы работаете с базами данных, их тоже надо периодически «дефрагментировать», причем тем чаще, чем активнее изменяются данные. А так как запись данных в лог и пересчет статистики на сайте происходят постоянно, то и «фрагментируются» эти таблицы активнее всего. В разных СУБД предусмотрены разные механизмы сжатия баз где-то оно происходит автоматически, где-то вам надо отдать специальную команду, так что очень внимательно почитайте документацию по этому поводу...