Маркетолог: начиная новый проект — сначала проверь сайт!
Краткая заметка о том, почему перед запуском рекламы и планированием активности — лучше проверить сайт на предмет ошибок и прочих радостей.
Меня зовут Лена и я — дизайнер (не маркетолог), хотя маркетингом тоже часто приходится заниматься, когда планируешь редизайн сайта, а штатного маркетолога у заказчика нет.
Проблема не в вас
Часто, даже на крупных проектах, куда в сутки льется рекламы от 1.000.000 рублей, работая в составе команды я замечала такие забавные штуки:
- Сайт некорректно работал в планшетах. Из-за некорректной адаптации сайта — корзина просто не помещается в экран и на планшете найти ее невозможно. Итог: 0 продаж с планшета, слито в трубу несколько миллионов за месяц.
- На обновленном магазине не работал платежный шлюз. Почти неделю это никого не беспокоило, пока раздосадованный пользователь не написал, что не смог оплатить онлайн. Итог: минус 5-7 миллионов рублей на пользователях, которые не смогли оплатить картой.
- После 9 нажатий на кнопку Меню — оно переставало работать. Видимо, цифра "10" была магической. Нашлось спустя месяц активной работы сайта, упущенный бюджет даже посчитать трудно.
И это только — несколько самых значимых примеров. Я видела тысячи мелких "багов", которые в целом не убивали продажи в ноль, однако отпугивали сотни пользователей, и команде проекта на это было откровенно плевать. Не потому, что они их не видели — они просто не искали их и не находили. И от этого будет страдать эффективность вашей рекламы.
Крайне редко я вижу культуру самопроверки и перекрестной проверки в российских компаниях. Отсюда, начиная новый проект — я очень рекомендую самостоятельно проверить сайт, сделать заказ, проверить работу форм хотя бы на своих устройствах. Это займет не более часа времени, однако вы точно будете понимать, если что-то пойдет не так — вряд ли проблема в сайте.
Как самостоятельно проверить сайт?
Если у вас есть час — вполне достаточно взять свой телефон, планшет, компьютер и прогнать основные пользовательские сценарии. Лучше всего, если у вас будет:
- Телефон на Android и iOS
- Планшеты — на тех же ОС, чаще всего достаточно и iOS
- ПК на Windows 10, несколько основных браузеров. Сайт должен корректно работать в разрешениях от 1366x768 до 2560x1440, поэтому лучше всего проверить на мониторе с высоким разрешением, уменьшая объем окна.
Попробуйте:
- Пройти полный путь с главной страницы до заказа. Если это интернет-магазин — купите товар, выбирая все возможные его опции.
- Проверить работу всех форм заказа товара/услуги, обратную связь.
- Убедиться что кликая на телефоны, почты, мессенджеры — у вас открываются соответствующие приложения на телефоне.
- Пройтись по страницам и убедиться что они выглядят +- однаково на всех устройствах, основные элементы вроде корзины, CTA кнопок — не пропадают.
Найденные ошибки можно записать в чеклист в Google Docs, сгруппировав по типу устройства, версии операционной системы и обязательно приложив скриншот ошибки.
Такая быстрая проверка не защитит вас от багов на редких устройствах и телефонах со старой версией ОС. Однако, практика показывает, что этого чек листа достаточно для закрытия запросов 80-90% пользователей. Оставшееся ошибки — могут найти профессионалы, которые занимаются тестированием, QA и т.д., которым можно поручить эту задачу.
Напоследок
Если в компании, которой вы начинаете заниматься — нет мониторинга основных точек отказа, настаивайте на том, чтобы она появилась.
Как минимум, нужно следить за:
- Тем, что открываются все страницы
- Скорость открытия страниц
- Доступность сайта из разных регионов
- Онлайн-чат
- Корректный номер, соцсети и учредительные данные фирмы
- Онлайн-оплата и корректность данных
А делать это нужно для того, чтобы не прозевать тот момент, когда отвалится корзина или когда какой-нибудь из старых сотрудников не решит поменять реквизиты поступления средств на свои, о чем недавно писали на VC.
Помните: да, за состояние сайта отвечают верстальщики и программисты. Но, часто, их внимания может быть недостаточно для корректной работы ресурса, особенно когда они заняты постоянным внедрением новой функциональности. А за конечный результат в виде сниженных продаж - отвечать, скорее всего, вам.
Помните: да, за состояние сайта отвечают верстальщики и программисты. Но, часто, их внимания может быть недостаточно для корректной работы ресурса, особенно когда они заняты постоянным внедрением новой функциональности.
И для этого есть такие ребята, называются QA-инженеры (по-простому тестировщики), про которых даже в статье есть немного текста. Если после деплоев у этих ребят получается так, что у многих пользователей полсайта не работает, надо увольнять и тестировщиков, и проджектов/продактов, которые за этим наблюдают. Потому что они тупо сливают деньги компании (если, конечно, они не в сговоре с разработкой на тему того, что "нужен огромный рефакторинг").
Если проджект/продакт не делает сам UA тестирование (как раз оно по факту в статье описано), то его так же стоит уволить. Он не отвечает за свой проект на самом деле (как после выкатки в прод не проверить хотя бы элементарные сценарии новой фичи + основные сценарии, за которые компания деньги получает?)
Проверкой работы проекта маркетологи не должны заниматься, потому что у них нет экспертизы в тестировании. Ровно как и не хватит и не должно хватать того набора устройств, которые перечислены в статье (каждый раз, когда вспоминаю сколько разных устройств, ОС и разрешений есть на Android, мне становится плохо).
Еще есть ребята, зовущиеся аналитиками. Они также должны выявлять странные loop'ы в поведении пользователей (типа 30 раз обновил одну страницу или 15 раз попытался пройти один и тот же сценарий - явно что-то хотел сделать, но не смог, и вряд ли по своей вине, надо проверить страницу/сценарий, желательно с того устройства, с которого он заходил - нужно создать таск на QA).
Ну и плюс надо бы повнедрять всякие кнопки быстрых отзывов типа "Что-то не работает?" Иногда люди ими пользуются.
Спасибо за комментарий, согласна со всем.
Однако, прошу заметить, что реалии малого и среднего бизнеса часто не позволяют держать в команде отдельного QA, а проджекты/продакты вообще не занимаются тестированием.
Меня часто привлекают как дизайнера на проекты, где я настаиваю на внедрении тестирования, но не буду же я ему говорить что "вашего продакта, программистов следует уволить". Да и если скажу - ничего от этого не меняется, поэтому, живем в тех реалиях что есть :) А в них лучше перепроверять проект хотя бы поверхностно, чтобы не напороться...
Хорошо когда сайт с маркетологом пишется. Плохо когда залетаешь на готовый уже
Согласна. Однако, уметь действовать нужно в любом случае и простая проверка в виде часа вашего времени может многое рассказать о клиенте, в том числе о том - насколько внимательно и бережно они относятся к своему проекту :)
Разумно +++
Много правильных вещей, но вам лично на заметку - не все мобильные фичи можно проверять через devtools. То же меня леново на телефоне может работать корректно.
Спасибо за оценку материала. В целом, это базовая проверка, которую можно быстро сделать у себя. Предполагается, что маркетолог - не тестировщик и им быть не планирует :)
Хорошую проверку, по моему мнению, делают QA за отдельные деньги и там тестируют на целом зоопарке устройств. Вопрос только в том что не всем это может быть по карману ИЛИ просто маркетолог просто не сможет убедить дира это заказать.