Не так давно я посетил одно мероприятие, где местные интернет-бизнесмены делились своим опытом и пережевываниями относительно своих проектов в интернет.
И так сложилось, что гвоздем программы был некий парень, назовем его Семен, который представился управляющим интернет-магазина игрушек с ежедневной посещаемостью более 17000 человек. И это была правда.
Семен занимал одну из самых важных должностей в этом проекте и мог влиять на многие аспекты бизнеса. Вопрос, с которым он обратился к аудитории звучал примерно так: «Друзья, у нас довольно успешный интернет-магазин игрушек, но мне не нравится его дизайн. Например вот эта штука, или эта. Я бы хотел выслушать ваше мнение, что нам можно изменить или улучшить?»
Аудитория не заставила себя долго ждать и тут же начала извергать самые разные идеи, предлагать развитие функционала или отказ от чего-то.
Вот проблема только в том, что никому не было интересно, а что же происходит с данным магазином сейчас, какая у него к��нверсия? На этот вопрос Семен ответил несколько расплывчато. Он думал или вернее догадывался о конверсии в 2% во что мне верилось с трудом.
Рядом точных вопросов мне удалось привести Семена к мысли, что вот так, пальцем в небо что либо менять или улучшать как минимум не принесет пользы, а может даже пойдет и во вред.
Смысл этой истории в том, что подавляющее большинство нынешних крупных и мелких владельцев интернет-бизнеса поступают ровным счетом также.
Семен полагал, что его личные взгляды и вкусы целиком и полностью соответствуют ожиданиям аудитории. По этому все изменения проводились хаотично по принципу «а было бы не плохо».
Проблема такого подхода заключается в создании универсального интерфейса для всех и каждого, а значит ни для кого. Как итог, сайт либо вообще не продает, либо продает плохо. А поскольку почти все сайты продают плохо, магический коэффициент конверсии в 1%-2% считается вполне нормальным. А что же происходит с остальными 98-99% посетителей, почему они ушли?
Ответ на этот вопрос и на проблемы Семена дает как ни странно веб-аналитика. В последнее время каждый начинающий и бывалый бизнесмен понимает необходимость установки Google Analytics, но ее использование, к сожалению, часто ограничивается только просмотром объема трафика и может еще каких-то тривиальных данных.
В правильных же руках, информация из Google Analytics способна дать ответы на многие вопросы, в частности указать на узкие места в интерфейсе, действительно требующие изменений.
После установки кода Google Analitycs, можно сразу отслеживать довольно много данных, но для полноценной картины необходимо провести еще кое-какую работу.
События позволяют отслеживать точки взаимодействия с интерфейсом. Например, на вашей странице с описанием товара есть три кнопки «Купить». Чтобы выяснить, какая из них приносит максимальный эффект, а какая вообще не эффективна достаточно назначить для каждой из них свой идентификатор события. Например, вот так:
<a href="/product/buy" onclick="_gaq.push(['_trackEvent', 'BuyButtons', 'BuyMain', 'Product Name']);">Купить
Где:
Таким образом, при нажатии на какую либо из кнопок мы будем точно знать, какая из них работает.
Позднее, в отчетах Google Analitycs собираемую информацию можно увидеть в отчете: «Отчеты/Поведение/События/Обзор».
Ценность событий в разрезе проектирования интерфейсов заключается в возможности отслеживать эффективность всех интерактивных элементов интерфейса. И на основе данных использования уже стоить гипотезы о необходимых изменениях.
Если настройкой событий еще можно пренебречь, то отслеживание целей должно быть настроено сразу же после установки кода Google Analitycs. Ибо эффективность достижения целей являет��я самой важной характеристикой работе сайта.
Целей может быть много, но важно знать меру и не создавать бестолковых целей, вроде длительности проведенного времени, количества просмотренных страниц или посещение страницы Оплата и доставка.
Например, для интернет-магазина логичными целями являются посещение страницы «Корзина», каждая страница процесса оформления заказа и финальная «Thank You Page». Кроме этого можно еще настроить цели для других лидогенерирующих элементов: форма вопроса по товару, обратный звонок, итд.
В отличие от событий, цели настраиваются через интерфейс Google Analitycs: «Администратор/Цели/Создать цель»
При создании цели можно также указать последовательность посещения предыдущих страниц, например, процесс оформления заказа. Тогда в отчете «Отчеты/Конверсии/Цели/Визуальная последовательность» можно увидеть такую замечательную воронку продаж:
В моем примере воронка состоит лишь из двух страниц.
Имея информацию о целях, вы сможете довольно точно увидеть, в каком месте процесса продаж у вас возникают проблемы, будь то карточка товара, корзина, процесс оформления заказа или что ни будь еще и «одним правильным мазком» улучшить продажи на вашем сайте.
Если ваш сайт является интернет-магазином, необходимость включения и настройки электронной торговли также важна, как и настройка целей.
Разница между целями и электронной торговлей в том, что цели говорят о факте покупки, в то время как торговля говорит что именно купили.
В разрезе проектирования интерфейсов, отчеты электронной торговли сообщают такую полезную информацию об аудитории, как средний чек, время до покупки, количество товара в заказе и могут служить отличными контрольными точками для отслеживания эффективности внедренных изменений.
Теперь, когда у вас есть настроенные события, цели и электронная торговля можно подходить к построению гипотез о необходимости тех или иных изменений.
Просматривая отчеты вы сможете четко заметить такие аномалии, как прерывающиеся конверсии на пути к финальной цели или понять, что какой-то функциональный и очень красивый блок не работает, так как не генерирует ни каких событий.
Исходя из выявленных проблем, вы сможете вполне безопасно убрать лишние, не работающие элементы, сократив избыточный функционал и сделав жизнь ваших пользователей чуточку лучше. Или же обратите пристальное внимание на страницу, где происходит большой процент прерывания и обязательно найдете причину, что сразу же скажется на увеличении конверсии.
Тем не менее, не смотря на кажущуюся простоту, любые изменения в уже работающем проекте рекомендуется делать через сплит-тестирование. Таким образом, во первых можно уберечься от неправильных изменений, во вторых точно оценить эффективность внедренных изменений.
A/B – тестирование позволяет проверить эффективность нескольких вариантов страниц. Например, вы решили проверить гипотезу, что увеличение размера кнопки «Купить» и ее цвета на яркий, контрастный способно увеличить вероятность ее нажатия.
Для этого необходимо создать копию страницы с внедренными изменениями и доступную, например, по GET-параметру ?split.
То-есть, если пользователь открывает страницу: _http://site/category/product — он видит старое содержание, а по адресу _http://site/category/product?split открывается страница с большой и яркой кнопкой.
Теперь, используя инструмент «Отчеты/Поведение/Эксперименты/Создать эксперимент» вы сможете очень быстро запустить ваш эксперимент и проверить гипотезу.
Механизм работы A/B – теста заключается в случайном показе выбранному объему аудитории одного из проверяемых вариантов и замером эффективности достижения выбранной для эксперимента цели.
Вот так выглядит один из отчетов:
В целом, я рекомендую проверять абсолютно все вносимые изменения, будь то внедрение совершенно нового дизайна страницы или изменение текста описания товара. Но лучше всего A/B – тесты работают на небольших изменениях, так как в случае с изменением всей страницы будет сложно понять что именно влияет на результат.
Возвращаясь к истории с Семеном, теперь становится ясно, почему его попытки слепого изменения могли бы обернуться реальным провалом всего бизнеса.
Любое изменение в уже работающем проекте должно иметь под собой почву из аналитических данных и проверятся с помощью тестов. Особенно это важно для высоко посещаемых проектов со сформировавшимся ядром аудитории, как в случае с Семеном. Ведь, какой замечательный и идеальный интерфейс бы не внедрили на его сайт, большая часть аудитории все равно была бы жутко недовольна, ибо привычки уже сформированы, а точечное улучшение воспринялось бы куда лучше. Вспомните хотя бы iOS7.
P.S. В материале описываются принципы работы с классическим Google Analitycs, но уже на смену ему приходит Universal Analitycs, где метод учета событий несколько отличается.
P.P.S. Если материал показался вам интересным, пишите в комментариях, о чем бы вы хотели узнать еще – с удовольствием поделюсь своим практическим опытом проектирования интерфейсов.
И так сложилось, что гвоздем программы был некий парень, назовем его Семен, который представился управляющим интернет-магазина игрушек с ежедневной посещаемостью более 17000 человек. И это была правда.
Семен занимал одну из самых важных должностей в этом проекте и мог влиять на многие аспекты бизнеса. Вопрос, с которым он обратился к аудитории звучал примерно так: «Друзья, у нас довольно успешный интернет-магазин игрушек, но мне не нравится его дизайн. Например вот эта штука, или эта. Я бы хотел выслушать ваше мнение, что нам можно изменить или улучшить?»
Аудитория не заставила себя долго ждать и тут же начала извергать самые разные идеи, предлагать развитие функционала или отказ от чего-то.
Вот проблема только в том, что никому не было интересно, а что же происходит с данным магазином сейчас, какая у него к��нверсия? На этот вопрос Семен ответил несколько расплывчато. Он думал или вернее догадывался о конверсии в 2% во что мне верилось с трудом.
Рядом точных вопросов мне удалось привести Семена к мысли, что вот так, пальцем в небо что либо менять или улучшать как минимум не принесет пользы, а может даже пойдет и во вред.
Смысл этой истории в том, что подавляющее большинство нынешних крупных и мелких владельцев интернет-бизнеса поступают ровным счетом также.
В чем же проблемы Семена?
Семен полагал, что его личные взгляды и вкусы целиком и полностью соответствуют ожиданиям аудитории. По этому все изменения проводились хаотично по принципу «а было бы не плохо».
Проблема такого подхода заключается в создании универсального интерфейса для всех и каждого, а значит ни для кого. Как итог, сайт либо вообще не продает, либо продает плохо. А поскольку почти все сайты продают плохо, магический коэффициент конверсии в 1%-2% считается вполне нормальным. А что же происходит с остальными 98-99% посетителей, почему они ушли?
Ответ на этот вопрос и на проблемы Семена дает как ни странно веб-аналитика. В последнее время каждый начинающий и бывалый бизнесмен понимает необходимость установки Google Analytics, но ее использование, к сожалению, часто ограничивается только просмотром объема трафика и может еще каких-то тривиальных данных.
В правильных же руках, информация из Google Analytics способна дать ответы на многие вопросы, в частности указать на узкие места в интерфейсе, действительно требующие изменений.
Что отслеживать?
После установки кода Google Analitycs, можно сразу отслеживать довольно много данных, но для полноценной картины необходимо провести еще кое-какую работу.
Настроить отслеживание событий
События позволяют отслеживать точки взаимодействия с интерфейсом. Например, на вашей странице с описанием товара есть три кнопки «Купить». Чтобы выяснить, какая из них приносит максимальный эффект, а какая вообще не эффективна достаточно назначить для каждой из них свой идентификатор события. Например, вот так:
<a href="/product/buy" onclick="_gaq.push(['_trackEvent', 'BuyButtons', 'BuyMain', 'Product Name']);">Купить
Где:
- BuyButtons – группа, которая будет объединять ваши события (название может быть произвольным)
- BuyMain – идентификатор события, то есть какая именно кнопка была нажата (название может быть произвольным)
- Product Name – название продукта, для более точной аналитики
Таким образом, при нажатии на какую либо из кнопок мы будем точно знать, какая из них работает.
Позднее, в отчетах Google Analitycs собираемую информацию можно увидеть в отчете: «Отчеты/Поведение/События/Обзор».
Ценность событий в разрезе проектирования интерфейсов заключается в возможности отслеживать эффективность всех интерактивных элементов интерфейса. И на основе данных использования уже стоить гипотезы о необходимых изменениях.
Настроить цели
Если настройкой событий еще можно пренебречь, то отслеживание целей должно быть настроено сразу же после установки кода Google Analitycs. Ибо эффективность достижения целей являет��я самой важной характеристикой работе сайта.
Целей может быть много, но важно знать меру и не создавать бестолковых целей, вроде длительности проведенного времени, количества просмотренных страниц или посещение страницы Оплата и доставка.
Например, для интернет-магазина логичными целями являются посещение страницы «Корзина», каждая страница процесса оформления заказа и финальная «Thank You Page». Кроме этого можно еще настроить цели для других лидогенерирующих элементов: форма вопроса по товару, обратный звонок, итд.
В отличие от событий, цели настраиваются через интерфейс Google Analitycs: «Администратор/Цели/Создать цель»
При создании цели можно также указать последовательность посещения предыдущих страниц, например, процесс оформления заказа. Тогда в отчете «Отчеты/Конверсии/Цели/Визуальная последовательность» можно увидеть такую замечательную воронку продаж:
В моем примере воронка состоит лишь из двух страниц.
Имея информацию о целях, вы сможете довольно точно увидеть, в каком месте процесса продаж у вас возникают проблемы, будь то карточка товара, корзина, процесс оформления заказа или что ни будь еще и «одним правильным мазком» улучшить продажи на вашем сайте.
Настроить электронную торговлю
Если ваш сайт является интернет-магазином, необходимость включения и настройки электронной торговли также важна, как и настройка целей.
Разница между целями и электронной торговлей в том, что цели говорят о факте покупки, в то время как торговля говорит что именно купили.
В разрезе проектирования интерфейсов, отчеты электронной торговли сообщают такую полезную информацию об аудитории, как средний чек, время до покупки, количество товара в заказе и могут служить отличными контрольными точками для отслеживания эффективности внедренных изменений.
Я все сделал, что дальше?
Теперь, когда у вас есть настроенные события, цели и электронная торговля можно подходить к построению гипотез о необходимости тех или иных изменений.
Просматривая отчеты вы сможете четко заметить такие аномалии, как прерывающиеся конверсии на пути к финальной цели или понять, что какой-то функциональный и очень красивый блок не работает, так как не генерирует ни каких событий.
Исходя из выявленных проблем, вы сможете вполне безопасно убрать лишние, не работающие элементы, сократив избыточный функционал и сделав жизнь ваших пользователей чуточку лучше. Или же обратите пристальное внимание на страницу, где происходит большой процент прерывания и обязательно найдете причину, что сразу же скажется на увеличении конверсии.
Тем не менее, не смотря на кажущуюся простоту, любые изменения в уже работающем проекте рекомендуется делать через сплит-тестирование. Таким образом, во первых можно уберечься от неправильных изменений, во вторых точно оценить эффективность внедренных изменений.
A/B – тестирование
A/B – тестирование позволяет проверить эффективность нескольких вариантов страниц. Например, вы решили проверить гипотезу, что увеличение размера кнопки «Купить» и ее цвета на яркий, контрастный способно увеличить вероятность ее нажатия.
Для этого необходимо создать копию страницы с внедренными изменениями и доступную, например, по GET-параметру ?split.
То-есть, если пользователь открывает страницу: _http://site/category/product — он видит старое содержание, а по адресу _http://site/category/product?split открывается страница с большой и яркой кнопкой.
Теперь, используя инструмент «Отчеты/Поведение/Эксперименты/Создать эксперимент» вы сможете очень быстро запустить ваш эксперимент и проверить гипотезу.
Механизм работы A/B – теста заключается в случайном показе выбранному объему аудитории одного из проверяемых вариантов и замером эффективности достижения выбранной для эксперимента цели.
Вот так выглядит один из отчетов:
В целом, я рекомендую проверять абсолютно все вносимые изменения, будь то внедрение совершенно нового дизайна страницы или изменение текста описания товара. Но лучше всего A/B – тесты работают на небольших изменениях, так как в случае с изменением всей страницы будет сложно понять что именно влияет на результат.
Эпилог
Возвращаясь к истории с Семеном, теперь становится ясно, почему его попытки слепого изменения могли бы обернуться реальным провалом всего бизнеса.
Любое изменение в уже работающем проекте должно иметь под собой почву из аналитических данных и проверятся с помощью тестов. Особенно это важно для высоко посещаемых проектов со сформировавшимся ядром аудитории, как в случае с Семеном. Ведь, какой замечательный и идеальный интерфейс бы не внедрили на его сайт, большая часть аудитории все равно была бы жутко недовольна, ибо привычки уже сформированы, а точечное улучшение воспринялось бы куда лучше. Вспомните хотя бы iOS7.
P.S. В материале описываются принципы работы с классическим Google Analitycs, но уже на смену ему приходит Universal Analitycs, где метод учета событий несколько отличается.
P.P.S. Если материал показался вам интересным, пишите в комментариях, о чем бы вы хотели узнать еще – с удовольствием поделюсь своим практическим опытом проектирования интерфейсов.
