Веб-аналитика: анализ информации о посетителях веб-сайтов - [116]

Шрифт
Интервал

Существует много прекрасных производителей (автор имел большой опыт многопараметрической проверки с использованием Offermatica и Google Web Optimizer). Различия между инструментами не будут вашим главным ограничением на протяжении некоторого времени (проверка идей, культура, сложность программы и внедрения). Так, если у вас есть знакомый, работающий в SiteSpect, наймите его. Но не забудьте обзавестись экспертом.

Пятница: реализуйте два ключевых компонента любой программы проверки

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

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

Процесс

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

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

• должности, которые необходимо укомплектовать;

• конкретные обязанности для каждой должности;

• четкую структуру для принятия решений.


Рис. 10.7 иллюстрирует полный процесс проверки (вероятный).


Рис. 10.7. Надежный процесс проверки: шаги, роли и обязанности


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

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

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

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

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

Большинство из нас пугает слово процесс (process), поскольку с ним ассоциируется негатив и небольшие шансы на выигрыш. Но это неправильное восприятие. Хорошо документированный процесс может быть просто слайдом PowerPoint, который в простой форме представляет схему процесса. Даже на ней можно заметить различные неупорядоченности, оплошности, масштабируемость и здравомыслие. Можно также решить начать с простого, а затем, по мере приобретения квалификации, оптимизировать процесс или добавить больше подробностей.

Сбор требований

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

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

• Постановка гипотезы.

• Какова бизнес-проблема или сложность, которую предстоит решить?

• Какова гипотеза?

• Бизнес-случай.

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

• Аудитория проверки.

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