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

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

В этой главе рассматриваются основные принципы и стратегии веб-аналитики, позволяющие справиться с возможными проблемами.

Сбор данных: веб-журналы или дескрипторы JavaScript?

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

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

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

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

Когда дело доходит до сбора данных о веб-сайте, используйте дескрипторы JavaScript.

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

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

Разделение обслуживания и сбора данных

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

Когда используются дескрипторы JavaScript, сбор данных действительно отделяется от их обслуживания. Веб-страницы могут передаваться отовсюду (из веб-сервера компании, из локального кеша посетителя или из фермы кэширования Akamai или ISP), при этом сбор данных будет все равно продолжаться (дескриптор JavaScript выполняется при загрузке страницы, и данные передаются на сервер ASP или внутренний). Красота этого подхода заключается в том, что отдел информационных технологий компании и разработчики веб-сайта могут делать свою непосредственную работу, а “аналитический отдел” свою — собирать данные. Это также означает, что обе стороны обретают гибкость в действиях, т.е. аналитики и разработчики независимо правят код (который не всегда должен располагаться в дескрипторах на странице) для сбора большего количества данных.

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

Типы и размер данных

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

Дескрипторы 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. Обсудив с руководством компании, выберите одного производителя, который отвечает всем требованиям.

9. Внедрите решение и празднуйте.

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

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

Новый способ

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

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

Следуйте инструкции, приведенной ниже.

1. Выясните оптимальную принадлежность (день 1).

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

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

• Оповестите по электронной почте всех сотрудников компании (небольшое преувеличение) о выборе инструмента.

2. Реализуйте решение веб-аналитики (день 2).

• При использовании данных веб-журналов раздобудьте ClickTracks Appetizer ().

• Если предпочли данные дескрипторов страниц, используйте Google Analytics ().

• Если оба инструмента не вызывают доверия, раздобудьте StatCounter (www.statcounter.com). Хотя он бесплатно предоставляет только основные данные, он все же очень хорош.

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

3. Начните с использования простых отчетов и формирования интеллектуальной

аудитории в компании (день 3).

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

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

• Проведите второй выпуск отчетов.

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

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

4. Выясните для себя ограничения веб-аналитики, дескрипторов, несоответствия чисел, необходимость повторного сбора информации о веб-сайте (архитектура, URL,

идентификаторы, параметры, файлы cookie) и других данных (день 17).

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

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

5. Засучите рукава и принимайтесь за дело (день 27).

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

• Зачастую это трудный процесс. Соберите все необходимое вместе (и раздобудьте недостающее).

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

• Постепенно увеличивайте круг пользователей данных.

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

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

6. Составьте четкий и глубокий критический обзор сделанного (месяц, два и больше).

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

• Выясняется, что составление отчетов не равнозначно анализу, поэтому необходимо существенное обновление веб-аналитиков компании с точки зрения квалификации.

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

• Выясняется, что Google Analytics или ClickTracks полностью удовлетворяют все потребности компании в области веб-аналитики.

• Выясняется, что ClickTracks или Google Analytics — неподходящие инструменты веб-анализа для данной компании, поскольку она имеет уникальные потребности.

• Выясняется, что веб-аналитика (данные анализа посещаемости сайта) недостаточна для поиска веб-понимания, поэтому потребуются средства на исполнителей веб-анализа, а также опытных аналитиков и исследователей (см. о мировоззрении Trinity в главе 1, “Веб-аналитика — настоящее и будущее”).

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

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

• Теперь RFP должен содержать определение имеющейся проблемы и ограничения нынешнего инструмента (Google Analytics, ClickTracks, StatCounter).

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

• Выберите разных производителей. Помните, Большая Тройка (Big Three) предлагает в значительной степени одинаковый набор возможностей и преимуществ (за исключением, возможно, 5 процентов различий, которые решают все). Если в окончательном списке вариантов остались только производители Большой Тройки, реальный дифференцированный выбор можно пропустить. Если необходимо объективное сравнение, выберите радикально иного производителя. Рассмотрите инструменты Coremetrics, Visual Sciences, IndexTools, Unica или ClickTracks, каждый из них имеет множество различий, которые можно свести в таблицу.

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

Преимущества нового способа

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

Всего за шесть этапов было сделано практически невозможное.

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

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

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

Разработчики веб-сайта. Они изучили все мелочи предоставления данных, которые критически важны для принятия бизнес-мер, — параметры, которые следует добавлять в URL, имена страниц, которые нужно модифицировать, дублирование ссылок на страницах, чтобы их можно было отслеживать, и т.д.

Создатели отчетов. Они узнали, что веб-аналитика — это не столько написание отчетов, сколько анализ, при этом рекомендуется заняться саморазвитием для успешного перехода на следующий уровень.

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

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

Бизнес-руководители. Они узнали, обладают ли их сотрудники достаточной квалификацией и имеются ли пробелы в их процессах. Они убедились, что реальную цену веб-аналитики составляют не инструменты, а люди (вспомните правило 10/90).

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

Понятие качества данных о посещаемости сайта

В главе 2, “Сбор данных — важность и возможности”, начался разговор о принципе GIGO: мусор на входе - мусор на выходе (Garbage In, Garbage Out). Важно выбрать такую методику сбора данных, которая бы наилучшим образом подходила для конкретных потребностей, а также удостовериться в правильности ее реализации. Но, вероятно, нет никакого другого фактора, настолько отравляющего жизнь веб-аналитика, как качество данных. Уникальная проблема сбора веб-данных частично заключается в следующем.

• Веб-сайт постоянно развивается.

• Технология постоянно изменяется.

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

• Каждый производитель разработал собственные “оптимизированные” методики сбора и обработки данных.

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

• Данные, собираемые по всему миру веб, получаются разрозненными и требующими объединения.

• Для отслеживания личности приходится полагаться на такие “хрупкие” вещи, как файлы cookie. Однако они отслеживают только такие браузеры, как Microsoft Internet Explorer, Firefox от Mozilla или Safari от Apple, а не людей.

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

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

• Ничто не кажется связанным с чем-нибудь еще.

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

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

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

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

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

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

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

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

И с этим ничего нельзя поделать, по крайней мере сейчас.

Чем скорее удастся это усвоить, тем быстрее получится смириться и продолжать. На самом деле не имеет значения и то, что инструмент от любимого производителя бесплатен или стоит 1 миллион долларов. Все производители в значительной степени используют похожие методики сбора данных. Да, у каждого есть некоторые милые инновации, но они не помогут, поскольку Интернет — чрезвычайно юркое животное, постоянно развивающееся и изменяющееся. Собственно, в этом и заключается восхитительная красота и обаяние веб.

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

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

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

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

Это нудное и бесполезное занятие. Кроме того, ко времени нахождения некоего подобия объяснения появятся новые причины, по которым данные не будут увязываться (по крайней мере, на макроуровне). Если несоответствие составляет лишь 10 процентов или меньше, то все в порядке, поскольку это в пределах ожидаемого разброса. Меньше 10 процентов — очень хорошо. Грустно, но справедливо.

2. Полностью овладейте данными.

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

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

3. Принимайте удобные решения.

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

Если со 100-процентным доверием к данным человека можно посылать на Луну, то с 75-процентным доверием к ним же ему можно, по крайней мере, посоветовать купить телескоп, чтобы тоже исследовать Луну. Важнейшим здесь является сам факт принятия решения и возможность его

реализовать1.

Предположим, например, что некий важный KPI изменился на 15 процентов. При 100 процентах доверия к данным понадобилось бы срочно инвестировать порядка 90 000 долларов на проведение рекламной кампании, полное изменение архитектуры сайта или построение процесса расчета. Но при 75 процентах доверия к тем же 15 процентам изменения KPI можно решить, что для начала стоит потратить лишь 60 000 долларов, а перед полным изменением архитектуры сайта провести многопараметрическую проверку, чтобы получить больше доверия к данным или, возможно, выработать новый процесс расчета, поскольку при наличии лишь 75-процентного доверия к данным расчет очень важен.

Этот пример — простая иллюстрация возможности принимать решения с менее чем 100 процентами доверия к данным. Правильное поведение. Хорошо, если аналитик доверяет данным больше, чем ответственные лица компании, но и они со временем привыкнут.

Данная модель поведения очень важна. Если аналитику будет трудно обрести доверие к информации, то ответственным лицам компании или окружающим будет еще труднее это сделать и переходить к следующему этапу.

4. Углубитесь в специфические области.

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

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

5. Освойтесь с данными и их ограничениями.

Со временем, по мере улучшения овладения данными (сбором, хранением, манипулированием, обработкой и анализом), можно вносить соответствующие коррективы в интерпретации и поиск веб-понимания. В свою очередь это через некоторое время повысит уровень доверия к данными с 75 процентов до 78, 85, 90 и т.д. Хотя до 100 процентов доверия дело никогда, возможно, и не дойдет, но бизнес решения начнете все же выполнять гораздо увереннее.

Стремитесь к небольшим инкрементным усовершенствованиям и увеличению уровня доверия для себя лично и для ответственных лиц (это намного сложнее).

6. Стремитесь к целостности в вычислениях.

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

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

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

Два исключения, заслуживающие внимания с точки зрения качества данных

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

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

Например, предполагается заменить Omniture на WebTrends, или WebTrends на CoreMetrics, или Google Analytics или Omniture, или... любые комбинации Omniture, WebTrends, HBX, Coremetrics на ClickTracks, Google Analytics, WebTrends, Omniture. Запустите оба инструмента параллельно и обратите внимание, что посетителей относительно прежней платформы стало, например, на 15 процентов больше. Используйте этот коэффициент для сравнения тенденции прежних данных. Сделайте это для трех или четырех основных показателей (просмотры страниц, уникальные посетители, время на сайте) и забудьте о согласовании.

Коэффициент сэкономит большое количество долларов, времени и волос на голове.

Анализ корзины и процесс расчета

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

Реализация рекомендаций

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

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

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

Рекомендации следующие:

1. Располагайте дескрипторы на всех страницах.

2. Располагайте дескрипторы в конце.

3. Располагайте дескрипторы вместе.

4. Идентифицируйте уникальные определения страниц.

5. Используйте файлы cookie с умом.

6. Учитывайте проблемы кода ссылок.

7. Будьте готовы к переадресации.

8. Проверьте правильность фиксируемых данных.

9. Проверьте правильность кода улучшенного веб-содержимого.

Обратите внимание, рекомендации пронумерованы; по мере их реализации можно создать нумерованный список по строкам и отмечать в нем выполненные элементы.

Располагайте дескрипторы на всех страницах

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

Простое программное обеспечение типа Web Link Validator от REL Software весьма полезно для проверки правильности расстановки дескрипторов на страницах. Хотя оно способно значительно на большее. Более подробная информация о возможностях Web Link Validator приведена по адресу , и своих 95-795 долларов оно стоит.

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

Располагайте дескрипторы в конце (клиенты приходят сначала!)

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

Веб-сайты предназначены в первую очередь для клиентов и лишь во вторую — для сбора данных.

Располагайте дескрипторы вместе

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

Идентифицируйте уникальное определение страниц

Веб-сайты становятся все более динамическими с точки зрения взаимодействия с клиентами или предоставления содержимого. Так, одна и та же страница .html (или .jhtml, или .asp, или .jsp) может делать разные вещи. Это означает, что для ее идентификации больше нельзя полагаться на схему имя-продукта .html.

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

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

В данном случае .html просто указывает индивидуальную страницу.

Однако рассмотрим следующий URL, взятый с веб-сайта Best Buy:

Это olspage.jsp и параметр skuId, что, возможно, определяет индивидуальную страницу. Если в данном случае оставить инструмент веб-анализа без обучения тому, что делает страницу индивидуальной, то числа, очевидно, будут получены неправильно.

Проблема определения индивидуальности страниц

Идентификация индивидуальных страниц может быть очень затруднена. Ниже приведен реальный URL с вебсайта (фактическое имя сайта было удалено в целях безопасности). Можно ли предположить, что это идентифицирует индивидуальную страницу?

Используйте файлы cookie с умом

=

Используйте по возможности собственные файлы cookie, а не стороннего производителя. Они позволяют собирать информацию трех следующих типов.

Атрибуты источника. Определяют, откуда приходят посетители (веб-сайты, кампании, поисковые системы и т.д.).

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

Атрибуты пользователя. Определяют, кем является посетитель (по постоянным анонимным идентификаторам, регистрационному имени, если оно есть, и т.д.).

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

Иногда атрибуты пользователя имеют тенденцию оставаться на стороне сервера после инициализации сеанса, например значение параметра TimesSelect анонимного файла cookie или регистрационное имя на веб-сайте New York Times. Учтите, что если дело обстоит так, то дескрипторам JavaScript эти данные недоступны.

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

1

Учитывайте проблемы кода ссылок

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

Оболочки JavaScript

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

JavaScript:var

x=window.open('?)

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

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

Анкеры

Анкеры (anchor), или якоря, в конце ссылок — это просто способ для посетителя быстрее перемешаться в пределах той же страницы. Рассмотрим, например, следующую ссылку:

Щелкнув на ней (где #features — часть анкера), посетитель останется на той же странице, но перейдет к разделу возможностей продукта.

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

Несколько ссылок на один источник

Нет ничего необычного в нескольких ссылках на один источник, расположенных на одной странице. Например, на веб-сайте Amazon.com ссылка на раздел Books присутствует в заголовке, в навигационной панели слева, в теле веб-страницы и во вспомогательной области справа. Все четыре ссылки указывают на ту же страницу.

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

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

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

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

Будьте готовы к переадресации

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

Внутренняя переадресация

Применение внутренней переадресации (internal redirect) (переадресация с одной страницы веб-сайта на другую страницу того же сайта) может быть не оптимально. Например, давайте рассмотрим следующую ссылку с веб-сайта Microsoft:

Это ссылка с microsoft.com на подкаталог microsoft.com/downloads того же сайта, но через msn.com. Автор не уверен, делает ли Microsoft это для преодоления проблем с инструментом веб-анализа, хотя это совершенно неважно. Дополнительная передача данных через второй домен может вызвать проблемы. Инструмент придется настроить так, чтобы он свидетельствовал о переходе посетителей с домашней страницы не на g.msn.com, а на , и эту логику придется поддерживать постоянно (что может быть сложно при изменении сайта). Использование внутренней переадресации требует также фиксации и хранения дополнительных данных, что тоже может вызвать проблемы при их глубокой сегментации.

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

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

Внешняя переадресация

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

В этом примере представлена ссылка на eliminated.com, которая пересылает трафик на zsolutions.com при помощи переадресации. В прошлом это была единственная возможность, поскольку при использовании веб-журнала данные реферрера передаются на сайт получателя. Применение переадресации позволяет веб-журналу зафиксировать “щелчок” для отчета.

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

Еще один резон использования внешней переадресации — часть некой кампаний (баннера, маркетинговый поиск, слияние и т.д.). Рассмотрим пример (взят из сети Yahoo!).

Когда пользователь щелкает на этой волшебной ссылке, он переходит по адресу вроде следующего:

Приведенный выше сервер, вероятно, используемый агентством, заканчивает переход примерно так:

=

Так что один щелчок проводит клиента по назначению через два транзитных участка, на каждом из них данные собираются кем-то вне компании. Способно ли приложение веб-аналитики установить, что пользователь пришел с Overture? Обычный ответ — нет.

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

• Работая с агентством (или внутренним ресурсом), следует удостовериться, что по крайней мере один параметр передается с транзитного участка владельцу, чтобы он мог точно контролировать ход кампании. Этим параметром мог бы быть source id (идентификатор источника), используемый в приведенном примере.

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

Проверьте правильность фиксируемых данных

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

Я не собираюсь агитировать за тот или иной подход, поскольку оба имеют свои преимущества и недостатки. Однако важно наладить контроль качества (Quality Audit — QA) среды и рабочего окружения, чтобы каждый из 25 специальных дескрипторов фиксировал именно то, что и предполагалось.

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

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

Проверьте правильность кода улучшенного веб-содержимого

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

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

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

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

Применение трех уровней "ну и что"

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

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

А вот реальность веб: можно обратиться на google.com/analytics и подписаться на учетную запись за пять минут. В ответ получите фрагмент кода JavaScript. Поместите его в глобальный для веб-сайта нижний колонтитул, сохраните файл и — готово. Через пару часов откроется доступ примерно к 80 отчетам и такому большому количеству показателей, что сразу и не сообразишь, как с ними быть.

Обратите внимание на различие периода внедрения (time to market) в двух ситуациях. Год или более при крупных затратах против пары часов и отсутствии затрат. Вместо Google Analytics можно использовать другой, платный продукт веб-аналитики. Это ненамного замедлит внедрение, лишь на время выбора другого производителя (пара месяцев максимум).

Опасностью получения непосредственного доступа к такому большому количеству показателей является то, что становится трудно разобраться, как извлечь из них максимальную пользу. Дилемма осложняется большим объемом разнообразных KPI (Key Performance Indicator — ключевой показатель эффективности), которые скорее затрудняют, чем облегчают выбор правильного направления. В такой среде трудно выяснить, на чем следует сосредоточиться и какие показатели исследовать, чтобы обрести максимально действенное понимание.

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

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

Давайте на паре примеров проиллюстрируем проведение проверки “ну и что”.

Ключевой показатель эффективности: процент повторных посещений

Запустите отчет и обратите внимание на тенденцию. Вот как будет работать проверка “ну и что”.

• “Из месяца в месяц наблюдается тенденция роста повторных посещений веб-сайта.”

Ну и что ?

• “Это хорошо, поскольку демонстрирует его привлекательность.” (Хороший момент задаться вопросом “почему” и в результате чего был достигнут рост привлекательности, но речь сейчас не об этом.) Ну и что?

• “Для манипуляции этой тенденцией необходимо сделать больше xxx (или yyy, или zzz, что могло бы привести к еще большему росту тенденции, если это хорошо).”

Ну и что?

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

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

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

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

• “Вот самые популярные страницы выхода на веб-сайте за декабрь 2006 года.” Ну и что? За шесть месяцев они, похоже, не изменились.

• “На эти страницы следует обратить внимание, поскольку это главные точки утечки (leakage point) с веб-сайта.” Ну и что? Мы смотрим этот отчет уже шесть месяцев и пытаемся исправить ситуацию, но даже после этого перечисленные здесь страницы не покинули его.

• “Если нам удастся предотвратить утечку посетителей с веб-сайта, то мы сможем сохранить их.” Ну и что?Разве не все посетители рано или поздно покидают веб-сайт на некой странице?

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

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

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

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

• “Показатель переходов для 20 наиболее популярных ключевых слов увеличился за последние три месяца на статистически существенное значение”. Ну и что?

• “Наша компания PPC (Pay-Per-Click — плата за щелчки) дает положительный результат, и мы должны перераспределить фонды согласно тем девяти ключевым словам, которые выглядят наиболее многообещающими.” Вот оно!

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

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

• Все довольно понятно и после первого ответа вопрос “ну и что?”, но даже для этого KPI аналитик сегментировал данные на реалистичные и PPC. Это еще один небольшой секрет: никакой KPI не работает на объединенном уровне, понимание можно получить лишь по отдельности, что и обеспечивает сегментация (segmentation).

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