Пришёл перерисовать первый экран — начал с настройки метрик

Контекст

TrustStore продаёт подписки на зарубежные сервисы. Живой магазин с постоянным трафиком, владелец держит на себе бэкенд и деплой.

Я предложил владельцу переделать первый экран и замерить эффект A/B-тестом. Мерить было нечем: попросил подключить Яндекс Метрику и GTM. Сам настроил цели — под тест и на будущее.

Тест запустили, и владелец попросил заняться воронкой «корзина → чекаут → оплата»: там теряются деньги. Гипотеза разумная — заказы создаются, часть не оплачивается, значит что-то не так.

Ограничения

• Правки идут прямо в прод, тестового контура нет.
• Прав на деплой у меня нет: всё, что требует правки файлов, ждёт окна у владельца.
• Около 30 визитов в день на главной — столько попадало в тест. При таком трафике значимость на A/B-тесте достижима только для крупных эффектов.
• Первый экран должен соответствовать дизайн-системе остального сайта.

Решение 1. Новый первый экран

 — откроется снимок целиком в новой вкладке

Что не так со старым экраном

Мой экспертный разбор показал, что первый экран работает сильно хуже, чем мог бы:

• Кишит AI-маркерами, а бессмысленный заголовок хвалит сервис.
• Не хватает визуального элемента, который бы объяснял сервис.
• Не снимает страхи покупателей: а что, если не сработает? А не обманут ли меня?
• Нет ни одного названия сервиса вроде ChatGPT или Claude, хотя покупатели ищут «оплатить ChatGPT», а не «маркетплейс подписок».
• Главная кнопка того же белого цвета, что заголовок и подзаголовок, — ничем не выделена как главное действие. И названа именем раздела, а не действием покупателя. Кнопка плохо доводит покупателей до товаров.

1440 · 768 · 375 px

 — откроется снимок целиком в новой вкладке

 — откроется снимок целиком в новой вкладке

 — откроется снимок целиком в новой вкладке

Что сделал— Решение 1

• Ушёл от «карнавальной» тематики. Успокоил экран.
• Заголовок отвечает на вопрос «Что за сервис?», а не даёт оценку.
• Кнопка называет действие и контрастирует с экраном.
• Возражения покупателей сняты: бейдж со сроком активации, строка про возврат денег.
• Добавил социальное доказательство: прописал рейтинг сервиса и число клиентов.
• Конкретика вместо абстракции: названия сервисов в подзаголовке и в визуале.

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

Как сделано

Анимация — чистые SVG и CSS, ноль библиотек и ноль новых сетевых запросов, учтён prefers-reduced-motion. Экран собирается от 320 пикселей. Всё на токенах существующей дизайн-системы. Имена классов сохранены: на них завязаны цели аналитики, и переименование сломало бы измерения. Вёрстку собрал через Claude Code и передал пакетом на прод, выкатывал владелец.

Решение 2. Настоял на A/B-тесте вместо выката по вкусу

Новый экран нравился и мне, и владельцу. Это плохое основание для выката в прод.

Чем аргументировал

Его деньгами: первый экран покупатель видит сразу, нельзя дважды произвести первое впечатление. Это важная точка контакта с клиентом. Если он красивый, по нашему мнению, но хуже по метрикам, то падение спишут на сезон или конкурентов, и никто не узнает причину без A/B-теста.

Заранее объявил проигрышный для себя исход приемлемым: выигрывает старый экран — значит сэкономили деньги, не потеряли на новом. Новый выиграет — значит экран действительно лучше доводит клиентов до товаров. Правило решения зафиксировали до того, как увидели данные: выкатываем новый вариант, если он значимо выигрывает по кликам и не даёт значимого ухудшения по оплатам.

Спор про антифликер

Пока экран грузится, посетителю нельзя показать старый вариант и подменить на новый — часть аудитории попадёт не в свою группу. Стандартное решение — ненадолго скрыть страницу. У владельца таймаут стоял на 140–180 миллисекунд ради высокой оценки скорости загрузки сайта. Этого времени недостаточно, чтобы платформа успела ответить: тест просто перестаёт измерять. Предложил снимать маску не по таймеру, а в момент, когда платформа ответила, какой вариант показать: обычно это около 0,3 секунды. И скрывать не всю страницу, а только первый экран. Возражение про скорость разобрал отдельно: лабораторная оценка ранжирование не определяет. Цену решения назвал сразу: у тех, кому платформа не ответила вовсе, первый экран остаётся скрытым до 2,5 секунд, а потом показывается старый вариант. Владелец принял схему, и тест запустили с ней.

Что чинил до старта

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

Самое полезное — история с копиями стилей. Навигация при каждом переходе добавляла на страницу ещё одну копию, и заголовок мерцал. Владелец починил: стиль с тем же именем больше не добавлялся второй раз. Владелец проверил так: посчитал на странице стили с этим именем. Нашёл один — значит, всё ок. Но такая проверка и не могла показать другое число: она считала ровно то, что починка убирала. Рядом копировался второй стиль, без имени, — его не видели ни починка, ни проверка. Я посчитал все стили эксперимента по содержимому, а не по имени, — копии продолжали множиться. Дал второму стилю имя, и только тогда счётчик перестал расти.

Результат теста

 — откроется снимок целиком в новой вкладке

Ещё один результат я не могу записать на свой счёт — это было бы не совсем честно. За период теста отказы упали почти вдвое, с 30% до 18%, — с первых же дней. Среди возможных причин есть и новый экран, но доказательств нет.

Что тест не доказал

Рядом с основной метрикой стояла вторая — конверсия в оплату, страховка «не стало ли хуже». У нового варианта она показала минус 40%, и Вариокуб в отчёте написал, что это незначимо. Визитов было мало: тест заметил бы только падение больше чем наполовину. Так что «незначимо» здесь значит не «не хуже», а «мы бы и не увидели».

Точное влияние на деньги неизвестно. Метки эксперимента в заказах не было, разложить продажи по вариантам нельзя. Пересчёт по базе заказов показал, что ни одна ступень воронки не просела значимо. После завершения теста мы вернули старый вариант на три дня, и уровень оплат не изменился: если бы новый экран резал продажи на 40%, это было бы видно. Итого: новый вариант не показал ухудшения продаж.

Какая из правок сработала — неизвестно. Тест мерил связку целиком. Сколько дал ярлык кнопки, сколько её контраст, сколько плашка с рейтингом — по этим данным не разложится.

Клики по кнопке первого экрана — не главный путь к покупке: кнопка лишь прокручивает к товарам на той же странице, и до них доходят и без неё. Удвоение кликов улучшило вход в воронку, который для многих не критичен.

Решение 3. Заменить сломанный учёт, а не чинить его

Я прошёл путь покупки вживую и сверил цели с базой заказов. Метрикам верить было нельзя — в том числе тем, что настраивал я сам.

Что выяснил

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

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

Цель «оплата», о которой я писал в разделе «Что тест не доказал», засчитывала любой заход на страницу успеха.

Что сделал— Решение 3

Переходы починил, не трогая код: через GTM задал переменную с номером счётчика, которую ждала навигация, и хиты пошли. Цель «посещение корзины» заменил событиями — «добавил в корзину» и «перешёл к оплате»: они срабатывают на любом из трёх маршрутов.

Был соблазн посчитать поправочный коэффициент к цели «оплата» и жить дальше. Нельзя: величина приписки плавала от периода к периоду — на одном отрезке +40%, на другом +13%, а в августе — в 2,55 раза. Коэффициент, который меняется, — это признак того, что метрике верить нельзя. Сначала я планировал метку в браузере: запоминать номер заказа перед переходом на оплату и засчитывать цель, если человек с ним вернулся. Отказался — метка подтверждала бы возвращение, а не платёж. Вместо неё владелец переписал страницу успеха так, чтобы она спрашивала статус заказа у сервера по номеру. Новую цель и остальной учёт я собрал сам, в GTM, — без новых деплоев владельца. Через несколько дней это окупилось: я нашёл 39 визитов за шесть дней, приходящих в обход обычного пути покупки, без номера заказа. Без условия по номеру новая цель зачла бы их как оплаты и сломалась бы ровно так же, как старая.

Решение 4. Не редизайнить чекаут

Чем обосновал отказ

Что сделал вместо редизайна

Разобрал путь оплаты по коду и нашёл четыре дефекта:

• Корзина очищалась до перехода на оплату, а не после успешного платежа.
• Заход на чекаут без служебного параметра рисовал заглушки — «Товар · 0 ₽» и кнопку «Перейти к защищённой оплате».
• Пустая корзина выдавала системное окно вместо нормального перехода.
• Адрес возврата при отмене терял параметр, без которого чекаут ломался.

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

 — откроется снимок целиком в новой вкладке

Платёж не прошёл, человек вернулся на сайт

 — откроется снимок целиком в новой вкладке

Я описал исправления, владелец выкатил версию, приёмку прошёл я на живом проде.

Результат

Я закрыл утечку на пути оплаты: человек, у которого не прошёл платёж, больше не начинает покупку с нуля. Основные потери остаются после перехода на оплату — их я описал и передал владельцу. Эффекта в процентах измерить не удалось. При таком объёме оплат измеримого прироста конверсии не будет ещё месяцы — чувствительности не хватает.

Чему научился

1. Метрику-страховку сверять с базой заказов до старта. Уже в июле цель давала на 40% больше оплат, чем было в базе.
2. Цели ставить на действие, а не на адрес страницы. «Посещение корзины» не видела покупателей, шедших в чекаут мимо неё, а «оплата» засчитывала любой заход на страницу успеха.
3. Записывать в заказ, какой вариант видел покупатель. Без этого заказы не разделить по вариантам, и на вопрос «а продажи выросли?» точного ответа нет.

AI в работе

Весь проект я вёл через Claude Code: настройка Google Tag Manager, Яндекс Метрики, Вариокуба, чтение чужого кода по слепкам прода, разбор выгрузок базы, вёрстка нового экрана, отладка перед запуском.

Интереснее, где я его вывод отбросил.

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

Инструмент ускоряет всё, но иногда ошибается, и его надо перепроверять.