ГлавнаяБитриксБитрикс хабр

Конверсионный дизайн: создание онлайн-сервисов, которые искренне полюбят пользователи. Битрикс хабр


Как не надо разрабатывать проект на Битрикс / Хабр

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

Здесь я постараюсь не акцентировать внимание на стандартных «worst practice» при программировании на PHP, типа наплевательского отношения к выборам имен переменных и функций, излишних запросов к БД в цикле, отсутствия проверок пользовательских данных в формах, игнорирование комментариев и тому подобного. Я попытаюсь коснуться именно моментов, свойственных разработке на Битриксе, которые в последствии позволят избежать негодования и проклятий в ваш адрес от программиста, которому выпало сопровождать ваш код. И да, нередко этим программистом будете оказываться вы сами через год, или более, когда уже совершенно забудете, зачем вы вставляли сюда тот или иной костыль.

«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте» (с) Джон Ф. Вудс Первое, и самое, на мой взгляд, важное — ради всего святого, используйте папку local. Это просто жизненно необходимо при использовании системы контроля версий – все, что вам нужно – добавить в исключения папку /bitrix/. Всё. Далее практически вся разработка ведется только в ней. Это заметно упрощает поиск нужных файлов и компонентов в последствии, помогает не засорять репозиторий лишними файлами, да и вообще – приводит дерево проекта в более опрятный, «человеческий» вид.

Не модифицируйте ядро. Даже если вы уверены, что оно не будет обновляться. Даже если так быстрее. Даже если вам лень. Забудьте эту мысль, как страшный сон. Если необходимо изменить логику работы стандартного компонента – перенесите его в новое пространство имен /local/components/modify/ и работайте с ним. То же самое касается модулей, гаджетов и activities бизнес-процессов.

Не засоряйте файл init.php. Объединяйте функции для работы с каким-то конкретным модулем или функционалом в класс, весь этот класс записывайте в отдельный файл, а в init.php просто подключайте эти файлы и прописывайте обработчики событий. Мне встречались файлы init.php по 500Kb, где в кашу были смешаны функции, определение констант, классы и инициализация обработчиков. Разумеется, когда приходилось разбираться в этих файлах, я сыпал проклятиями на своих предшественников.

Следующий пункт не касается случая разработки готовых решений для Marketplace, когда целью ставится сделать максимально настраиваемый функционал из публичной части для конечного потребителя. Если вы работаете над конкретным проектом, по конкретному ТЗ – не стоит пытаться сделать унифицированный шаблон для компонента на все случаи жизни. Лично я придерживаюсь философии – лучше несколько простых шаблонов, использующихся для разных целей, чем один универсальный, но в котором сам черт потом ногу сломит. Разумеется, в каждом конкретном случае нужно отталкиваться от того, что есть – техзадание, варианты реализации и тому подобное, но забывать про «Бритву Оккама» все-таки не стоит. Как пример приведу один проект лизинговой компании, который мне довелось править. Сам проект, конечно, был реализован ужасно, на настоящий ужас был в страницах раздела каталога услуг. У каждого из пяти разделов была собственная верстка, на которых отличалось как положение блоков на странице, так и в принципе наличие некоторых из них. И для всех пяти страниц использовался один шаблон с кучей if-else, дублированием вызовов компонентов, подключением стилей и скриптов, которые, к тому же, периодически конфликтовали друг с другом. Как итог – огромный файл, в котором разобраться «без поллитры» было смерти подобно. Хотя, казалось бы, что мешало сделать 5 разных шаблонов и не создавать трудностей на ровном месте?

Используйте API. Не изобретайте велосипеды там, где это не нужно. Юзайте документацию – весь продукт довольно хорошо описан, а так же каждую функцию можно посмотреть детально на bxapi.ru.

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

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

Подключайте css и js с помощью API. До сих пор повсеместно встречаю подключение скриптов и стилей с помощью html-тегов. Используйте объект класса \Bitrix\Main\Page\Asset и функции addJs() и addCss(). Это позволит объединять файлы и, в последствии, кешировать их одним нажатием чекбокса в настройках главного модуля

Ну и напоследок, ошибка касается не только Битрикса, но уж больно часто я стал встречать проблемы, связанные с ней. Проверяйте на пустоту массив с результатами выборки. Как пример, последний раз встретился с данной проблемой при работе с одним интернет-магазином. Жалоба: страницы иногда грузятся по 16 секунд. С чем связано – не ясно. Методом проб и ошибок выяснил, что страницы грузятся неприлично долго только тогда, когда корзина пустая. Казалось, с чего бы? Как выяснилось, у корзины при наведении появлялось всплывающее окно, в котором отображались изображения товара, положенного в корзину. Ну что сделал предыдущий разработчик? Взял результат работы компонента «маленькая корзина» и в файле result_modifier.php сделал вызов GetList() товаров для выборки изображений с фильтром из массива ID товаров, потом из результатов выборки в массив соответствующего товара добавлял src изображения. В итоге, когда товаров в корзине не было, фильтр уходил пустой, и в выборку попадал ВЕСЬ каталог товаров. Ну а дальше цикл по каждому и… имеем то, что имеем. Ясно, что на этапе разработки при тестовых 15 товарах это было незаметно, и проблемы возникли уже в боевых условиях. Хотя, казалось бы, чего стоило поставить проверку на empty($arResult[‘ITEMS’])…

На этом я заканчиваю свой личный топ «worst practice», касательно разработки на Битрикс. Если хоть кому-то данная информация поможет избежать ошибок в будущем и улучшить свой стиль разработки, значит это было не зря.

habr.com

Автотесты, ночные сборки, экстремальный Agile. Как мы тестируем наши продукты

Наше тестирование — большой продукт, сжатые сроки, огромная ответственность.

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

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

Разработчики, собирают пачку кода в отдельную версию. И пишут описание: «Новый интернет-магазин в облаке. Изменения такие-то. Добавили кучу новых страниц». И обязательно прикладывают огромный changelog с несколькими сотнями коммитов.

Всё это поступает к тестировщикам. Этот процесс я называю «экстремальным Agile» — мы работаем по чётким итерациям. Отклоняться от этих правил тестирования нельзя.

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

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

Раньше мы делали так. Составляли подробные описания прецедентов: «Нажимаем сюда. В поле ввода пароля должны появиться кружочки. Если они не появляются, что-то не так».

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

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

Пример — список кейсов по работе с задачами в «Битрикс24».

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

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

Дальше мы за несколько этапов проверяем, как выполняются системные действия.

Этапы тестирования

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

Параллельно с прогоном автотестов мы делаем:

1 этап
— Изучаем описание изменений от разработчиков.

Смотрим, как должно быть по ТЗ. Сравниваем с тем, как модуль сделан в реальности. Но главное — учимся смотреть на продукт и изменения с точки зрения здравого смысла и обычного пользователя.

Удобен ли рабочий сценарий? Всё сделано «по-человечески»? Параллельно проводим ещё и usability-тестирование.

Это не всегда получается — изменений огромное количество. Но мы всё равно подсказываем разработчикам, когда какой-то сценарий можно сделать удобнее.

Мы автоматизировали огромную часть рутины. И постоянно думаем что можно «докрутить».

Вопросы к разработчикам мы обсуждаем в отдельных чатах под каждое обновление. У нас нет «сломанного телефона» — в чате присутствуют все сотрудники, причастные к выпуску.

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

— На этом этапе мы «отлавливаем» большинство ошибок. Разработчик может что-то упустить в «обычном» описании, но changelog покажет все ошибки.

Недавно был курьёз. Разработчик внёс изменения в текст локализованной версии продукта. На французском языке.

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

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

3 этап
Затем начинается третий этап — анализ обращений клиентов по ошибкам в продукте:

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

Я несколько раз предлагал коллегам найти что-то другое. Начинали анализировать и каждый раз оказывалось, что в Mantis есть все что нам нужно. Мы отлично интегрировали её в работу: связали с «открытыми линиями» и техподдержкой.

Весь журнал обращений клиентов по поводу ошибок мы берем в Mantis.

В каждое мини-обновление у нас включаются и фичи, и исправления багов, которые нашли клиенты и тестировщики.

Разработчик утверждает, что ошибка исправлена — мы проверяем. Если ошибка не исправлена, возвращаем тикет в работу.

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

4 этап
После верификации переходим к четвертому этапу — повторному прогону тестового плана.

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

5 этап
Пятый этап — сборка пакета обновлений и выгрузка в эталонную среду тестирования: Она находится в облаке Amazon и представляет собой отдельный портал «Битрикс24».

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

6 этап
На шестом этапе мы организуем группы закрытого тестирования.

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

К этому этапу почти все ошибки уже выловлены. Пользователи рассказывают, насколько им удобно работать по разным сценариям. Можно назвать это дополнительyым usаbility-тестированием.

7 этап
Потом наступает очередь седьмой этап — полузакрытое тестирование:

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

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

Здесь мы тоже оцениваем удобство работы с продуктом, удобство сценариев.

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

Этот этап может занимать 2-3 недели. Мы постоянно вносим изменения по фидбэкам клиентов.

После тестирования на стейдже обновление выкатывается в production. А мы радостно пишем обучающие статьи и снимаем видео.

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

Cloud first

Многие клиенты жалуются, что мы выпускаем обновления сначала для облачной версии «Битрикс24». Пока нам не удалось построить процесс тестирования и выпуск продукта так, чтобы синхронно выпускать обновления и для «облака», и для «коробки».

Выпуск коробочного обновления — более сложный процесс. Если вы знакомы с обкаткой сырого продукта, то знаете, что такое тестовая среда. В облаке у нас уже есть готовая инфраструктура с заданными версиями PHP и MySQL со своей кодировкой. Там всё настроено и работает — можно ставить продукт и спокойно тестировать.

С «коробкой» все по-другому. Вариативность «сред» у клиентов огромна. Мы стараемся стимулировать пользователей к переходу на более высокие версии PHP, но многие делают это неохотно.

По факту, немалая доля клиентов начинают менять версию PHP, только когда их заставляют хостеры. Добавьте к этому разнообразие версий MySQL и кодировок.

Вот почему тестирование «коробки» намного сложнее и дольше по времени.

Автотестирование

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

Созданием автотестов у нас занимается специальный отдел.

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

Поэтому мы разбили большие сценарные автотесты на более мелкие независимые сценарии, кейсы.

Для работы с автотестами у нас есть самописный фреймворк на .NET и отдельный фреймворк для работы с базой.

Почему у нас продукт на PHP, а фреймворк для автотестов на .NET?

По моему многолетнему опыту работы, для автотестирования UI подойдёт любой фреймворк, который будет работать. Мы используем .NET, потому что он отлично подключается к UI и прекрасно работает с Selenium, ну и мне он просто нравится.

Как проходит среднестатистический автотест?

То же самое с очисткой данных. Проверили сценарий. Если всё хорошо, то задачу удаляем не через интерфейс, а через API — вызываем метод удаления задачи. Робот быстро очищает данные за собой.

Раньше мы тестировали только через интерфейс.

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

Smoke-тесты и ночные автотесты

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

Обычно мы используем их для финальной проверки.

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

Сейчас наш полный цикл ночных автотестов наконец-то стал укладываться в ночное время. Раньше он занимал около 32 часов. Ускорить автотесты удалось с помощью виртуальных машин и постоянных оптимизаций фреймворка и самих тестов.

А вот чего в нашем процессе тестирования нет, так это постоянной интеграции. Она нам не подходит, потому что есть накопленное «историческое наследие».

Мы не можем отказаться от какой-то части инфраструктуры, которая очень велика и сложна. Так что мы пока робко пробуем внедрить небольшие элементы классической continuous integration.

Ночные сборки

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

Как это происходит?

Самописная система обращается к сборщику обновлений и автоматически ставит все возможные обновления. Смотрит, что упало на этапе установки.

Затем машина собирает все имеющиеся дистрибутивы — у нас их 8 редакций — и ночью развёртывает локальные установки.

Ночные билды мы не выкладываем в открытый доступ. Система опять фиксирует, всё ли установилось. Если всё в порядке, запускаются все автотесты.

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

Модульные-тесты

Большая часть наших тестов — UI, а не Unit. Модульные тесты мы используем только для важных компонентов: главный модуль, CRM, интернет-магазин.

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

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

Для прогона модульных тестов используем стандартный инструмент PHP unit. Просто вызываем метод. Смотрим, как он работает с параметрами, которые даются на вход. И смотрим ответ.

URL checker

Это моя давняя идея. Возможно, кому-то она будет полезна.

Робот на вход:

У нас есть готовый список возможных ошибок: ошибка 404, fatal error, ошибки базы, JS-ошибки, невалидные символы, битая картинка, ошибка 500.

Всё, что можно найти и вытащить из кода страницы, робот складывает в лог со скриншотами.

Написать такого робота крайне просто, но он может сэкономить много времени.

Component checker

Наш component checker работает так: Эффективный и простой тест для веб-разработки.

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

Визуальный эксперимент

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

На них сразу видно, какие элементы продукта с чем связаны: на что влияет сохранение заказов, или что влияет на само сохранение? Что и как может повлиять на схему складского учета?

Так тестировщик может быстро оценить — на какие элементы повлияют изменения в том или ином компоненте.

Качество тестирования

Мы отказались от избыточного тестирования. Я сторонник принципа достаточности.

Сейчас мы очень мало тестируем на «защиту от дурака». Например, в поле ввода денежной суммы, скорее всего, не будем вводить буквы.

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

Но для нас этот подход перестал работать — в наших реалиях хватает «достаточного» тестирования.

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

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

* * * Мне интересно ваше мнение о прочитанном. Как проводится тестирование в вашей компании?

habr.com

Как достичь рейтинга А+ для SSL-сертификата на вашем сайте, и другие аспекты безопасности хостинга

В последние годы хостинг превратился в commodity — полноценный продукт, привлекательность которого во многом определяется сопутствующими услугами. А поскольку особое значение сегодня имеет информационная безопасность веб-сайтов, то одним из важнейших аспектов хостинга являются SSL-сертификаты. Вся электронная коммерция так или иначе проходит через хостинг, поэтому необходимо понимать, насколько безопасно, правильно и удобно выполняются все бизнес-операции. Подробнее об этом рассказал спикер компании Rusonyx на партнёрской конференции «1С-Битрикс». Данные, обнародованные Министерством внутренних дел России, наводят на грустные размышления:

В 2013 году количество киберпреступлений — около 11 тысяч инцидентов — составило 30% от общего объёма правонарушений. В 2015 году доля киберпреступлений выросла ещё больше. Хакерским атакам регулярно подвергаются довольно серьёзные проекты, которым мы доверяем свои деньги: в первую очередь, интернет-магазины и банки.

Наверняка кому-то из вас приходилось настраивать платёжные системы в продуктах CMS «1С-Битрикс». Любая платежная система вынуждает нас использовать защищённое HTTP-соединение, SSL-сертификаты. Это прихоть или действенная мера безопасности? Чтобы в этом разобраться, давайте посмотрим, что собой представляет SSL-сертификат.

Что такое SSL-сертификат

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

Как работает SSL-сертификат

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

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

Какие бывают виды SSL-сертификатов

  1. DV SSL (Domain validation). Этот сертификат подтверждает доменное имя. У него есть подтип — WildCard. С помощью этого подтипа мы можем защитить все поддомены на одном уровне. К примеру, либо ssl.site.ru, либо ssl2.ssl.site.ru.
  2. OV SSL (Organization validation). Он подтверждает домен и организацию. То есть когда вы посылаете CSR-запрос в сертификационный центр, они проверяют, действительно ли существует организация с таким ИНН, после чего выписывают вам сертификат. У него также есть подтип WildCard.
  3. EV SSL (Extended validation). Этот сертификат подтверждает доменное имя и организацию. Для его получения вам придётся предоставить полный пакет документов о своей организации, то есть осуществляется расширенная проверка. На выписывание этого сертификата требуется больше времени, по сравнению с другими типами сертификатов, и стоит он гораздо дороже. У него нет подтипа WildCard, но на замену ему приходит MDC. Он позволяет нам в принудительном порядке перечислить количество доменов, которое будет защищать этот сертификат.
  4. UCC SSL. Сравнительно малораспространённый вид сертификата. В основном используется для защиты почтовых служб, таких как Microsoft Exchange Server. При этом данный сертификат позволяет защищать до 100 доменов.
  5. Organization ServerSign GlobalIP. Защищает все доменные имена, расположенные на одном IP-адресе.
  6. Code Signing Certificate. Используется разработчиками. Данным сертификатом можно подписывать программное обеспечение, то есть он подтверждает автора ПО, а также гарантирует, что данный продукт не изменялся с тех пор, как была нанесена цифровая подпись.

Тестирование сервера

Можем ли мы быть полностью уверены в том, что данные наших пользователей и клиентов сайта находятся в безопасности из-за одного лишь факта установки SSL-сертификата? Для ответа на этот вопрос давайте рассмотрим три аспекта: Для примера я выбрал сервер, на котором был предустановлен ряд приложений. Front-end —NGINX, back-end — Apache.

Ресурс SSL LABS принадлежит компании QUALYS, которая с 1999 года занимается облачной защитой, так что я считаю, что ему можно доверять. Прямо в панели можно установить SSL-сертификат, без каких-либо вмешательств в настройки сервера. Рейтинг довольно плохой — “С”. И первое, на что я хочу обратить внимание, — сервер до сих пор поддерживает старый протокол SSLv3, уязвимый к POODLE-атаке, в ходе которой можно перехватывать и расшифровывать данные. Злоумышленник может намеренно заставить нашего клиента использовать неактуальный уязвимый протокол SSLv3, и воспользоваться этим в своих целях.

Оптимизация сервера

Я приведу список оптимизаций только для NGINX, настраивать Apache нужно приблизительно так же.

В первую очередь, логично будет отключить на сервере протокол SSLv3. Это делается в виртуальных хостах, в server block: в директиве ssl_protocols просто убираем SSLv3, оставляя TLSv1, TLSv1.1 и TLSv1.2. Конечно, надёжнее будет оставить только TLSv1.1 и TLSv1.2, но можно столкнуться с некоторыми проблемами, о них я скажу ниже.

Второе, что нам попадается на глаза при тестировании — это старый набор шифров.

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

После того, как мы настроили протоколы, по которым будем работать, а также установили на сервер актуальные шифры, пора позаботиться о том, чтобы клиент чётко выполнял наши указания. Для этого необходимо установить приоритетность шифров, включив директиву ssl_prefer_server-ciphers on. В этом случае при использовании протоколов SSLv3 и TLS серверные шифры более приоритетны, чем клиентские. Это позволяет защититься от многих атак типа Logjam, Beast, Freak.

Второе, за что SSL LABS поставил нам не самый высокий рейтинг, это использование слабых параметров файла ключей Diffle-Hellman.

Этот ключ генерируется с помощью команды openssl dhparam -out, где нужно указать путь к нашему будущему ключу и его длину.

openssl dhparam -out /etc/pki/tls/dh.pem 2048 Многие из вас, возможно, скажут, что необходимо использовать ключ длиной 4096. Возможно, это безопаснее. Но это замедлит скорость загрузки сайта. И к тому же 2048 — это, пока что, довольно безопасная длина ключа.

Следующее, на что нужно обратить внимание, — это механизм HSTS. Чтобы установить заголовок Strict Transport Security, нам необходимо перекомпилировать NGINX вместе с модулем HTTP header.

add_header Strict-Transport-Security max-age=15768000; После перекомпиляции мы добавляем заголовок Strict Transport Security. Тем самым мы заставляем клиента, зашедшего по HTTP-протоколу, использовать HTTPS-протокол. С одной стороны, это хорошо, но с другой — влияет на SEO-оптимизацию. Поэтому перед тем как устанавливать данный заголовок, лучше проконсультироваться с коллегами, которые занимаются SEO-оптимизацией вашего сайта.

Далее, мы видим, что у нас отключён OCSP Stapling:

Протокол OCSP (Online Certificate Status Protocol) был создан на замену старого варианта CRL. Сертификационные центры приблизительно раз в неделю генерировали список отозванных сертификатов. Когда браузер подключался к нашему защищённому серверу, он скачивал список отозванных сертификатов, проверял, нет ли в нём нашего сертификата, и если не находил, то подключался к сайту. Но это довольно длительная процедура, поэтому был разработан более быстрый протокол OCSP. Правда, у него есть другой недостаток, но об этом ниже.

Включить Stapling можно в Server block с помощью директив

ssl_stapling on; ssl_stapling_verify on; Также нужно указать путь к нашему корневому сертификату:ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates; И установить resolver: resolver <IР DNS resolver>; Обычно ставят 8888. Это Гугловский public DNS, но если у вас есть свой DNS на сервере, то я бы рекомендовал поставить localhost.

Теперь о недостатках самого OCSP.

Дело в том, что проверка сертификата на отозванность состоит из четырёх стадий:

Помимо того, что мы выполняем лишние действия, мы также нагружаем сам сертификационный центр. Представьте, если каждый клиент подключается к серверу и запрашивает лично. Чтобы этого не происходило, мы включаем OCSP Stapling. Это позволяет веб-серверу самому подключиться к OCSP Responder и скачивать информацию о том, не отозван ли его сертификат. Эту информацию сервер кэширует у себя. Далее мы подключаемся только к DNS, потом к веб-серверу и получаем данные вместе с SSL-переговорами (handshake).

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

Обычно переговоры состоит из трёх-пяти этапов, а SPDY позволяет всё сделать за одно соединение. Для его включения нам сначала придётся перекомпилировать NGINX, включив модуль spdy. Далее потребуется обновить OpenSSL до версии не менее 1.0.1а. Включить сам протокол можно в Server block с помощью директивы Listen:

Listen 443 ssl spdy Следующий нюанс, на который я хотел бы обратить ваше внимание, это Session Resumption, кэширование. Когда мы в первый раз подключаемся к серверу, клиент передаёт ID сессии, сохраняющийся на сервере. И когда мы повторно подключаемся к нему, то при совпадении ID сессии уже не требуется выполнять SSL-переговоры, что ускоряет загрузку. Включить Session Resumption можно следующими директивами:ssl_session_cache shared:SSL:50m; ssl_session_timeout 5m; Согласно моему тестированию, кэширование позволяет снизить среднее значение SSL Negotiation на 10 мс.

Упрощение задачи

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

Есть такой ресурс, как Mozilla SSL Configuration Generator. На нём можно в несколько кликов сформировать уже готовый виртуальный хост с нужными настройками, которые позволят вам получить в SSL LABS рейтинг «А». К примеру, мы выбираем веб-сервер NGINX, уровень шифрования modern, то есть самый безопасный, и указываем версию сервера. После генерирования нашего конфигурационного файла мы получаем все директивы, которые необходимы.

Недавно появился ещё один интересный проект — Let’s Encrypt. Их сертификаты защищают только доменное имя и субдомен. Также вы не получите зелёной строки, о которой я говорил — Extended validation certificate, то есть вы не подтверждаете организацию. Авторы заявляют, что их главная цель заключается в том, чтобы весь HTTP-трафик по умолчанию переводить в HTTPS. В принципе, неплохая идея. Я решил протестировать этот сервис. Скачал с их сайта Python-плагин, минут 30 его устанавливал, потому что он ещё не оптимизирован под многие версии Python. Но всё же мне действительно удалось довольно быстро установить сертификат. Я получил DV — Domain validation certificate, который подтверждал мой домен, а также субдомен, автоматически включённый в мой веб-сервер.

Но есть более быстрый способ.

Если ваш сервер поддерживает предустановленную панель PLESK, то в разделе «Расширения» вы можете в два клика скачать и установить расширение Let’s Encrypt. После введения вашего домена e-mail адреса он будет автоматически установлен на сервер. Важно отметить, что данный сертификат выписывается только на 90 дней, и его необходимо будет обновлять. Это можно очень просто сделать в панели PLESK, просто нажав кнопку Renew.

Как же достичь рейтинга А+?

Как же, в итоге, достичь рейтинга «А+»? Нужно выполнить следующую оптимизацию:
  1. Отключить уязвимые SSL-протоколы (SSL v1, v2, v3)
  2. Актуализировать набор шифров.
  3. Сгенерировать надёжный ключ dh_param.
  4. Включить механизм HSTS.
  5. Ускорить SSL-переговоры с помощью OCSP Stapling.
  6. Ускорить SSL-переговоры с помощью SPDY.
  7. Включить кэширование.
Вот результат проделанной нами работы:

На что следует обратить внимание?

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

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

О безопасности сервера

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

habr.com

создание онлайн-сервисов, которые искренне полюбят пользователи / Блог компании 1С-Битрикс / Хабр

Термин «конверсия» многие годы был связан с гражданской продукцией предприятий ВПК. Но у IT-специалистов скорее возникнет совсем иная ассоциация. Однако сейчас мы хотели бы поговорить о таком понятии, как конверсионный дизайн. Общепринятый подход к разработке сайта выглядит примерно так: есть блок по веб-дизайну, есть блок по вёрстке, по разработке и так далее. Но, в течение последних двух-трёх лет всё начало стремительно меняться. Сам термин «веб-дизайн» постепенно умирает, потому что кроме браузера у нас появился адаптивный дизайн. По большому счёту, веб-дизайн перестал существовать в таком однозначном виде. Появились всякие дополнительные терминологии, как сервисный дизайн — data-driven design, который, в том числе, является конверсионным. Этому явлению посвятили своё выступление на киевской партнёрской конференции «1С-Битрикс» управляющий партнер компании AIC Сергей Попков и руководитель отдела продуктовой аналитики AIC Виталий Черемисинов. Для начала давайте рассмотрим текущие тенденции. В целом, сегодня ситуация мало чем отличается от 2015 года. Но мы нашли пару любопытных примеров того, что, как нам кажется, будет актуально именно в 2016 году.

Текущие тенденции

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

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

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

Четвёртая тенденция — широкое внедрение анимации. Она призвана компенсировать графический минимализм, избавление от «излишеств». Теперь везде используется анимация микровзаимодействий, разработчики работают больше с Javascript и HTML5, анимируют интерфейсы, чтобы они выглядели интереснее.

Так возникла ещё одна — пятая — тенденция: пространственные интерфейсы, когда сайты начинают работать без перезагрузок. Всё подгружается в фоне: видео, графики, картиночки, всё летает, прыгает… Для аналитиков это просто головная боль: ни одного физического URL, всё на «якорях». Дополнительная интеграция, не всегда удобно настраивать. Например, новый сайт крупной производственной компании Acme:

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

Сущность дизайна

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

Какая картинка вам нравится больше? Наверняка автомобиль, ведь он такой красивый. Но все забывают, для чего на самом деле нужен автомобиль. Многие приходят в автосалон и выбирают ту модель, которая нравится. И немногие задают себе вопрос: а как поедет этот автомобиль? Зачастую покупают, даже не воспользовавшись тест-драйвом.

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

Согласно Википедии, определение «дизайна» звучит так:

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

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

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

Взгляните на новый сайт авиакомпании Virgin America. Они которая полностью отказались от какого-то эмоционального посыла на главной странице.

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

В классическом понимании слова «дизайн» здесь нет никакого дизайна. Среднестатистический заказчик, увидев такой макет, скажет, что ему не нравится. Это как-то сухо. Нет дизайна. Где картинки? И лишь в самом конце процесса выбора билета Virgin America воспользовалась эмоциональной составляющей: при заполнении своих данных можно выбрать иконку настроения, и следующий пользователь, ваш потенциальный сосед, будет видеть ваше настроение и лицо. При этом в остальном сайт решает исключительно сервисные задачи.

А вот, для сравнения, сайты отечественных авиакомпаний. Здесь мы видим тот самый дизайн, к которому привыкли.

Почему исторически сложилось так, что изначально в сети превалировал эмоциональный дизайн? Когда интернет только появился, сайты были очень простыми. Они представляли собой набор статичных страничек, и с этим ничего нельзя было сделать. Даже создание формы заявки была достаточно нетривиальной задачей. Поэтому вебмастеры ударились в эмоциональный дизайн. Всем было важно, чтобы конкретно их сайт удивил всех своим внешним видом. Позднее начали появляться сайты для онлайн-продаж, появились поисковики, появилась выдача. Начали появляться более удобные формы. И в итоге мы пришли к глобальным онлайн-сервисам.

Для них эмоции в дизайне имеют очень мало общего с тем, как должны работать эти сервисы. И даже когда потенциальный заказчик говорит: «Я хочу такое приложение, как Uber. Мне нравится этот дизайн», то, скорее всего, он имеет в виду уже не графическое оформление интерфейса, а ту лёгкость и логичность, с которой работает это приложение. Чтобы подойти к заказчику с правильной стороны, надо менять процесс общения, помочь заказчику сформулировать запрос. Подавляющее большинство разработчиков подходят к этому изначально неверно: «Зачем вам нужно менять дизайн сайта?» — «Он морально устарел». То есть заказчику кажется, что дизайн сайта всего лишь выглядит не слишком современно. Хорошо, если он сам доходит до формулировки вроде: «Наш сайт плохо отображается на мобильном телефоне». Это уже предпосылка к тому, что заказчик мыслит в правильном направлении.

Ещё один интересный пример — сайт Почты России. Когда-то он был таким:

А новый сайт работает уже по сугубо сервисному принципу:

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

Обновлённый сайт Госуслуг. Сюда пользователь заходит для оформления документов, оплаты штрафов или налоговой задолженности. Визуального дизайна здесь как такового уже нет.

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

Веб-дизайн

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

Постоянные изменения в технологиях и платформах приводят к ряду проблем. Вчера был мобильный телефон, сегодня появились часы, завтра это может быть какой-то нейроинтерфейс. Уже витают в воздухе новые идей, все ждут Zero UI, когда красота интерфейса будет заключаться в его отсутствии. Всё это постоянно влечёт изменения в рабочих процессах по созданию вебсайтов. И появление конверсионного дизайна тоже обусловлено развитием технологий, аналитических систем данных.

Как раньше определяли эффективность дизайна? Нам было важно, чтобы заказчик его принял, и не важно, понравилось ли ему. В редких случаях делали какие-то опросы и тестирования, спрашивали у своих близких и друзей. Посмотрели, «круто выглядит, не хватает какой-то фишечки». В результате долго игрались со шрифтами, кнопками и так далее.

А сейчас это может выглядеть приблизительно так:

Var. A: CTA 4,75% Retention 3w >>>Win<<< Var. B: CTA 4,35% Retention 3w

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

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

Как часто пользователь возвращается к вам? И сколько, в среднем, он проводит времени в вашем сервисе? Например, по статистике Facebook Messenger пользователи чаще всего возвращаются к ним после того, как они добавят к себе в приложение 5 друзей, и эти 5 друзей отправят минимум 10 сообщений. То есть вполне себе конкретный, осязаемый критерий качества продукта. По факту, интерфейса там нет. Есть только продуктовые метрики. Юнит-экономика — это описание жизни вашего продукта с точки зрения финансов: сколько стоит привлечение нового пользователя, сколько стоит возвращение старого, какой размер среднего чека у пользователя, и так далее.

Data-driven design

Data-driven design — это создание дизайна на основе каких-то данных. Чем больше мы используем разноплановых метрик, аналитических инструментов и методологий тестирования, тем больше доказательств эффективности дизайна мы имеем.

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

Есть такой глобальный сервис https://www.simple.com/, финансовый агрегатор; за последние 4 года они 3 раза сменили дизайн сайта. В чём смысл? Когда стартап только запускается, им важно произвести максимальное впечатление на новых пользователей, завлечь гиков, поэтому они делают максимально сногсшибательный дизайн. Когда набирается первичная стабильная аудитория, когда пользователи прочувствовали, что продукт уже достаточно качественный, то приходит время гнать конверсию. Нужно как можно больше регистраций. И тогда владельцы сервиса начинают менять дизайн в сторону повышения конверсии в регистрации, и этот дизайн может быть уже не таким красивым и сногсшибательным, с кучей анимации. Новый дизайн должен решать иные задачи.

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

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

Упрощённо стадии разработки сервисного дизайна можно представить в таком виде:

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

Плоский и объёмный

Как-то дружной компанией мы обсуждали развитие мобильных платформ: iOS, Android и Windows Phone. И поняли, что пользователь, который взаимодействует с мобильным устройством, всегда привыкает к какой-то инфраструктуре. Когда он открывает то или иное мобильное приложение, то действует в рамках унаследованных шаблонов. Навигация везде одинаковая, иногда даже схожи элементы UI.

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

Пользователям Windows до 10 версии мы показали два варианта интерфейсов: с плоскими кнопками и с объёмными. В результате среди пользователей, работавших с объёмными (выпуклыми) кнопками, и вообще с дизайном, который по своим паттернам схож с дизайном ОС, был отмечен рост конверсии (заказ продукта) на 10%.

Товарная витрина

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

Например, при подключении к новому интернет-провайдеру проверит адрес, выберет тариф и пойдёт дальше. В действительности всё оказалось не так. Пользователи игнорировали проверку адреса, сразу выбирали тариф, доходили до конца и получали сообщение «выбери адрес». Их это несколько обескураживало, и они уходили с ресурса, потому что в самом начале проигнорировали первый пункт. Тогда мы решили заставлять пользователей сначала проверить свой адрес, и только после этого выбирать тариф. Заказчик очень долго сопротивлялся: «Как же так? Мы такую красивую витрину закроем? У нас же потрясающие тарифы!». Мы уговорили его последовать нашему предложению, и оказалось, что ограничение в выборе и концентрация на определённых объектах, пусть даже не всегда удобных, увеличивает определённые продуктовые показатели. Конверсия выросла на 20%.

Индикатор прогресса

Если вы откроете какой-нибудь UX Кit, или почитаете западные блоги с рекомендациями по оформлению страниц и форм, то везде будет написано: «Делайте индикаторы прогресса. Говорите своим пользователям, что необходимо проходить из точки А в точку Б и рассказывайте о промежуточном этапе». Везде написано, что пользователю важно видеть, куда он идёт.

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

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

Воронка потребления продукта

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

Начали обсуждать с пользователем. Сразу решили, что у нас огромная проблема в «Оценке и контактах», потому что пользователь на этом этапе пользователь впервые получает оценку стоимости. Соответственно, клиент всё это время думал, что проблема в цене. Мы провели небольшой A/B-тест: 1) после проведения оценки показывалась стоимость машины, 2) стоимость не показывалась. Когда пользователю предлагалась некая стоимость, конверсия увеличивалась, но не так разительно, как хотелось бы. То есть этот пункт можно было проигнорировать.

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

Целевая аудитория

С вышеупомянутым сервисом была связана ещё одна поучительная история. Всю свою рекламную активность клиент осуществлял исходя из того, что его целевая аудитория — владельцы достаточно бюджетных машины, дешевле 10 тыс. долларов. Но оказалось, что намного лучше покупают владельцы машин более высокого класса, порядка 15 тыс. долларов. То есть потребителями услуг сервиса были представители совсем не той аудитории, на которую ориентировался заказчик. Хотя эту информацию можно было получить за полчаса, покопавшись в Google Analytics или проанализировав данные из CRM-системы.

Привычка к линейности

И последний пример, снова воронка потребления.

Но в чём проблема воронки? Разработчик идёт в Google Analytics, строит воронку и понимает, что идут колоссальные потери по пути от «Продукта» до «Формы» и до «Спасибо». Он думает: «Что-то не так. Скорее всего, с продуктом какая-то беда». А как происходит в действительности? Допустим, пользователь хочет взять кредит в банке. Он сначала идёт на сайт, смотрит: «Ага. Такая-то процентная ставка. Столько-то я переплачу. Пойду посмотрю другие условия». И уходит.

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

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

Это говорит о том, что им нужно время, чтобы «созреть». И вокруг этих очень полезных данных мы можем построить персонализированные модели через “1С-Битрикс”, запустить триггерные рассылки, то есть взаимодействовать с пользователем персонально. А если мы будем смотреть исключительно на линейные процессы, то есть что происходит здесь и сейчас, то всегда будет шанс совершить большую ошибку.

habr.com

Prostoy-Site | Все права защищены © 2018 | Карта сайта