Сегодня Дзен подкинул в ленте интересную статью с Клерк.ру "В Москве создана гигантская коррупционная ниша вокруг ФНС: сданы десятки тысяч поддельных отчетов по НДС. Ущерб на 300 млрд"
И я решил осветить похожую проблему в контексте создания сайтов.
Зачем мне нужен какой-то бета-тест?
Часто, при первоначальном общении с клиентом, когда обсуждаются потенциальные расходы на создание сайта, я слышу подобные вопросы в той или иной интерпретации.
Людей понять можно - разработка сайта и так недешёвое удовольствие, а тут предлагают заплатить вообще непонятно за что! Ну как непонятно? Конечно приблизительно человек понимает смысл этого термина, но всё равно задаётся вопросом - "Зачем это моему сайту?"
И ответ на него достаточно прост и сложен одновременно...
Безопасность посетителей / сайта
Очень объёмная тема, но если в двух словах, то основная цель бета-тестера - определить наличие потенциальных уязвимостей. А основные задачи - поиск ошибок всех, кто принимал участие в разработке сайта.
Взлом
Пожалуй самая большая проблема любого сайта. Ведь закон Мёрфи неоднократно подтверждал свою состоятельность, т.е. если существует возможность взломать сайт, то это рано или поздно произойдёт.
Что может привести к этому:
- Устаревшие версии платформы / фреймворков, использовавшихся при создании сайта. Ни один, даже самый дорогой продукт не смог избежать ошибок в коде. Поэтому регулярно выходят патчи, закрывающие эти огрехи. Но к идеалу не приблизился ещё никто.
- Используемые самописные скрипты. Тут всё ещё хуже. При разработке сайта, если вы не огромная корпорация, #web-разработчик нанимается в пределах бюджета, а он, чаще всего, очень даже ограничен. Это значит, что вероятность написания кода без обработки любых возможных исключений многократно возрастает.
- Пиратские версии шаблонов / плагинов. Что греха таить, ведь даже вы наверняка их использовали. Или если не сами, то нанятый разработчик - ведь проще скачать с какого-нибудь файлообменника зануленную версию, чем покупать её официально, снижая свой доход. В лучшем случае он предложит вам самому решить, и по опыту знаю, что часто выбирают "сначала давай с этой приблудой попробуем, и если она прям супер, то уже тогда купим".
- Дешёвый хостинг. Опять же, если вы в самом начале и сайт только создаёте, то стараетесь минимизировать расходы, в том числе и на хостинге. Выбирая малоизвестного хостера с низкими ценами и shared-хостинг с тарифом подешевле, вы оказываетесь заложником: старых программных решений для обеспечения подобных услуг, а также "соседей" по серверу - с потенциальными уязвимостями и возможностью добраться через них в вашу директорию с файлами сайта.
Каковы же печальные последствия подобных ошибок? Тут всё достаточно очевидно:
- Заражение сайта. Самый распространённый результат. Основных целей несколько: расширение ботнета, заражение посетителей, кража данных.
- Получение доступа в админку. Без комментариев - резвись не хочу. Делай всё что хочешь, вплоть до удаления сайта.
- Кража данных пользователей. Если на сайте предусмотрена регистрация и сбор персональных данных (адрес, телефон, ФИО, email, соцсети, возможно данные платёжных карт), то пользователи вряд ли обрадуются факту их утечки.
- Кража ваших заказов. Актуально для сайтов услуг с определённым LTV. Например, вы оплачиваете рекламу, посетители оставляют заявки, а вам на сайт добавили кусочек кода, который эти заявки сбрасывает "на сторону".
- Дамп БД. Список логинов-паролей, особенно с привязкой к почте - лакомый кусок любого хакера.
Следующей проблемой, с которой вы можете столкнуться, не протестировав сайт перед выпуском его "в бой", - это ограниченность ресурсов сервера, на котором он "крутится".
Т.е. бета-тестер должен определить, можно ли...
"Положить" сайт
И тут вопрос даже не в кознях недоброжелателей, хотя и от этого никто не застрахован.
Пример прямо в статье, о которой я писал выше, - не захотела редакция удалять материал с сайта, получите DDoS-атаку.
Даже вполне себе тривиальный сценарий, когда сайт не на чистом HTML, а написан на PHP или JS (таких сейчас подавляющее большинство) и при функционировании потребляет ресурсы сервера, может привести к недоступности по причине их исчерпания.
Т.е. когда количество посетителей достигает определённого порога, ограничения по потребляемым ресурсам на вашем тарифном плане, установленные хостером, просто не дают возможности "отрисовать" страницу сайта, и пользователь в браузере видит или пустой экран, или 503 ошибку.
Избежать этого помогут: внимательное ознакомление с условиями тарифного плана ДО его приобретения (если сами это делаете) или обязательное обсуждение этого вопроса с веб-мастером, кто вам делает сайт и рекомендует тот или иной хостинг.
А также нагрузочное тестирование на этапе бета-теста, позволяющее определить этот предел и выработать стратегию по проактивному предупреждению возникновения подобной ситуации.
Переходим к менее опасному, но не менее важному вопросу.
Лояльность посетителей
Не раз сталкивался с заказчиками, обращающимися с просьбой решить проблему с неконвертящим сайтом. Т.е. люди приходят...и уходят. И у них возникает естественный вопрос:
И часто проблема не в том, что некрасивый дизайн или завышенные цены, а просто на этапе проектирования сайта не были проработаны основные сценарии действий посетителя.
Скоро будет статья на эту тему, так что если вам интересно, то ПОДПИСЫВАЙТЕСЬ на канал, чтобы не пропустить!
Сценарии использования сайта
Обязательно учитывайте, что ещё до того, как сайт начнёт воплощаться в коде, у вас должны быть определены наиболее вероятные варианты действий посетителей на сайте.
Это значит, что вы должны себе представлять его путь от момента загрузки страницы до совершения конверсии или выхода с сайта. Часто уже на этом этапе совершаются ошибки в предположениях, что приводит к непонятному или перегруженному меню, неочевидности точек конверсии, запутанному процессу конвертации.
И грамотный тестировщик, оценивающий сайт с позиции посетителя, способен увидеть эти "узкие места", что позволит вам избежать их ДО выхода сайта "в свет".
Для оценки именно сценариев пользователя на сайте, если он уже работает, лучше использовать инструмент от Google.
Analitycs -> Отчёты -> Поведение -> Карта поведения
К сожалению, Яндекс Метрика подобного удобства не предоставляет.
Ошибки кода / дизайна / логики
Да-да-да. Именно так. Как бы вам не хотелось верить, что у вас всё как надо, но в 99% случаев проведение бета-теста обязательно находит эти ошибки.
Наиболее распространённые из них:
- Дизайн. Дизайнер (если вы привлекали такого специалиста) разрабатывал сайт с использованием одного монитора, вы оценивали его работу на другом, а у посетителей вообще чехарда с цветопередачей, яркостью и контрастностью дисплеев. И вполне возможна ситуация, что некоторые элементы будут сливаться с фоном или наоборот будут смотреться непривлекательно. Или не отработан дизайн интерактивных элементов в различных состояниях: hover, active, visited (особенно актуально, если при вёрстке не будет использоваться фреймворк, где это уже предусмотрено).
- Вёрстка. Графические элементы, наезжающие на текст или друг друга; текст выходящий за пределы страницы; частично "съеденный" текст или заголовок; пропавшие элементы и т.п.
- Адаптивность. Хоть это и относится к вёрстке, но я выделил её в отдельный пункт, поскольку очень часто натыкаюсь именно на эту ошибку. И если на десктопе, например, всё сделано как надо, то при проверке симуляции мобильных устройств практически со 100% вероятностью вылезают ошибки: слишком крупные заголовки; большие отступы между секциями; "поехавшие" блоки в секциях с повторами; не свайпающиеся галереи; появление горизонтальной прокрутки и т.д.
- Скрипты. Даже сейчас, с учётом развития стандартов HTML и CSS, если ты хочешь получить живой сайт, с анимацией и различными эффектами, то придётся использовать самописные скрипты. И не всегда они работают так, как задумывалось, да и как писал выше - безопасность в них может хромать.
- Грамматика и орфография. Тоже регулярно встречающаяся проблема. Тот, кто отвечает за наполнение сайта, не вычитывает тексты перед размещением, даже если он же сам их и написал. Ну как можно серьёзно относится к компании, на сайте которой
тестыс неверно расставленными знаками препинания или очепятками? Была реальная история с одним моим заказчиком, продающим кондиционеры, где в слове "многоканальные" потеряли одну букву🤣🤣🤣 - всего ОДНА буква и какой пассаж! - Формы. Это вообще классика. Из наиболее распространённого: не приходящие заявки в CRM / на почту / в мессенджер; неполная информация в этих заявках (например программер в шаблоне забыл закрывающий символ } в переменной и вы вместо номера телефона получите в заявке {phone); неверная информация в этих заявках (например номер телефона, где в форме на сайте по умолчанию уже стоит +7, а посетитель начинает по привычке писать 89*** - в результате вы получаете неверный номер без последней цифры). И т.д. и т.п.
Всё это напрямую влияет на лояльность (желание совершить конверсионное действие или вернуться на него ещё раз) посетителей сайта.
Оптимизация
В идеале, #веб-мастер должен изначально, ещё на этапе вёрстки и наполнения, организовать всё так, чтобы сайт имел отличные показатели в
PageSpeed Insights или Яндекс Вебмастере. Было осуществлено первоначальное SEO.
Однако, как это часто бывает в жизни, идеал недостижим. И на вашем сайте могут быть / не быть:
- Картинки разного размера. Или просто огромного размера...
- Неминифицированные скрипты или таблицы стилей
- Закомментированный неиспользуемый код
- Не заполненные мета-теги
- Не подключённые системы аналитики и инструменты вебмастера
- Не настроенное или неправильно настроенное кэширование
И многое другое, что будет пагубно влиять на оптимизацию сайта, - оно вам надо?
Учитывая всё вышесказанное, задайте себе вопрос...
Так нужен мне бета-тест сайта или нет?
Я постарался максимально кратко и доступно объяснить основные причины по которым настоятельно рекомендую своим заказчикам выделять на него бюджет.
Неосвещёнными осталось несколько мелких моментов, которые не столь важны.
Ещё раз, для понимания, повторю...
При создании сайта (его концепции, дизайна, бизнес-логики) вы исходите из собственных предпочтений и предположений. Что совсем не означает их истинность и безошибочность.
Программист может написать неоптимизированный или небезопасный код. Может ошибиться в одном символе, и в результате вы не будете получать заявки.
Хостинг может не обеспечивать вас достаточным при росте посещаемости пулом ресурсов, и сайт "ляжет".
Выбранная платформа и её версия могут быть "дырявыми, как решето", что может привести к непредсказуемым проблемам с безопасностью.
Как и всё то, о чём я говорил выше, а также что не осветил в этом материале.
Вот и решайте сами - заплатить 1 раз ДО появления проблем с целью их предотвращения, или потом столкнуться с ними, но уже тратить деньги на их устранение, учитывая слитые рекламные бюджеты, неполученную прибыль от несконвертированных лидов, потенциальную возможность судебных исков или разборок с управлением К.
Спасибо, что дочитали до конца очередной #длиннопост. Надеюсь я сумел раскрыть тему, и вам было интересно читать!
А что вы думаете по этому вопросу?
Если вам понравился материал - ПОДПИСЫВАЙТЕСЬ на канал, чтобы не пропустить новые интересные статьи про разработку и продвижение сайтов.
Всем добра и хороших сайтов с отличными конверсиями!
