
Привет, меня зовут Улукбек, я фронтенд-разработчик в команде, которая работает над продуктом «Ипотека» в Райффайзенбанке. Этой историей я попробую рассказать, как разработчик может не только просто реализовывать задачи, поступающие от бизнеса, но и сам стать генератором идей, помочь компании в повышении эффективности и дать пользователям удобный сервис.
Пролог
Когда-то я работал в продажах и мог с легкостью оценить свой вклад в рост компании. В разработке такой возможности нет — сложно отвечать на вопрос «Чем я помог бизнесу?», когда делаешь клиентские порталы или личные кабинеты для пользователей. Поработав в новом проекте, я решил попробовать изменить ситуацию, и, параллельно с основными проектами, взялся за повышение конверсии посадочных страниц.
В этом мне помогли отличная команда и сервисы Google:
-
Google Analytics (GA): чтобы анализировать поведение пользователей и отслеживать возможные ошибки в работе;
-
Google Data Studio: с его помощью можно удобно отображать данные из Analytics, видеть полную картину и генерировать гипотезы;
-
Google optimize: для тестирования гипотез;
-
Google Developers PageSpeed Insights: анализ того, что можно улучшить в коде и организации проекта;
-
и кольцо Всевластия, чтобы управлять ими всеми;
Действие первое, где мы выясняем, что очень мало знаем о поведении пользователей, — и настраиваем GA
Выяснилось, что аналитику в проекте почти не собирали. Если точнее — собирали, но из нее можно узнать только откуда пришел посетитель, отправивший заявку. Это не плохо: нам нужно оценивать, какие каналы эффективны. Но в условиях, когда каждый лид стоит десятки тысяч рублей, а каждый посетитель — сотни, необходимо иметь больше информации.

Поэтому мы настроили отслеживание дополнительных действий с помощью GA:
-
Когда форма появилась в зоне видимости потенциального клиента.
-
Когда он активировал поле.
-
Правильно ли посетитель его заполнил.
-
В каком порядке пользователь заполнял поля и на каком этапе перестал.
-
Приходилось ли посетителю удалять информацию из поля после заполнения.
-
На каких полях у него возникали ошибки валидации.
-
Читал ли посетитель условия соглашения.
-
Какой статус формы был после ее отправки.
-
На каком этапе посетитель закончил оформление заявки.
Эти данные мы, как серьезные люди, через Google Tag Manager (GTM) передаем в GA. GTM — контейнер, через который можно подключать внешние скрипты, не имея доступа к коду. Использование этого сервиса очень удобно как для разработчиков — их не отвлекает маркетинг, так и для маркетинга — не нужно ждать внедрение доработок.
Действие второе, где нам страшно смотреть на все эти циферки. Мы хотим, чтобы было красиво, и поэтому настраиваем Google Data Studio
GA дает нам огромные объемы сырой информации, обычно в этом потоке разбираются веб-аналитики: они готовят отчеты, формируют сегменты, выуживают какие-то закономерности, творят магию. Конечный же потребитель — бизнес, UI/UX специалисты, фронтенд-разработчики, обычно хочет, чтобы все было стильно, модно, молодежно.
Под катом страшный интерфейс Google Analytics. Внимание, не для детей


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

1. Посетители с устройств на Android реже отправляют смс с подтверждением.
Причина: Модальное окно открывалось криво.
Решение: Исправили баг с окном.
2. Пользователи на мобильных реже доходят до самой формы.
Причина: Неизвестна.
Гипотеза: Баннер на мобильном занимает слишком много места.
Решение: Создать А/B тест с разными размерами баннеров, или вообще без них.
3. Посетители чаще закрывают формы на стадии заполнения полей контактных данных.
Причина: Неизвестна.
Гипотеза: Пользователи не готовы делиться контактами. Боятся, что их начнут спамить.
Решение: Создать А/B тест с полями контактов в начале и конце формы. Возможно, посетители, которые инвестировали свое время в заполнение других полей, спокойнее отреагируют на поля контактных данных.
Действие третье, где Google Optimize решает все вопросы с тестированием гипотез

Уже на второй проблеме стало очевидно, что нужно как-то тестировать наши гипотезы. Поэтому мы добавили возможность проводить А/В тестирования, чтобы цифры говорили сами за себя.
Для этого у Google есть Google Optimize — довольно простой инструмент, который работает примерно так:
-
Настраиваем страницу входа, страницу теста и конверсионное действие;
-
Optimize фильтрует всех посетителей страницы входа. Половина перенаправляется на тестовый вариант;
-
При достижении статистической значимости (определенное количество пользователей, на поведении которых уже можно что либо сравнивать) тест показывает, какой вариант выиграл;
Под катом интерфейс Google Optimize. Выглядит сложнее, чем есть на самом деле.

Этот процесс поставлен на поток. В любой отдельно взятый промежуток времени у нас запущен тест. Как только он заканчивается — мы выбираем выигрышный кейс, делаем его основным и сразу начинаем следующий. Для это почти в каждом спринте есть задача по созданию страницы для нового теста.
Действие четвертое, где разработчики изучают код и смотрят показатели скорости сайта
До последнего времени анализ поведения посетителей давал небольшие результаты. Но плох тот разработчик, который полагается только на маркетинговые инструменты и поведение посетителей.
Мы покопались в Google Developers PageSpeed Insights (aka Lighthouse в Google Chrome) и сформировали гипотезы, которые оказались за рамками обычного поведения пользователей.

Шаг 1: Серьезный
Мигрировали на SSR и перенесли старое React-приложение на Next.js. Мы плакали, кололись, но продолжали есть кактус. Пришлось затащить дизайн-систему банка к себе в проект, выяснить много нового про прод стенды и CI/CD проекта.
Шаг 2: Вдумчивый
Мы спросили у Page Speed, чего нам еще не хватает. Оказалось, что нужно сделать много всего. В итоге мы:
-
Добавили конвертацию изображений в *.webp-формат
-
Настроили кэш для статики
-
Разбили чанки, настроили тришейкинг, обновили библиотеки и убрали то, что уже не используем
-
Узнали, что вместе с нашим кодом грузятся килотонны разных скриптов
Шаг 3. Спорный
Нам пришлось обсуждать с маркетингом каждый скрипт, который они добавили через GTM (помните в начале про удобный инструмента? Ага, это он) и актуализировать необходимость его использования.
Почему так вообще происходит? Дело в том, что каждая уважающая себя платформа имеет свой пиксель для отслеживания перехода посетителей с этой платформы, а каждый уважающий себя маркетолог имеет доступ к GTM для добавления этих скриптов. В итоге мы имели:
-
Пиксели социальных сетей: Facebook, «ВКонтакте», TikTok;
-
Пиксели рекламных платформ поисковиков: Google, «Яндекс»;
-
Пиксели аналитических систем: GA, «Яндекс.Метрика», Owox, Hotjar;
-
Пиксели дополнительных сервисов: Comagic;
Парадоксально, но Google в своих рекомендациях ругается на скрипты Google, которые недостаточно оптимизированы и имеют неправильные настройки кэша.
Результатом трех шагов стало снижение времени ожидания загрузки страниц в 10 раз. Этот результат позволил нам подтвердить результаты эксперимента Walmart — «Сокращение времени загрузки на 1 секунду повышает конверсию на 2%».
Эпилог
Это были незабываемые месяцы.
Флешбэками у меня в мозгу всплывали встречи, звонки, коммерческие предложения и длительные встречи во время работы в продажах. В разработке мне гораздо меньшими силами удалось повысить продажи (выдачи ипотек).
На сегодняшний день нам удалось увеличить конверсию посадочных страниц на 25%. Нужно понимать, что это путь не для слабонервных — результаты работы разработчика за пару недель могут быть легко выброшены в корзину вместе с неподтвержденной гипотезой. Однако каждая подтвержденная гипотеза приносит новые знания, которые позволяют нам делать продукт удобнее для пользователей и выгоднее для банка.
ссылка на оригинал статьи https://habr.com/ru/articles/572200/
Добавить комментарий