Маркетинговые отделы любят статистику сайта. Нет ничего лучше, чем передать генеральному директору недавно сгенерированный отчет, показывающий, как растет трафик их веб-сайта. Вот когда начинаются проблемы.
Многие люди ошибочно полагают, что веб-статистика абсолютно неопровержима: цифры генерируются независимыми компьютерами и не могут ошибаться. Так почему статистика из двух или более источников редко совпадает? Чтобы понять проблему, нам нужно изучить два метода, используемых для сопоставления и анализа статистики. Сегодня мы рассмотрим методы на стороне сервера …
Сбор и анализ данных на стороне сервера
Каждый раз, когда вы посещаете веб-сайт, веб-сервер записывает информацию о каждом запросе файла, то есть файле HTML, файлах CSS, файлах JavaScript, графических файлах, флэш-фильмах, документах PDF, музыке MP3 и т. Д. Реализации отличаются, но большинство серверов записывают каждый запрос в одной строке файла журнала. Данные обычно включают в себя:
- тип запроса — обычно GET или POST
- полный путь к запрашиваемому файлу
- дата и время
- IP-адрес запрашивающей стороны и
- пользовательский агент запрашивающей стороны; строка символов, которая идентифицирует устройство, то есть определенную ОС и браузер или бот поисковой системы.
Понятно, что файлы журналов могут расти до сотен мегабайт даже на относительно тихих веб-сайтах.
Основным преимуществом сбора данных на сервере является то, что он записывает каждый запрос файла независимо от используемой технологии. Легко оценить популярность загрузок или обнаружить узкие места в производительности. Большинство серверов создают файлы журналов по умолчанию, поэтому возможно получить доступ к исторической информации о росте трафика.
К сожалению, есть ряд недостатков:
- Очень мало можно определить относительно устройства просмотра пользователя. Строки пользовательского агента предлагают минимальную информацию и могут быть подделаны (Opera раньше притворялась IE, чтобы сайты не блокировали браузер). Обычно вы не можете оценить параметры разрешения экрана пользователя или включить JavaScript и Flash.
- Крупные организации часто пропускают все интернет-запросы через один шлюз. Идентификация пользователя становится трудной, когда два или более пользователей используют один и тот же IP-адрес и строку агента пользователя.
- Журналы сервера не могут записывать кэшированные файлы. Кэширование имеет важное значение, и Интернет остановился бы без него. Ваш браузер будет кэшировать файлы, поэтому, когда вы вернетесь на страницу, он покажет файлы, которые были загружены ранее.
Кроме того, многие провайдеры кэшируют файлы популярных веб-сайтов на прокси-серверах. Когда вы вводите веб-адрес, вы можете видеть файлы, возвращенные с этого прокси, а не с исходного сайта. По мере роста популярности вашего сайта вы можете даже столкнуться с падением доступа к файлам, поскольку все больше прокси-серверов кэшируют ваш сайт.
Такие приложения, как AWstats, могут анализировать файлы журналов сервера для получения значимых цифр, таких как количество уникальных пользователей или посещений. Однако эти приложения должны делать предположения, когда они интерпретируют данные.
Например, приложение может определить один «сеанс посетителя» как доступ с того же IP / агента пользователя в течение того же 15-минутного периода. Пользователь, который посещает страницу, затем ждет 16 минут, прежде чем щелкнуть ссылку в другом месте, будет записан как две отдельные сессии посетителя. Но приложение, которое предполагало 20-минутный период бездействия, будет записывать только один сеанс посетителя.
Если сбор и анализ данных на стороне сервера некорректен, могут ли методы на стороне клиента помочь нам? Посмотреть часть 2 сейчас …