Оптимизация конверсии: список необходимых действий перед тестированием

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

С таким авто вы скоро окажетесь на обочине.

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

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

В долговременной возможности это ведет к более идеальному ритму тестирования.

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

Просматривайте кроме этого: Возврат к базам либо как создать HTML5 шаблон?!

Настройка «под капотом», либо Back-end

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

1. URL-структура

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

Посмотрим на примеры двух различных вариантов URL-таргетинга. Первый — это RegEx, в нем для соответствия основанных на тесте шаблонов употреблялся JavaScript. Второй — совпадение подстроки (Substring Match), являющейся в этом случае заглавием категории с двумя косыми линиями, по одной с каждой стороны.

RegEx

Продукты для включения:

  • www.test.com/ab82
  • www.test.com/F42
  • www.test.com/september/sale98

Продукты для исключения:

  • www.test.com/F4255

Таргетинг:

  • RegEx: (ab82|F42|sale98)

Substring

Продукты для включения:

  • www.test.com/products/engines/brandengine/
  • www.test.com/products/engines/v6turbo
  • www.test.com/products/sale/september/engines/v8

Продукты для исключения:

  • www.test.com/products/sale/september/wheel/alloy

Таргетинг:

  • Substring: /engines/

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

Иначе, второй пример показывает компанию, структурировавшую все собственные категории и URL продуктов. В этом случае таргетинг основан на совпадении с подстрокой «/engines/» (двигатели) и разрешает вам исключить другие категории, к примеру «wheels» (колеса). Верная URL-структура свидетельствует беспроблемное стремительное тестирование.

2. Время загрузки сайта, либо «время первых штрихов»

Понятие «время первых штрихов» (Time to First Paint) относится к начальной загрузке страницы, при которой необязательно все ее элементы загрузились всецело, но пользователь видит, что что-то происходит. Сейчас люди не могут продолжительно удерживать внимание на одной вещи и скоро раздражаются, в то время, когда загрузка продолжается через чур продолжительно. Во время тестирования время первых штрихов может стать важной задачей для ответа, в особенности если вы сталкиваетесь с таким явлением, как мелькание уникального контента перед загрузкой тестируемого варианта (Flash of Original Content, FOOC), или с еще более медленной, чем в большинстве случаев, загрузкой.

Как же уменьшить время первых штрихов?

1. В рамках HTML вашей страницы:

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

2. Сделайте ваши JS- и CSS-файлы как возможно меньше, дабы они скоро загружались в пользовательский браузер. После этого соберите все JS и CSS в единый файл для каждого из этих двух типов. Это разрешит браузерам пользователей выхватывать контент из двух файлов вместо того, дабы обращаться к множеству файлов за нужными руководствами.

Считывать с 15 документов либо из двух сжатых — отличие очевидна.

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

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

Рекомендуем применять способ куки либо JavaScript, отсылающий ответ «правильно»/«неверно» (True/False). К примеру, в то время, когда пользователь входит, ответ может «быть», в то время, когда выходит — «False».

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

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

Данный календарный виджет выглядит мило, но достаточно ли он ценен, дабы оправдать его включение?

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

Хорошим решением будет независимое создание модального окна.

Просматривайте кроме этого: Переосмысление процесса Веб-дизайна

Front-end-настройка

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

1. Контрольных точек не должно быть большое количество

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

  • На мобильных устройствах — 320 и 420 пикселей
  • На десктопах и планшетах — 768px, 992px, 1024px и 1200px

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

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

Пример аналитики по видам устройств из Гугл Analytics

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

2. Прекратите вставлять изображения вместо текста в ваш UI

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

  • Неприятность 1. Сайт откликается на каждую контрольную точку, но применяемые изображения размываются.
  • Неприятность 2. В случае если вам нужно добавить ссылку в футер либо поменять текст call-to-action, приходится создавать совсем новое изображение.

Избегайте размытых calls-to-action: используйте кнопки, а не изображения

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

3. Сохраняйте HTML и CSS несложными

Прекратите вставлять CSS в HTML. Умеренно применяйте div-теги. Старайтесь не помещать все в таблицы.

Простота сослужит вам хорошую работу в будущем!

Никаких дополнительных div-тегов!

Поместив CSS в отдельный файл, вы сохраните собственный HTML чистым и станете совершенно верно знать, куда необходимо зайти для внесения трансформаций в CSS. Сокращение числа div-тегов, создающих секции в коде, кроме этого «очищает» HTML.

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

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

Дополнительный совет. Не обращайтесь к iFrames, в случае если это не есть критически нужным. Помещение страницы в рамки второй страницы очень сложно — не делайте этого.

4. Выберите стандарт для присваивания имен и ID

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

Принципиально важно определиться с корпоративным стандартом для HTML-их атрибутов и тегов. Включайте стандартизированные атрибутивные имена для классов и ID, кроме того для тегов перечня. И самое основное — не применяйте однообразные наименования классов для несвязанных элементов!

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

Тут опять возможно совершить параллель с вождением: принципиально важно иметь возможность выяснить, какой поворот нужен, второй либо третий, а не просто реагировать на команду: «Разверните».

Просматривайте кроме этого: Словарь терминов по фронтенду

Лучшие практики технического тестирования

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

1. В случае если имеете возможность редактировать в CSS — делайте это.

В этом примере вы видите в одном из столбцов код, написанный как stylesheet в CSS. Столбец справа демонстрирует ту же анимацию, написанную в JavaScript.

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

2. Не перетягивайте контент с вторых страниц при тестировании.

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

3. Наконец, маленький перечень того, что стоит и что не следует делать вашей технической команде:

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

Высоких вам конверсий!

По данным widerfunnel.com. Источник картины: Joel Dinda

Случайные статьи:

Важность Конверсии. Как Увеличить Конверсии? Как Повысить Конверсию?


Подборка похожих статей:

riasevastopol