GIGO (Garbage In, Garbage Out - “мусор на входе -мусор на выходе” [5]См. http://ru.wikipedia.org/wiki/GIGO — Примеч. ред.
) был одним из самых ранних акронимов, появившихся в области PC. Качество на выходе было неразрывно связано с качеством на входе. С тех пор компьютеры стали намного интеллектуальней и иногда способны сделать нечто умное даже с мусором на входе, но чтобы получить нечто полезное, лучше на входе мусора не иметь.

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

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

Концепция ландшафта данных

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

• Существует множество способов получения информации о взаимодействии клиента с веб-сайтами. Есть файлы веб-журнала, веб-маяки (web beacon), дескрипторы JavaScript и анализаторы пакета (packet sniffer). Некоторое передовое программное обеспечение электронной торговли, например от компании ATG, может также задействовать для сбора данных о важных деловых событиях встроенные механизмы, такие как регистрация событий.

• Ряд механизмов сбора данных используют принцип “откажись, и пожалеешь” (пропусти дескриптор JavaScript на странице, и данные пропали).

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

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

• Для выработки эффективных решений могут понадобиться и другие источники данных: сведения о результативности веб-сайта (чтобы измерить реальную успешность), различные типы качественных данных, включая опросы или исследование применимости, необходимое для понимания поведения клиента, а также информация из других источников компании, включая систему CRM и систему планирования ресурсов предприятия (Enterprise Resource Planning — ERP).

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

• И наконец, но не в последнюю очередь, — приватность. По мере установки механизмов сбора данных этот вопрос приобретает первостепенную важность. Следует удостовериться в совершенно четком понимании значения фиксируемых веб-данных. Клиентам необходимо ясно и доступно объяснить, какие именно данные фиксируются. Нужно быть предельно осторожным, нельзя собирать личную информацию (Personally Identifiable Information — PII), но если это необходимо, клиента следует честно уведомить об этом. Удостоверьтесь, что применяемые средства сбора и хранения данных, а также механизмы их обработки соответствуют установленным стандартам. Настоятельно рекомендуется проводить периодический контроль защиты полученных и хранимых данных (как у их поставщика, так и в компании). Это может показаться паранойей, но однажды главный директор по маркетингу (Chief Marketing Officer — CMO) откровенно сказал автору: “Если произойдет малейшая утечка информации или появится статья в газете, или крошечная кража данных о нашей веб-операции, все сгорит синим пламенем.” Сегодня клиенты больше, чем когда-либо заботятся о своей приватности, поэтому со своей стороны необходимо сделать все для обеспечения защиты данных клиента и сохранения его доверия.

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

Правильно отобрав собираемые данные, вполне можно ошибиться с исполнителем. Обратного почти никогда не случается.

Данные анализа посещаемости сайта

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

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

Веб-журналы

Вебжурналы (Web log) были первоначальным источником для сбора данных на заре веб. Изначально они задумывались лишь для фиксации информации об ошибках на веб-серверах, но со временем были “расширены”, чтобы фиксировать большее количество данных, применимых и для аналитических потребностей. Так из чисто технического средства они превратились в том числе и в маркетинговое.

На рис. 2.1 приведен пример схемы фиксации данных в веб-журналах.

Рис. 2.1. Как веб-журналы фиксируют данные

Процесс сбора протекает следующим образом:

1. Клиент вводит URL в браузере.

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

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

4. Веб-сервер посылает страницу клиенту.

Как правило, веб-журналы снимают с сервера по расписанию (обычно ночью). Их можно передать стандартному инструменту анализа журнала или инструменту веб-анализа, чтобы получить типичные отчеты.

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

• Веб-журналы, — вероятно, наиболее легкодоступный источник информации. Каждый веб-сервер обладает простым встроенным механизмом сбора данных и создания веб-журнала. Данные собираются независимо от того, используются они или нет.

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

• Веб-журналы — единственный механизм сбора данных, способный фиксировать и хранить информацию о посещениях и поведении роботов поисковых систем на веб-сайте. Последние не выполняют дескрипторы JavaScript, а следовательно, не оставляют никаких следов для других механизмов сбора данных. Так, при необходимости проанализировать посещения роботами таких поисковых систем, как Google, MSN (Microsoft Network — сеть Microsoft), Yahoo и других, чтобы удостовериться в просмотре и правильности индексирования ими веб-сайта, придется использовать веб-журналы.

• При использовании веб-журналов данными располагает сам владелец веб-сайта. При большинстве других методик информацию будет фиксировать, обрабатывать и хранить исполнитель веб-анализа (web analytics vendor), под которым обычно подразумевают провайдера служб приложений (Application Service Provider — ASP). Веб-журналами владеет хозяин сайта, он же хранит их; это позволяет без проблем сменить исполнителя веб-анализа, перепроверить данные самостоятельно, а также при необходимости вернуться к прежним данным и обработать их новым инструментом.

Недостатки использования веб-журналов в качестве механизма сбора данных

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

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

• Если веб-сервер не устанавливает файлы cookie, идентификация посетителей с любой степенью точности крайне сомнительна.

• Веб-журналы создавались для фиксации всех обращений к серверу. Следовательно, при их использовании для получения точных тенденций трафика и поведения необходимо правильно отфильтровать запросы изображений, ошибки загрузки страниц, трафик роботов, запросы файлов каскадных таблиц стилей (Cascading Style Sheet — CSS) и т.д.

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

Рекомендация

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

Веб-маяки

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

Веб-маяки — это обычно прозрачные изображения размером 1x1 пиксель, которые помещают на веб-страницу при помощи дескриптора HTML img src. Прозрачные изображения, как правило, находятся на сервере стороннего исполнителя, отличном от сервера, содержащего веб-страницу.

Рис. 2.2 демонстрирует, как веб-маяки фиксируют данные.

Процесс протекает следующим образом:

1. Клиент вводит URL в браузере.

2. Запрос страницы поступает на один из веб-серверов.

Рис. 2.2. Как веб-маяки фиксируют данные

3. Веб-сервер посылает страницу клиенту наряду с запросом прозрачного изображения размером 1 х 1 пиксель, которое находится на сервере стороннего исполнителя.

4. При загрузке страницы она запрашивает изображение размером 1 х 1 пиксель, оповещая таким образом стороннего исполнителя о просмотре страницы.

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

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

Преимущества использования веб-маяков в качестве механизма сбора данных

• Веб-маяки легко реализуемы (в большинстве случаев), поскольку они представляют собой лишь пару строк кода в оболочке дескриптора HTML img src. Весь “интеллект”, ответственный за сбор возвращаемых данных, сосредоточен на том сервере, который получает запрос изображения.

• Существует возможность точно указать, какие данные собирает маяк (например, только о просмотре страниц или включая время, значения файлов cookie, или даже реферрер), а поскольку роботы запросов изображений не выполняют, сбор нежелательных данных исключен. Это позволит поддерживать размер журнала в контролируемых пределах и не потребует сложной фильтрации.

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

Рис. 2.3. Фиксация тех же данных, что и на рис. 2.2, но для двух сайтов (avinashk.net и kaushik.net)

Недостатки использования веб-маяков в качестве механизма сбора данных

• Маяки обычно ассоциируются с рекламой в Сети, а следовательно, имеют слегка подмоченную репутацию. Уже немало писалось о значении приватности при отслеживании поведения одного человека на нескольких сайтах. В результате большинство посетителей решительно отказались от получения рекламной рассылки по электронной почте, а многие установили программу AntiSpyware, автоматически удаляющую файлы cookie, что серьезно препятствует возможности сбора данных.

• Если у пользователя отключены запросы изображений в программе электронной почты (как это все чаще делается по умолчанию в таких программах, как Microsoft Office Outlook и Gmail от Google) или браузере, то собрать данные о нем будет невозможно.

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

• По своей природе маяки взаимодействуют с серверами стороннего производителя и, главным образом, устанавливают файлы cookie последнего. Они подвержены также все более и более строгим ограничениям безопасности, вследствие чего браузеры (типа Internet Explorer) или не будут принимать их совсем или не будут предъявлять файлы cookie стороннего исполнителя. Система защиты AntiSpyware также удаляет файлы cookie стороннего исполнителя, тем самым существенно усложняя отслеживание повторных посещений и, в свою очередь, выяснение точного поведения клиента.

Рекомендация

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

Дескрипторы JavaScript

На сегодняшний день дескрипторы JavaScript (JavaScript tagging), вероятно, наиболее предпочтительный метод в отрасли. Большинство производителей и решений веб-аналитики полагаются при сборе данных именно на них.

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

Теперь веб-страницы могли покидать сервер компании без необходимости фиксации данных и предоставляться посетителям веб-сайта. Информация о сеансе посетителя, в свою очередь, фиксируется на других серверах (обычно серверах сторонних исполнителей веб-аналитики), обрабатывается там и предоставляется в виде отчета, доступного по Сети.

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

Но сначала давайте вспомним, как работают дескрипторы (рис. 2.4).

Процесс протекает следующим образом:

1. Клиент вводит URL в браузере.

2. Запрос страницы поступает на один из веб-серверов.

3. Веб-сервер отсылает страницу вместе с фрагментом кода JavaScript, присоединенного к ней.

Рис. 2.4. Как осуществляется сбор данных дескрипторами JavaScript

4. При загрузке страницы этот код JavaScript выполняется, фиксируя просмотр страницы, подробности сеанса посетителя, файлы cookie, и посылает все это на сервер сбора данных.

5. В некоторых случаях после получения первого набора данных сервер посылает браузеру дополнительный код, чтобы установить дополнительные файлы cookie или собрать больше данных.

Хотя согласно рис. 2.4 данные фиксируются на серверах стороннего исполнителя, несколько компаний (включая ClickTracks и WebTrends) предоставляют решения их сбора на базе JavaScript. Если пойти по этому пути, то данные можно фиксировать и хранить внутри собственной компании, получив больше контроля над политикой безопасности и установкой файлов cookie при сохранении собственности на данные. Одним из преимуществ наличия внутреннего решения JavaScript является существенное упрощение интеграции данных из других источников компании в решение вебаналитики, поскольку это можно сделать самостоятельно, не заботясь об опасности передачи секретных данных компании в чужие руки.

Преимущества использования дескрипторов JavaScript в качестве механизма сбора данных

• Эта методика требует, возможно, наименьших усилий по реализации после вебжурналов. Добавления нескольких стандартных строк кода JavaScript в глобальный элемент сайта (например, нижний колонтитул) оказывается вполне достаточным для всего сайта, и буквально через 30 минут можно получить массивы данных и стандартных отчетов.

• При отсутствии непосредственного доступа к самим веб-серверам (технически) или журналам веб-сервера применение дескрипторов JavaScript — единственный выбор. Дескрипторы на страницах можно легко установить самостоятельно, а для формирования отчетов использовать провайдера ASP. Этот подход особенно хорош для малого и среднего бизнеса.

• Кеширование страниц либо локально на компьютере посетителя, либо на фермах кеширования, таких как Akamai Technologies, не проблема для дескрипторов JavaScript (в отличие от веб-журналов). Независимо от того, откуда загружается веб-страница, дескриптор JavaScript выполняется, и инструмент веб-аналитики будет способен собрать данные.

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

• Применение дескрипторов JavaScript позволяет разделить сбор данных и их обслуживание. При использовании дескрипторов JavaScript выпуск сайта происходит немного быстрее, поскольку отдел информационных технологий не должен ничего проверять, кроме установки дескриптора на странице. (Ответственность за сбор данных теперь несет исполнитель.) Больше не придется беспокоить отдел информационных технологий, чтобы установить файлы cookie или отследить сеансы, теперь инструмент аналитики способен это сделать сам.

• Большинство новшеств разработчиков (новые возможности, усовершенствование сбора данных и т.д.) относятся к методике JavaScript. Большинство производителей перестало активно улучшать свои инструменты в версии для веб-журналов, а многие даже не предоставляют такие версии.

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

Недостатки использования дескрипторов JavaScript в качестве механизма сбора данных

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

• Данные, собираемые при помощи дескрипторов JavaScript, отделены от других метаданных. Следовательно, практически неизбежно понадобится более тщательное обдумывание и планирование при создании дескриптора, который будет фиксировать таксономию сайта и его иерархию с учетом оптимальности анализа. По мере развития сайта это может превратиться в напряженный процесс, требующий регулярного обслуживания.

• Сбор данных при помощи дескрипторов JavaScript базируется на “стороне браузера”, а не на “стороне сервера”. Некоторые веб-сайты, вместо того чтобы хранить данные в файлах cookie или параметрах URL, хранят их в течение сеанса посетителя на сервере. В таком случае, дескрипторы не зафиксируют существенной информации. Если принятая стратегия подразумевает содержание ключевых данных на сервере, а не в браузере (машине посетителя), то дескрипторы могут не подойти (либо придется пройти процедуру изменения стратегии информационной технологии).

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

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

Рекомендация

Возможность применения дескрипторов JavaScript при сборе данных следует рассмотреть в первую очередь. Большинство новшеств веб-аналитики исходят от тех производителей, которые совершенствуют свои инструменты в области использования дескрипторов JavaScript. Кроме того, их применение может быть оптимальным при необходимости управления собираемыми данными, что позволяет группе аналитики фиксировать именно то, что нужно. Единственное возможное дополнение — это использование веб-журналов для замера оптимизации поисковой системы (Search Engine Optimization — SEO), а также поведения веб-роботов на веб-сайте.

Анализ пакетов

Анализ пакетов (packet sniffing) — один из наиболее технически сложных способов сбора веб-данных. Появившись практически одновременно с другими, эта методика по ряду причин не стала столь же популярной, как другие, описанные в данной главе. Среди производителей, предоставляющих решения веб-аналитики на базе анализа пакетов, следует отметить Clickstream Technologies. Появляются также некоторые интересные способы применения анализаторов пакета, например SiteSpect использует данную технологию для многопараметрической проверки, устраняя необходимость в применении дескрипторов на веб-сайте.

Процесс сбора данных с использованием анализа пакетов представлен на рис. 2.5.

Рис. 2.5. Сбор данных с использованием анализа пакетов

Сбор данных осуществляется в пять этапов.

1. Клиент вводит URL в браузере.

2. Запрос направляется на веб-сервер, но прежде чем достигнуть его, он проходит через программный или аппаратный анализатор пакетов, который может фиксировать атрибуты запроса и другие данные о посетителе.

3. Анализатор пакетов пересылает запрос на веб-сервер.

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

5. Анализатор пакетов пересылает страницу браузеру посетителя.

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

Преимущества использования анализаторов пакетов в качестве механизма сбора данных

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

• Время подготовки немного больше, чем при применении дескрипторов JavaScript, в связи с необходимостью одобрения группой информационных технологий,

Стр. 59

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

• Возможность немедленно собрать огромное количество данных, гораздо большее, чем при помощи стандартных дескрипторов JavaScript. Например, можно выявить ошибки сервера, степень использования пропускной способности, любую техническую информацию, связанную со страницей, а также деловые данные. Об анализе пакетов зачастую говорят, что он позволяет собрать наиболее исчерпывающий объем данных из когда-либо возможных (все 0 и 1!).

• С учетом характера решений остается возможность использовать файлы cookie и другие элементы по назначению.

Недостатки использования анализаторов пакетов в качестве механизма сбора данных

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

• Не забывайте, происходит сбор необработанных пакетов трафика веб-сервера Интернета. В результате возникает две важные проблемы: отнюдь не тривиальные объемы работ по конфигурации решения анализатора пакетов, чтобы он исследовал только необходимые данные из всех доступных, и вторая проблема — безопасность. Необработанные пакеты позволяют фиксировать все данные, включая такие как пароли, имена, адреса и номера кредитных карточек. В результате необходима очень осторожная стресс-проверка и корректность опросов. Но, с другой стороны, применение дескрипторов JavaScript для дополнения анализаторов пакетов привело бы к проблемам, описанным ранее.

• При использовании большинства решений анализа пакетов для правильного сбора всех данных, необходимых при оптимальном анализе, все равно понадобятся дескрипторы JavaScript. Например, без них анализатор пакетов не получил бы никаких данных о кэшируемых страницах (поскольку в этом случае на веб-сервер никаких запросов не поступает). Добавим сюда и невозможность получения данных от файлов Adobe Flash, Ajax и улучшенных приложений Интернета (Rich Internet Application — RIA): эти глубоко автономные файлы поступают на браузер посетителя, и большая часть взаимодействия с ним происходит там, а следовательно, не отмечается традиционным анализатором пакетов (поскольку ресурс улучшенного взаимодействия не передает никаких запросов на сервер), а еще неспособность собрать информацию о базовой структуре и метаданных страниц при помощи исключительно внедрения анализатора пакетов.

• При наличии множества веб-серверов или веб-серверов в нескольких сетях (что нередкость) анализ пакетов может оказаться довольно дорогим. В этих случаях приходится устанавливать программное обеспечение или аппаратные средства во всех сетях.

Рекомендация

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

Замечания по поводу механизмов сбора данных

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

Собственные файлы cookie или файлы cookie стороннего производителя

Большинство исполнителей устанавливают свои файлы cookie (т.е. файлы cookie стороннего производителя), хотя компании практически всегда предпочтительней использовать файлы cookie собственного домена. Это справедливо по многим причинам, не последними из которых является преодоление защиты и программного обеспечения AntiSpyware.

Собственность на данные

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

Время на последней странице

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

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

Все механизмы сбора данных ненадежны и несовершенны

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

Клиенты в первую очередь

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

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

Стоимость

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

Ныне большинство исполнителей ориентировано на ASP, а следовательно, используют схему регулярных платежей. Они производят начисления на основании “просмотра страниц” (важно заранее определить, что он собой представляет, поскольку разные исполнители трактуют это по-разному). Это означает, что с ростом популярности веб-сайта платить придется больше, что вполне справедливо, поскольку исполнитель должен содержать дополнительные аппаратные средства и платить за все издержки, связанные с анализом увеличивающихся объемов данных.

Решения на основании веб-журналов и дескрипторов JavaScript внутреннего применения (например, от ClickTracks и WebTrends) подразумевают одноразовую оплату. Заплатить необходимо только разовый взнос за программное обеспечение и стандартную цену за поддержку. Затем, после первого года, фактические издержки снижаются. Некоторые компании уже имеют стандартные веб-серверы, которые по стоимости сравнимы с аппаратными средствами.

Теперь можно решать, какая модель обойдется компании дешевле, — внутренняя модель позволяет иметь множество веб-сайтов с дескрипторами безо всякой дополнительной оплаты.

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

Почему данные не согласуются

При смене исполнителя или метода сбора данных либо просто при использовании нескольких методов

(например, веб-журналов и дескрипторов) неизбежно сталкиваешься с жутким фактом — противоречиями

в получаемых значениях. Фактически различия могут достигать 10-15 процентов для того же веб-сайта за тот же

период времени (и хорошо, если разница составит лишь 10 процентов).

Вот пять основных причин, по которым данные могут не согласоваться.

• Каждому инструменту присущи собственный уникальный способ выявления начала и завершения сеанса. Наиболее распространенным признаком завершения сеанса является “29 минут бездеятельности”. Однако некоторые инструменты считают сеанс закрытым, если обнаруживают, что посетитель возвратился к поисковой системе менее чем за 29 минут. Инструмент фиксирует начало нового сеанса. При сравнении данных удостоверьтесь, что все инструменты используют одинаковые параметры сеанса.

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

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

• Сравнивая данные, полученные в результате применения дескрипторов JavaScript, проверьте одну вполне очевидную вещь: все ли веб-страницы фактически содержат дескрипторы (просто удивительно, как часто это оказывается не так).

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

Данные о результатах деятельности

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

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

• посетители (посещения, общее количество, индивидуально);

• просмотр страниц (индивидуально, всего, в среднем);

• время (в целом, в среднем, по секторам);

• реферреры (количество, веб-сайты, ключевые слова, тенденции).

Каждый отчет иллюстрирует один из приведенных выше показателей, или один из них, умноженный, разделенный или вычтенный из другого.

Так что же происходит? (so what happened?) — важнейший вопрос, о котором зачастую забывают во всей круговерти данных. Если все эти люди пришли и посмотрели все эти страницы, проведя столько времени на сайте, то каков результат деятельности (outcome) для клиента или компании?

Вот почему так важно тщательно продумать стратегию сбора данных о результатах деятельности — она должна в первую очередь учитывать вопрос: зачем существует данный веб-сайт?

Ответом на него должен стать не том на 500 страниц, а лишь несколько слов, которые подтверждают право и оправданность существования сайта. Ответ может звучать примерно так:

• заработать для компании как можно больше денег без нанесения вреда клиентам;

• снизить затраты на службу поддержки по телефону за счет улучшения информативности веб-сайта;

• улучшить коэффициент разрешения проблем для большинства клиентов;

• стимулировать популярность обращений к базе данных компании по электронной почте, оказать содействие усилиям отдела сбыта и продвижению новых товаров;

• создавать у клиента впечатление, которое бы укрепило бренд компании и выработало у миллионов людей мнение, что лучше ее нет.

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

В этом разделе рассматривается несколько способов оптимизации стратегии сбора данных о результатах деятельности.

Электронная торговля

Для большинства веб-сайтов электронной торговли сегодня довольно стандартной практикой является использование специальных дескрипторов JavaScript (или анали-

заторов пакетов, или веб-маяков) для сбора данных со страниц подтверждения заказа. Данные, которые фиксируются чаще всего, содержат следующую информацию:

• уникальный идентификатор заказа;

• заказанный товар или услуга;

• количество и цена единицы;

• наличие скидки и продвижения;

• метаданные о сеансе клиента: проверка A/B или многопараметрическая проверка (Multivariate Test — MVT) идентификатора, значения файла cookie и т.д.;

• метаданные о товаре или услуге: иерархия товара и кампании, атрибуты товара (все необходимое для сложного последующего анализа).

Затем эта информация поступает на стандартный инструмент анализа посещаемости сайта, создающий отчеты на основании данных электронной торговли.

Побуждение спроса

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

Защита и поддержка бренда

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

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

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

Такие производители, как Omniture и WebTrends, создали в своих инструментах версии V1 реальную “серверную часть хранилища данных”. В качестве альтернативы многие большие компании предпочитают строить собственные системы хранения данных (рис. 2.6), в которых анализ посещаемости сайта является лишь одним из источников информации. Для секционирования и фрагментации данных эти компании используют стандартное программное обеспечение, а также методики и инструменты бизнес-интеллекта (Business Intelligence — BI) (такие как Brio, Business Objects, Cognos и MicroStrategy).

Наличие собственной системы означает огромную гибкость с точки зрения использования большего количества источников данных (например, журналов событий из приложений Flash или улучшенных приложений Интернета, данных поиска Google, метаданных из других отделов компании, а также данных CRM и телефонных каналов). Это позволяет создать действительно сквозное (end-to-end — e2e) представление поведения клиента и выявить результат деятельности, масштаб эффективности которого со временем может меняться. Можно также использовать имеющиеся в наличии стандартные инструменты.

Рис. 2.6. Так выглядит хранилище данных Web e2e

Исследование данных

В главе 1 обсуждалась необходимость понимания ответа на вопрос что, и колоссальная мощь, которую может дать понимание ответа на вопрос почему. Это может означать различие между большим объемом данных, зачастую лишь вызывающих много вопросов, и наличием доступа к данным, возможно, и небольшого объема, но способным выступить в роли катализатора, когда дело доходит до необходимости принять меры. Сбор данных для анализа рассматривается в разделах “Данные анализа посещаемости сайта” и “Данные о результатах деятельности”. Теперь пришло время выработать стратегию получения данных для ответа на вопрос почему.

Основной целью получения данных для ответа на вопрос “почему” (или качественного анализа) является объяснение показателей и тенденций с учетом голоса клиента (Voice Of the Customer — VOC) в принимаемом решении. Для выявления точки зрения последнего обычно используются следующие методы ориентированного на клиента проектирования (User-Centric Design — UCD) и взаимодействия человека с компьютером (Human-Computer Interaction — HCI):

• опросы;

• эвристические оценки;

• проверка применимости (лабораторная и дистанционная);

• посещаемость сайта.

Экспериментирование и проверка (A/B, многопараметрическая, впечатления) не являются традиционными методикам UCD/HCI, они, скорее, относятся к разделу просто исследования данных, поскольку зачастую предоставляют наиболее быстрый способ проверки гипотезы, сформулированной на основании количественных исследований, и выяснения точки зрения клиента, способной подтвердить или опровергнуть эту гипотезу.

Поскольку преуспеть в данной области критически важно, в главе 3, “Обзор качественных показателей”, каждая методология исследований и стратегий достижения успеха будет рассмотрена подробно.

С исследованием данных связаны три стратегических аспекта: мировоззрение, организационная структура и сроки.

Мировоззрение

Отрасль, традиционно называемая веб-аналитикой, занимается анализом посещаемости сайта и результатов деятельности. Многие полагают, что анализ цифр способен предоставить ответы на все вопросы. Существует огромная проблема мировоззрения — убедить всех “перцев количественного анализа” (“quant jocks”) (вверх и вниз по иерархии управления) осознать значение качественных данных и, что, возможно, важнее всего, начать думать по-другому, поскольку анализ опытных данных (research data) предоставляет совершенно иные возможности и проблемы.

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

Организационная структура

Как правило, исследовательская группа является либо отдельной организацией (подобной традиционной компании по исследованию рынка или общественного мнения), либо субподрядчиком (обычно агентство или консалтинговая компания), либо ее просто не существует. Действие, которое следует предпринять в последнем случае, очевидно: группу следует создать. Но в двух других случаях не все так просто.

Автор рекомендует компаниям иметь собственную веб-исследовательскую группу и содержать ее членов наравне с группой веб-анализа. Объяснение просто: каждая из двух частей по отдельности составляет в сумме полтора, но собрав их воедино, один плюс один равняется четыре. Группа качественного анализа может извлечь пользу из понимания того, что способна предоставить группа количественного анализа, чтобы сосредоточить свои усилия и получить реальное представление о происходящем (иногда исследователи теряют “связь” с реальным миром). Группа количественного анализа может извлекать пользу из тесного взаимодействия с клиентом, выявляя его точку зрения по возможности точнее (независимо от того, используют ли они решение Omniture, WebTrends или Visual Sciences).

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

Сроки

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

Автор рекомендует иметь по крайней мере одну программу непрерывного прослушивания (continuous listening). Обычно изыскивают наиболее эффективный механизм для непрерывного прослушивания, бенчмаркинга и контроля тенденций. Чрезвычайно выгодно использовать для изысканий одного из многих промышленных провайдеров (таких как ForeSee Results или iPerceptions), специализирующихся на выявлении таких критически важных фактов, как причины посещения людьми веб-сайта, коэффициент успешности завершения их задач, степень их удовлетворенности и вероятности покупки в результате посещения веб-сайта, список их предпочтений и многое другое.

Другие методики не относятся к категории непрерывного прослушивания (т.е. они применяются по необходимости или периодически). Наиболее подходящую из них можно выбрать на основании следующего:

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

• сроки (необходимо ли все прямо сейчас или через несколько недель);

• количество участников (от какого количества клиентов хотелось бы получить отзыв);

• бизнес-пожелание (например, до и после запуска сайта, в некоторое произвольное время или на основании внешних обстоятельств).

Хотя каждая методика уникальна, обычно цена растет примерно в следующем порядке: от эвристической оценки к лабораторной проверке применимости, посещаемости сайта и изучению мнения клиентов.

Конкурентные данные

Последняя методика сбора и анализа данных — возможно, один из наиболее эффективных способов получения стратегического преимущества.

Довольно просто объявить о начале празднования успеха (или переживания провала) веб-сайта на основании лишь показателей инструментов веб-анализа (Google Analytics, ClickTracks, IndexTools, HBX или другого). Но если его посетители год за годом добиваются все большего успеха, разве это не прекрасно? Или если коэффициент окупаемости инвестиций (ROI — Return On Investment) компании растет быстрее платы за клик (Pay Per Click — PPC), разве это не фантастика? Или если коэффициент окупаемости инвестиций компании увеличился на 30% за последний месяц, разве это не успех? В каждом из приведенных случаев ответ мог быть один, грандиозное “да”. Но здесь упущен критически важный момент — контекст экосистемы (ecosystem context): что происходит на местности такого, что привело именно к таким результатам деятельности, а не к другим?

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

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

Существует три основные методики, используемые для сбора данных, впоследствии анализируемых в ходе конкурентной разведки в веб: замер при помощи панели, замер при помощи ISP и данные поисковой системы.

Замер при помощи панели

Замер при помощи панели (panel-based measurement) очень похож на традиционную телевизионную систему рейтингов Нильсена (Nielsen ratings system), где в обмен на некий стимул участник соглашался на отслеживание своего поведения при просмотре телевизионных программ. В данном случае программы отслеживает определенное лицо, но для веб эта часть может быть автоматизирована.

Замером при помощи панели занимается компания comScore NetWorks. Собранные ею данные используются многими компаниями для конкурентного анализа. В обмен на стимул (серверная защита от вирусов или розыгрыш призов) участник соглашается контролировать свою активность в веб. Компания comScore реализует это за счет установки контролирующего программного обеспечения на компьютере участника, которое затем передает 100% трафика через ее прокси-серверы. Все данные клиента (включая HTTP, HTTPS, PII, кредитную карточку, номер карточки социального страхования и т.д.) фиксируются компанией comScore.

На декабрь 2006 года глобальная сеть comScore насчитывала 2 миллиона пользователей их панели (хотя замер аудитории компании Media Matrix составил 120 000 участников в США, а Media Matrix Global — 500 000 вне Соединенных Штатов).

Преимущества использования comScore (замер при помощи панели)

• Компания comScore собирает при помощи панели действительно глубокие данные о поведении при просмотре веб-сайта, а следовательно, предоставляемый ими анализ и в самом деле объективен с точки зрения данных.

• Компания comScore может предоставить такие показатели, как показатель переходов или покупок. Их панель контролирует 100 процентов трафика, а для аппроксимации данных показателей применяются сложные обобщения и вычисления.

• Компания comScore может разделять некоторые веб-сайты на внутренние страницы; например, она может произвести замер страницы microsoft.com/office/avinash/information.html, встроенной глубоко в систему каталога, что не позволяет ее эффективно отслеживать при помощи других методов.

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

Недостатки использования comScore (замер при помощи панели)

• Веб насчитывает порядка 200 миллионов пользователей в Соединенных Штатах и примерно 700 миллионов в остальных странах. Так насколько корректно экстраполировать на 200 миллионов человек результат, полученный на основании изучения поведения нескольких сотен тысяч?

• Компания comScore предлагает стимулы (защита от вирусов, розыгрыш призов), способные заинтересовать лишь некоторый тип участников Интернета, так что проблемой может оказаться отклонение от типового характера.

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

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

Рекомендация

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

Замер при помощи ISP

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

Согласно Hitwise, компания имеет порядка 10 миллионов пользователей в США и 25 миллионов во всем остальном мире, предоставляющих ей данные (на декабрь 2006 года).

Преимущества использования Hitwise (замер при помощи ISP)

• Размер выборки значительно больше, и это огромное преимущество.

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

• Ориентированные на ISP методики типа используемых Hitwise предоставляют куда более глубокие и богатые данные о трафике поисковых систем.

• Психографические (psychographic) данные (демография, образ жизни) компания Hitwise предоставляет через базу данных Prizm, это значительно лучше, чем непосредственное получение отчетов.

• По требованию через очень удобный веб-интерфейс компания Hitwise обеспечивает доступ к значительному количеству информации.

Недостатки использования Hitwise (замер при помощи ISP)

• Данные Hitwise весьма обширны (веб-сайты, участники, поисковые системы и сети), но по отдельным веб-сайтам не очень глубоки (глубина просмотра страниц веб-сайта, проникновение в сеансы HTTPS и т.д.). Следовательно, они не могут обеспечить глубокого понимания поведения пользователя на веб-сайте.

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

• Существуют некоторые типы данных PII (например, используемые способы оплаты или типы кредитных карточек), которые не могут быть получены при помощи методик, ориентированных на ISP.

Рекомендация

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

Данные поисковой системы

Это самый новый и, вероятно, наиболее популярный источник информации о поведении конкурентов. Как несложно представить, поисковые системы собирают огромные массивы данных, связанных с поиском. Они зачастую обладают также информацией о своих пользователях (в случае MSN, по информации учетной записи

почтовой системы Hotmail или системы регистрации Passport/Windows Live ID). Google и MSN недавно открыли системы lab/beta, где они позволяют пользователям обращаться к их базе данных, чтобы получить информацию о конкурентах.

На Google Trends () можно ввести одну или несколько фраз поиска, и система укажет общее количество поисков, осуществленных за некое время по этой фразе, частоту ее наличия в статьях Google News (можно даже просмотреть саму статью), а также самые популярные регионы, города и языки, зарегистрированные при ее поиске. На рис. 2.7 представлен отчет Google Trends.

Рис. 2.7. Отчет Google Trends для ключевых слов Microsoft, Google

На Microsoft adCenter Labs (adlab.msn.com/demo.aspx) можно сделать даже больше. Здесь можно определить возраст пользователя веб-сайта, его пол и другую демографическую информацию; задать аналитические параметры, связанные с искомыми ключевыми словами, например кластеризацию и прогноз ключевого слова, поиск последовательности (какие ключевые слова искать сначала, а какие — потом) и ключевые слова развернутого поиска; выявление коммерческих намерений посетителей любого веб-сайта (например, посетители вашего веб-сайта или веб-сайта конкурента более склонны к покупкам?). Отчет Microsoft adCenter Labs представлен на рис. 2.8.

Рис. 2.8. Отчет adCenter Labs Keyword Forecast Report для ключевых слов Canon, Nikon, Fuji и Olympus

Преимущества использования данных поисковой системы

• Доступ к данным и результатам анализа совершенно бесплатен.

• Поскольку большинство посетителей веб предпочитают обращаться к поисковым системам, эти данные представляют огромное количество пользователей.

• Поисковые системы — прекрасный источник подробных данных, связанных с поиском ключевых слов (adCenter, в частности, предоставляет некоторые удивительные инструменты).

Недостатки использования данных поисковой системы

• Объем возможных аналитических действий ограничен по сравнению с Hitwise или comScore.

• Инструменты все еще находятся в состоянии бета-версии.

Рекомендация

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