Перейти к содержимому

Избранный кейс

Разработка витрины Shopify, ориентированной на конверсию

Проектирование и эксплуатация buy box подписки, состояния корзины, измерения производительности, аналитики checkout и доставки в продакшн для американского велнес-бренда формата DTC на сильно доработанной теме Shopify.

  • Shopify OS 2.0
  • Recharge
  • Vanilla JS
  • Core Web Vitals
  • Web Pixel
  • Puppeteer
Открыть действующую страницу товара

Большая часть привлечённого трафика попадала сразу на страницы товара, поэтому этот кейс сфокусирован на системах PDP и производительности витрины, а не на главной странице. Действующая страница длинная и продолжается далеко за пределами первого экрана: buy box с выбором набора и подписки, преимущества, состав, хронология по неделям, отзывы и FAQ. Не каждое утверждение о товаре, отзыв или ассет на этой странице сделаны мной.

Lumway product page
Бизнес
Американские велнес-добавки, напрямую потребителю
Платформа
Shopify Online Store 2.0, собственная тема на базе Elixir
Роль
Единственный инженер на коммерческих поверхностях витрины
Ответственность
Архитектура, реализация, отладка в продакшене, измерения и релиз
Основная разработка
Liquid и чистый JavaScript, Selling Plans с Recharge, мониторинг реальных пользователей, Web Pixel для checkout

Одна система, а не шесть функций

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

Решение о покупке принимается на двух поверхностях: странице товара и наборе рекламных лендингов с тем же buy box. Трафик в основном платный и в основном мобильный, поэтому посетитель приходит из рекламы на телефоне среднего уровня и принимает решение за секунды.

Эти поверхности связаны, потому что покупатель воспринимает их как один путь: увидеть предложение, выбрать набор, добавить в корзину, оформить заказ и, в идеале, оформить подписку. Бизнес опирается на этот же путь, чтобы понять, сработало ли что-то из этого. Несоответствие в любой точке тихо теряет продажу, без единой строки в логе: цена, отстающая от выбранного набора, выдвижная корзина, которая мигает и исчезает, вёрстка, которая прыгает при первой отрисовке, воронка, которая гаснет на checkout.

Повторные клиенты приносят больше долгосрочной ценности, чем разовая покупка, поэтому элемент управления подпиской имел непропорционально большое коммерческое значение. И всё это работает на действующем магазине, который контент-команда правит каждый день через Shopify Customizer, поэтому каждое изменение должно попадать в продакшн, не перезаписывая их работу. Одно это ограничение сформировало архитектуру не меньше, чем любая функция.

Покупатель воспринимает предложение, набор, подписку, корзину, checkout и подтверждение как одну непрерывную систему.

Путь покупки

Шесть поверхностей, один путь, каждая зависит от слоёв под ней.

Платный мобильный трафик
PDP или лендинг
Общий buy box
Набор и тип покупки
Корзина
Shopify checkout
Подписка или разовый заказ

Вспомогательные слои

  • Отображаемая цена
  • Коммерческое состояние
  • Производительность
  • Аналитика
  • Доставка в продакшн

До и после

Подписка

До

Виджет вендора хранил собственное состояние цены, поэтому видимое предложение подписки могло расходиться с выбранным набором.

После

Собственный интерфейс на Shopify Selling Plans держал набор, периодичность списаний, отображаемую цену и списываемую цену согласованными.

Подтверждение: Правильный selling plan и цена на каждом протестированном наборе и типе покупки.

Корзина

До

DOM-запросы по всему документу вызывали неверные количества, исчезающее состояние выдвижной корзины и неработающее добавление в корзину.

После

Доступ к состоянию и DOM был ограничен реальным контекстом buy box, что устранило три тихих сбоя на уровне их общей первопричины.

Подтверждение: Проверено в чистом headless Chrome на полной матрице buy box.

Производительность

До

Тему оценивали по лабораторным метрикам, которые упускали сдвиг вёрстки, с которым сталкивались реальные посетители.

После

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

Подтверждение: Всплеск, полученный из полевых данных, с подтверждением до и после в лаборатории и песочнице.

Аналитика

До

Воронка гасла на checkout, а карта событий рисковала отправлять имена клиентов.

После

checkout был инструментирован через Web Pixel, без имён клиентов в payload.

Подтверждение: Карта событий срабатывает на витрине и checkout после прохода исправлений.

Доставка

До

Обычный push мог перезаписать оформление витрины, которое контент-команда только что опубликовала.

После

Общие файлы сначала подтягиваются, а потом отправляются, и каждое изменение выходит как один откатываемый pull request.

Подтверждение: После внедрения этого рабочего процесса известных потерь контента в Customizer больше не было.

Проверенные результаты

Каждый помечен тем, как его измеряли.

  • 66 / 66

    Перенесённые подписки подтверждены как активные

    Операционная проверка

  • 3

    Тихие сбои корзины сведены к одной общей первопричине

    Репозиторий и Puppeteer

  • ~0.9 CLS

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

    Полевое наблюдение

  • < 0.001 CLS

    Результат по сценарию выдвижной корзины после исправления

    Проверка в лаборатории и песочнице

  • Без жёстко заданных ID

    Сопоставление selling plan берётся из данных плана, а не из фиксированных ID

    Реализация

  • Изолированный откат

    Один независимо откатываемый pull request на каждое изменение в продакшене

    Операционный рабочий процесс

Ключевые инженерные истории

Избранная история · 01

Собственный buy box подписки на нативных selling plans

Готовый виджет подписки заводил отдельное состояние цены и не мог полностью совпасть с витриной. Я заменил его слой представления собственным buy box на Shopify Selling Plans, оставив Recharge как обработчик подписок. Выбор набора определяет периодичность списаний, а сопоставление берётся из текста плана, а не из жёстко заданных ID, поэтому оно переживает правки плана, которые ломают жёстко зашитую интеграцию. Поскольку повторные клиенты приносят больше долгосрочной ценности, чем разовая покупка, цель была простой: предложение, которое видит покупатель, это предложение, по которому его списывают.

ПровереноНа каждом наборе и типе покупки отправлялись правильный selling plan и цена.

Читать подробный разбор
Lumway subscription buy box: pack selection, 2-Month-Delivery selected with per-pack price, and add to cart
  1. 01Selected pack
  2. 02Subscribe versus one-time
  3. 03Billing cadence
  4. 04Visible price equals billed price
  5. 05Add to cart
Собственное представление
Authored
Нативный Shopify
Platform
Обработка в Recharge
Vendor

02

Коммерческое состояние и стабильность корзины

buy box состоит из трёх компонентов: селектора набора, переключателя типа покупки и кнопки добавления в корзину, которые не делят общий DOM на странице без фронтенд-фреймворка, со скрытой второй формой товара и сторонним приложением, способным удалить выдвижную корзину. Три сбоя в продакшене (неверное количество, исчезающая выдвижная корзина и неработающая кнопка) сведены к одной первопричине: DOM-запросы по всему документу на странице, где больше одной формы. Я ограничил каждое чтение реальным контекстом buy box и связал компоненты через обмен сообщениями.

ПровереноКаждое исправление вышло как откатываемый pull request и было перепроверено в чистом headless Chrome.

Читать подробный разбор
Несколько форм
Запрос по всему документу
Неверный контекст

03

Производительность, измеренная на реальных пользователях

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

ПровереноПолевой всплеск подтверждён, до и после измерены в лаборатории и песочнице.

Читать подробный разбор
00.10.50.91.0~0.9CLS · share of mobile pageviews
Good ≤ 0.1Spike ~0.9 (≈ a third of mobile)
Real-user monitoring, mobile. The spike near 0.9 never reproduced in lab or sandbox — it only showed in the field.

Drawer-path verification

< 0.001 CLS

Lab and sandbox

04

Аналитика через границу checkout

Каждое решение здесь оценивалось по данным, но checkout в Shopify это закрытая поверхность, до которой код темы не дотягивается, поэтому воронка не могла быть одним скриптом. Я инструментировал витрину из темы, а checkout через Shopify Web Pixel, держал их раздельно и добавил вендор-нейтральный слой событий, чтобы аналитического вендора можно было заменить. payload на checkout фиксирует, что поле было заполнено, а не кто его заполнил. Я диагностировал проблему дублирования Purchase для маркетинговой команды, не владея GA4 и пикселями.

ПровереноПошаговые события checkout без имён клиентов в payload.

Читать подробный разбор
Витрина темы
Граница checkout
Web Pixel

05

Безопасная доставка в продакшн

Ветки соответствуют темам, а merge публикует автоматически, и контент-команда параллельно правит те же JSON-файлы через Customizer, поэтому обычный push может незаметно перезаписать действующее оформление витрины. Я перенёс разработку на личные неопубликованные темы, подтягивал общие файлы перед их редактированием и выпускал каждое изменение как один изолированный, откатываемый pull request. Дисциплина здесь и есть архитектура, потому что платформа её не навязывает.

ПровереноПосле внедрения этого рабочего процесса известных потерь контента в Customizer больше не было.

Читать подробный разбор
Тема для разработки
Подтянуть общий JSON
Изолированный PR
Опубликованная тема

Вспомогательная операция

66 действующих подписок, миграция под задачу

Магазину нужно было перенести 66 активных подписок из Loop в Recharge. Чистый путь через API был недоступен: экспорт из Loop был закрыт, а Shopify больше не разрешает создавать собственные приложения из админки. Поэтому я сделал контролируемый рабочий процесс импорта, а не широкую платформу миграции: нормализовать экспорт, проверить каждое критичное для списаний поле, подготовить импорт в Recharge, проверить окно ближайшего списания и сверить каждую запись после загрузки. Переключение было рассчитано по времени вокруг самого раннего предстоящего списания, чтобы ни с одного подписчика не списали дважды. Процесс был сделан под одну ограниченную миграцию, а не превращён в инфраструктуру, которая бизнесу не нужна.

66

Expected

66

Imported

66

Active

Operational verification

Проверено66 из 66 перенесённых подписок подтверждены как активные в Recharge после импорта.

Читать историю миграции

Результаты и границы

Коммерческие метрики за время работы улучшились. Эти цифры принадлежат бренду и находятся под NDA, поэтому здесь я показываю проверенную инженерию, а серьёзному потенциальному клиенту разбираю результаты приватно.

Проверенная инженерия

  • Поведение реализации, подтверждённое в коде и тестах в чистой среде
  • Измерения в лаборатории и песочнице при троттлинге
  • Наблюдение из полевых данных, полученное мониторингом реальных пользователей
  • Операционная проверка миграции и рабочего процесса доставки
  • В payload событий checkout не было имён клиентов

Под NDA

  • Показатели конверсии и выручки
  • Средний чек и удержание
  • Аналитические дашборды бренда

Инженерные принципы

  1. 01

    Измеряйте реальных пользователей, а не только синтетические оценки.

    Лабораторные инструменты это диагностика, а не приговор о том, что на самом деле получают ваши посетители.

  2. 02

    Ограничивайте логику реальным коммерческим контекстом.

    На странице с несколькими формами и секциями запрос по всему документу это скрытый баг.

  3. 03

    Держите видимое предложение равным тому, по которому списывают.

    Цена, которой покупатель не может доверять, это проблема конверсии, а не косметики.

  4. 04

    Проектируйте доставку вокруг модели редактирования платформы.

    В магазине, который команда правит каждый день, безопасный релиз это задача проектирования, а не урок по Git.

Избранный стек

Витрина

  • Shopify Liquid
  • OS 2.0 sections and blocks
  • Vanilla JavaScript

Коммерция

  • Shopify Selling Plans
  • Recharge
  • AJAX Cart API
  • Sections Rendering API

Измерения

  • web-vitals
  • Google Apps Script
  • Amplitude
  • Shopify Web Pixel

Качество и доставка

  • Puppeteer
  • Shopify CLI
  • GitHub integration

Границы ответственности

Не приписываю себе

  • Storefront API и Metaobjects, которые встречаются только в коде стороннего конструктора страниц
  • Theme App Extensions, поставленные вендорами
  • Настройка GA4, Meta Pixel и TikTok Pixel, за которую отвечает маркетинговая команда

Где нужно, я диагностировал, просматривал или интегрировался с ними, но не создавал и не настраивал их.

Инженерные истории

Шесть самостоятельных историй из этого проекта. Каждая раскрывает реализацию полностью.

Следующий кейс

Absolute Support

Собственный коммерческий опыт для компрессионной одежды на базе Dawn, с сохранением нативных движков товаров и фильтрации Shopify.

Смотреть кейс

Нужен инженер Shopify, который работает по всему коммерческому пути?

Я работаю там, где сходятся UX витрины, продуктовая логика, ограничения платформы, измерения и доставка в продакшн.

Начать разговор