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

Пролог

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

В этом мне помогли отличная команда и сервисы 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%. Нужно понимать, что это путь не для слабонервных — результаты работы разработчика за пару недель могут быть легко выброшены в корзину вместе с неподтвержденной гипотезой. Однако каждая подтвержденная гипотеза приносит новые знания, которые позволяют нам делать продукт удобнее для пользователей и выгоднее для банка.