Веб-аналитика: анализ информации о посетителях веб-сайтов - [50]
Дескрипторы JavaScript создавались для сбора данных о посещаемости сайта в целях бизнес-анализа. Следовательно, они гораздо лучше приспособлены для своих задач и позволяют собирать только те данные, которые нужны (хотя по общему признанию не все дескрипторы JavaScript достаточно интеллектуальны и собирают также ненужные данные).
Это означает, что при использовании дескрипторов JavaScript собирается намного меньший объем данных, подлежащих хранению и обработке каждую ночь (или в минуту, или в час, или в день), что существенно облегчает жизнь логически, оперативно и стратегически.
Хорошо это или плохо, но большинство производителей давно не предоставляют версии своих продуктов, которые используют в качестве источника данных веб-журналы. Предлагаются, в основном, версии продуктов только для дескрипторов JavaScript (или анализаторов пакетов). История рассудит, насколько это хорошо, но практическое значение заключается в том, что большинство инноваций, происходящих в области сбора данных, их анализа, новых способов составления отчетов, а также удовлетворения потребностей Web 2.0 наблюдается именно в системах сбора данных на базе JavaScript.
Это ставит компанию перед необходимостью создавать собственные специализированные приложения по сбору и хранению новых данных, связанных с современными инновациями или экспертными решениями (независимо от предпочитаемого производителя), а также всех инноваций, вносимых производителями. Зачастую выбор для компании прост, если она считает приоритетной сосредоточенность
на бизнесе, а не на разработке решений веб-аналитики. (Хотя, по общему признанию, если компания достаточно велика, она вполне способна и на это, например, компания Wal-Mart разработала собственное решение для базы данных, поскольку ни одна система в мире не удовлетворяла потребностям компании столь большого размера и масштаба.)
Все чаще и чаще приходится полагаться скорее на замер и анализ впечатления клиента, чем на анализ посещаемости сайта. Два прекрасных примера: экспериментирование и проверка (особенно многопараметрическая), а также ориентированность на личности и поведение. В обоих случаях дополнительные решения применяются и на веб-сайте, и при проверке. Зачастую они связаны с их собственными методами сбора и анализа данных, а также замера успешности.
Однако для интегрированного сквозного представления о поведении клиента и оптимального анализа необходимо отыскать способ интеграции этих дополнительных данных со стандартными данными анализа посещаемости сайта. В противном случае понадобится оптимизация по каждому дополнению. Интеграция с такими дополнительными решениями, которые зачастую также применяют дескрипторы JavaScript, файлы cookie и идентификаторы URL. Значительно проще, когда используются дескрипторы JavaScript. Читать файлы cookie в веб-журналах тоже несложно, но организовать интеграцию с добавочными решениями будет быстрее и проще с использованием дескрипторов JavaScript.
Совет. Всегда осуществляйте выбор на основании собственных потребностей. Вышеизложенное — скорее личное мнение, чем рекомендация. Анализируя все преимущества и недостатки каждой методики сбора данных, учитывайте их описание в главе 2, “Сбор данных — важность и возможности” (поскольку применение дескрипторов JavaScript имеет несколько недостатков, а использование веб-журналов — несколько неоспоримых преимуществ).
Если есть желание выслушать еще чье-нибудь мнение перед принятием решения, то имеет смысл сделать это сейчас!
Как вы уже поняли, выбор инструмента веб-анализа — чрезвычайно ответственный процесс, и сделать его правильно критически важно, ведь проработать с ним придется довольно долго. Поскольку наблюдается тенденция преувеличивать значимость исторических веб-данных, не исключено, что сделанный выбор вскоре перестанет казаться правильным.
Итак, выбор инструмента веб-анализа сродни выбору супруга (супруги), поскольку жить с ним предстоит долго и желательно счастливо.
В настоящее время процесс выбора инструмента веб-анализа существенно изменился. Но традиционно он протекал в девять этапов и выглядел обычно следующим образом:
1. Соберите по возможности все бизнес-требования (цели, стратегия, KPI, отчеты, расписание их подачи и т.д.).
2. Соберите по возможности все технические требования (архитектура сайта, серверы, сценарии, страницы, требования информационных технологий и т.д.).
3. Свяжитесь со всеми (внутри и вне компании), кто мог бы нуждаться в любом виде доступа к любому виду веб-данных и выясните их потребности.
4. Поместите всю приведенную выше информацию в запрос предложений (Request For Proposal — RFP). Добавьте требования по финансовой стабильности производителя, ссылки и т.д.
5. Разошлите RFP разным производителям с указанием срока ответа.
6. Получите ответные RFP.
7. На основании маркетинговых данных, личных предпочтений и соответствия RFP отбросьте "малозначительные" предложения.
8. Обсудив с руководством компании, выберите одного производителя, который отвечает всем требованиям.