Избранный кейс
Разработка витрины Shopify, ориентированной на конверсию
Проектирование и эксплуатация buy box подписки, состояния корзины, измерения производительности, аналитики checkout и доставки в продакшн для американского велнес-бренда формата DTC на сильно доработанной теме Shopify.
- Shopify OS 2.0
- Recharge
- Vanilla JS
- Core Web Vitals
- Web Pixel
- Puppeteer
Большая часть привлечённого трафика попадала сразу на страницы товара, поэтому этот кейс сфокусирован на системах PDP и производительности витрины, а не на главной странице. Действующая страница длинная и продолжается далеко за пределами первого экрана: buy box с выбором набора и подписки, преимущества, состав, хронология по неделям, отзывы и FAQ. Не каждое утверждение о товаре, отзыв или ассет на этой странице сделаны мной.
- Бизнес
- Американские велнес-добавки, напрямую потребителю
- Платформа
- Shopify Online Store 2.0, собственная тема на базе Elixir
- Роль
- Единственный инженер на коммерческих поверхностях витрины
- Ответственность
- Архитектура, реализация, отладка в продакшене, измерения и релиз
- Основная разработка
- Liquid и чистый JavaScript, Selling Plans с Recharge, мониторинг реальных пользователей, Web Pixel для checkout
Одна система, а не шесть функций
Lumway не был списком функций. Это была единая коммерческая система, через которую покупатель проходит одним непрерывным движением.
Решение о покупке принимается на двух поверхностях: странице товара и наборе рекламных лендингов с тем же buy box. Трафик в основном платный и в основном мобильный, поэтому посетитель приходит из рекламы на телефоне среднего уровня и принимает решение за секунды.
Эти поверхности связаны, потому что покупатель воспринимает их как один путь: увидеть предложение, выбрать набор, добавить в корзину, оформить заказ и, в идеале, оформить подписку. Бизнес опирается на этот же путь, чтобы понять, сработало ли что-то из этого. Несоответствие в любой точке тихо теряет продажу, без единой строки в логе: цена, отстающая от выбранного набора, выдвижная корзина, которая мигает и исчезает, вёрстка, которая прыгает при первой отрисовке, воронка, которая гаснет на checkout.
Повторные клиенты приносят больше долгосрочной ценности, чем разовая покупка, поэтому элемент управления подпиской имел непропорционально большое коммерческое значение. И всё это работает на действующем магазине, который контент-команда правит каждый день через Shopify Customizer, поэтому каждое изменение должно попадать в продакшн, не перезаписывая их работу. Одно это ограничение сформировало архитектуру не меньше, чем любая функция.
Покупатель воспринимает предложение, набор, подписку, корзину, 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 и цена.
Читать подробный разбор
- 01Selected pack
- 02Subscribe versus one-time
- 03Billing cadence
- 04Visible price equals billed price
- 05Add to cart
- Собственное представление
- Authored
- Нативный Shopify
- Platform
- Обработка в Recharge
- Vendor
02
Коммерческое состояние и стабильность корзины
buy box состоит из трёх компонентов: селектора набора, переключателя типа покупки и кнопки добавления в корзину, которые не делят общий DOM на странице без фронтенд-фреймворка, со скрытой второй формой товара и сторонним приложением, способным удалить выдвижную корзину. Три сбоя в продакшене (неверное количество, исчезающая выдвижная корзина и неработающая кнопка) сведены к одной первопричине: DOM-запросы по всему документу на странице, где больше одной формы. Я ограничил каждое чтение реальным контекстом buy box и связал компоненты через обмен сообщениями.
ПровереноКаждое исправление вышло как откатываемый pull request и было перепроверено в чистом headless Chrome.
Читать подробный разбор03
Производительность, измеренная на реальных пользователях
Трафик был преимущественно платным и мобильным, где страница, которая прыгает или отрисовывается увеличенной, в момент решения выглядит дёшево. Лабораторные инструменты показывали тему как здоровую, но всплеск сдвига вёрстки около 0.9 задевал примерно треть мобильных просмотров и оставался невидимым на быстрых тестовых загрузках. Я собрал небольшой конвейер мониторинга реальных пользователей, который наводил атрибуцию на каждую причину, а затем изолировал и убирал их по одной.
ПровереноПолевой всплеск подтверждён, до и после измерены в лаборатории и песочнице.
Читать подробный разборDrawer-path verification
< 0.001 CLS
Lab and sandbox
04
Аналитика через границу checkout
Каждое решение здесь оценивалось по данным, но checkout в Shopify это закрытая поверхность, до которой код темы не дотягивается, поэтому воронка не могла быть одним скриптом. Я инструментировал витрину из темы, а checkout через Shopify Web Pixel, держал их раздельно и добавил вендор-нейтральный слой событий, чтобы аналитического вендора можно было заменить. payload на checkout фиксирует, что поле было заполнено, а не кто его заполнил. Я диагностировал проблему дублирования Purchase для маркетинговой команды, не владея GA4 и пикселями.
ПровереноПошаговые события checkout без имён клиентов в payload.
Читать подробный разбор05
Безопасная доставка в продакшн
Ветки соответствуют темам, а merge публикует автоматически, и контент-команда параллельно правит те же JSON-файлы через Customizer, поэтому обычный push может незаметно перезаписать действующее оформление витрины. Я перенёс разработку на личные неопубликованные темы, подтягивал общие файлы перед их редактированием и выпускал каждое изменение как один изолированный, откатываемый pull request. Дисциплина здесь и есть архитектура, потому что платформа её не навязывает.
ПровереноПосле внедрения этого рабочего процесса известных потерь контента в Customizer больше не было.
Читать подробный разборВспомогательная операция
66 действующих подписок, миграция под задачу
Магазину нужно было перенести 66 активных подписок из Loop в Recharge. Чистый путь через API был недоступен: экспорт из Loop был закрыт, а Shopify больше не разрешает создавать собственные приложения из админки. Поэтому я сделал контролируемый рабочий процесс импорта, а не широкую платформу миграции: нормализовать экспорт, проверить каждое критичное для списаний поле, подготовить импорт в Recharge, проверить окно ближайшего списания и сверить каждую запись после загрузки. Переключение было рассчитано по времени вокруг самого раннего предстоящего списания, чтобы ни с одного подписчика не списали дважды. Процесс был сделан под одну ограниченную миграцию, а не превращён в инфраструктуру, которая бизнесу не нужна.
66
Expected
66
Imported
66
Active
Operational verification
Проверено66 из 66 перенесённых подписок подтверждены как активные в Recharge после импорта.
Читать историю миграцииРезультаты и границы
Коммерческие метрики за время работы улучшились. Эти цифры принадлежат бренду и находятся под NDA, поэтому здесь я показываю проверенную инженерию, а серьёзному потенциальному клиенту разбираю результаты приватно.
Проверенная инженерия
- Поведение реализации, подтверждённое в коде и тестах в чистой среде
- Измерения в лаборатории и песочнице при троттлинге
- Наблюдение из полевых данных, полученное мониторингом реальных пользователей
- Операционная проверка миграции и рабочего процесса доставки
- В payload событий checkout не было имён клиентов
Под NDA
- Показатели конверсии и выручки
- Средний чек и удержание
- Аналитические дашборды бренда
Инженерные принципы
- 01
Измеряйте реальных пользователей, а не только синтетические оценки.
Лабораторные инструменты это диагностика, а не приговор о том, что на самом деле получают ваши посетители.
- 02
Ограничивайте логику реальным коммерческим контекстом.
На странице с несколькими формами и секциями запрос по всему документу это скрытый баг.
- 03
Держите видимое предложение равным тому, по которому списывают.
Цена, которой покупатель не может доверять, это проблема конверсии, а не косметики.
- 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, за которую отвечает маркетинговая команда
Где нужно, я диагностировал, просматривал или интегрировался с ними, но не создавал и не настраивал их.
Инженерные истории
Шесть самостоятельных историй из этого проекта. Каждая раскрывает реализацию полностью.
- 01Опубликовано
Собственный buy box подписки на нативных selling plans
UX подписки на Shopify Selling Plans с Recharge в роли обработчика, и размер набора сопоставлен с интервалом списания из текста плана, без жёстко заданных ID.
Selling plansRechargeЧитать - 02Опубликовано
Коммерческое состояние без фронтенд-фреймворка
Три компонента без общего DOM, согласованные через обмен сообщениями, и три тихих сбоя корзины, сведённые к одной общей первопричине.
Vanilla JSAJAX CartЧитать - 03Опубликовано
Измерение реальных пользователей, а не только PageSpeed
Небольшой конвейер RUM, который нашёл всплеск сдвига вёрстки, невидимый в лаборатории, и упорядоченные исправления, которые его убрали.
Core Web VitalsRUMЧитать - 04Опубликовано
Миграция 66 подписок из Loop в Recharge
Контролируемая миграция под задачу, когда путь через API был закрыт, с проверкой поле за полем до фиксации и рассчитанная по времени, чтобы избежать двойных списаний.
RechargeMigrationЧитать - 05Опубликовано
Безопасный выпуск в действующий магазин Shopify, который правят совместно
Рабочий процесс доставки, построенный вокруг сопоставления веток и тем и ежедневных правок в Customizer, чтобы релизы никогда не перезаписывали действующее оформление витрины.
GitHubDeliveryЧитать - 06Опубликовано
Инструментирование Shopify через границу темы и checkout
Разделённые конвейеры витрины и checkout с вендор-нейтральным слоем событий, и прямо обозначенные ограничения приватности.
Web PixelAmplitudeЧитать
Следующий кейс
Absolute Support
Собственный коммерческий опыт для компрессионной одежды на базе Dawn, с сохранением нативных движков товаров и фильтрации Shopify.
Нужен инженер Shopify, который работает по всему коммерческому пути?
Я работаю там, где сходятся UX витрины, продуктовая логика, ограничения платформы, измерения и доставка в продакшн.
Начать разговор
