Особенности национальной интернет-статистики. Часть 2

В очередной раз приходится писать статью об интернет-статистике, и в очередной раз задаю себе вопрос: «А какой она должна быть, эта статистика? Что бы удовлетворило даже самого требовательного пользователя?Л Просто хосты и хиты отображать явно недостаточно – это даже не вчерашний день российской статистики, а позавчерашний. Так какой же мы видим статистику сегодняшнюю, и какой мы хотим ее видеть завтра?

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

Итак, что же мы имеем в большинстве счетчиков? Безусловно, у нас есть статистика хостов/хитов на каждом из них. Есть реферер, то есть ссылающаяся страница – очень важная информация при выборе и анализе эффективности рекламных площадок, где вы размещаете свои баннеры. В большинстве (если не у всех) счетчиков есть информация о путях посетителя по сайту – начиная с точки входа и до последней страницы. Это осуществляется с помощью cookie, который устанавливается JavaScript'ом на вашем компьютере и служит вашим уникальным идентификатором для данного счетчика. Это cookie, или кукис и послужит источником информации о количестве уникальных посетителей на сайте, или же хостов. Этот же JavaScript «вытягиваетЛ информацию о цветности и разрешении экрана. Но если на браузере посетителя запрещены кукисы, то он попросту останется неучтенным. Также на браузере может быть отключена поддержка JavaScript – еще один источник неточности. Наличие же нескольких разн ы х браузеров у одного пользователя еще больше запутывает ситуацию.

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

Немногие счетчики показывают визиты роботов – фактор очень важный при раскрутке нового ресурса – в силу того, что это трудно осуществить технически. Как правило, робот не загружает изображений, то есть не вытягивает счетчики и, соответственно, не учитывается в статистике. Изображения же для Google Images или Яндексовского Поиска Картинок индексируются отдельно. Однако эта функция присутствует в лог-анализаторах. Так, распознавание роботов хорошо реализовано в программе Log Analyzer от компании NetPromoter. Программа изначально была рассчитана на распознавание только роботов, потом переросла в достаточно мощный полноценный лог-анализатор с более чем 180 пользовательскими агентами роботов в базе данных.

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

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

Теперь о лог-анализаторах. Тут все одновременно и проще и сложнее. Начнем с того, что серверные логи фиксируют всю информацию – будь то визит поискового робота, загрузка мультимедийного/ Flash / Java / Exe файла, вытягивание отдельной картинки с сервера (ох, блоггеры это любят!), и вообще позволяют вести учет трафика. Можно получать коды доступов к страницам, что невозможно учесть счетчиком (если только у вас нет кастомизированной 404-ой страницы). При наличии хорошего лог-анализатора с гибкой системой отчетов веб-мастер выудит всю нужную для себя информацию. Но… Возникает опять-таки проблема с диалапщиками. При каждом коннекте пользователю присваивается новый IP-адрес, и сервер, а следовательно, и лог-анализатор будут интерпретировать его как нового уникального посетителя, а это не так. Эта проблема решена счетчиками в виде вышеупомянутых куки, но в лог-файлах куки не фиксируются никак. Далее. Как известно, в больших офисах, как правило, пользователи выходят в Интернет через прокси-сервер, который присваивает одинаковый IP-адрес всем пользователям. То есть, теоретически, даже если в корпорации работает 100 человек, и десять из них (представим себе) зайдут на ваш сайт, то сервер зафиксирует их как одного посетителя. Если вы ориентируетесь на корпоративного клиента, то погрешность получается весьма ощутимая. Кроме того, прокси-сервера, как правило, кешируют содержимое запрошенных страниц, а следовательно, все последующие пользователи, которые сидят за прокси, получают, по сути одну и туже версию страницы.

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

Давайте же представим идеальную систему подсчета. Как она должна выглядеть? Представьте себе, вы устанавливаете у себя на сайте свой собственный счетчик, который вызывается с вашего же сервера. Полученная статистика фиксируется специализированной программой. То есть, вы сами себе HotLog или SpyLOG. Но этого по условию задачи недостаточно – ведь у нас остаются незадействованными логи с их преимуществами. Эта же программа является лог-анализатором и обрабатывает как статистику со счетчика, так и информацию, зафиксированную в логах. Конечно, такую систему намного проще себе представить, если у вас есть свой собственный сервер и вы имеете полные администраторские права. Если же вы покупаете хостинг, это может повлечь за собой некоторые проблемы – так не все провайдеры предоставляют доступ к логам – но это вопрос скорее выбора провайдера. Возникает еще одна проблема – насколько будет высоко доверие рекламодателей к такой статистике, ведь известно, что данными счетчиков определяется цена рекламы на вашем сайте. Где гарантия, что вы не накручиваете свою статистику?

Тем не менее, пока, поскольку таких систем нет, приходится комбинировать два вида сбора статистики и находить середину. К сожалению, показания счетчиков и лог-анализаторов могут различаться в десятки раз. Более того, показания счетчиков могут различаться в несколько раз – так, сравните показания, скажем, HotLog и достаточно популярного британского Nedstat – на последнем, как правило, вы получаете данные посещаемости чуть ли не на порядок большие. Правда, компания заявляет, что она решила проблему с учетом кешированных страниц, но вряд ли такая разница может возникать только на этом. Определить же какая система более правдивая достаточно сложно.