Перейти до вмісту
Illia RomanovichShopify & E-commerce Engineer

Ключовий кейс

Інженерія конверсійної вітрини Shopify

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

Переглянути інженерні історіїОгляд системи
  • Shopify OS 2.0
  • Recharge
  • Vanilla JS
  • Core Web Vitals
  • Web Pixel
  • Puppeteer
Витяги коду на GitHub
Wellness DTC product page
Бізнес
Американські wellness-добавки, напряму споживачеві. Бренд під NDA
Період
З червня по серпень 2026
Платформа
Shopify Online Store 2.0, власна тема на базі Elixir
Роль
Єдиний інженер на комерційних поверхнях вітрини
Відповідальність
Архітектура, реалізація, дебаг у продакшні, вимірювання та релізи
Основна робота
Liquid і vanilla JavaScript, Selling Plans із Recharge, моніторинг реальних користувачів, checkout Web Pixel

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

Ця вітрина не була списком функцій. Це одна комерційна система, крізь яку покупець проходить одним рухом.

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

Ці поверхні пов'язані, бо покупець сприймає їх як один шлях: побачити пропозицію, обрати набір, додати в кошик, оформити замовлення й, в ідеалі, підписатися. Бізнес спирається на цей самий шлях, щоб знати, чи все спрацювало. Розбіжність у будь-якій точці тихо втрачає продаж, без жодного рядка в логах: ціна, що відстає від обраного набору, cart drawer, що блимає й зникає, верстка, що стрибає на першому відмалюванні, воронка, що гасне на checkout.

Постійні клієнти несуть більше довгострокової цінності, ніж разова покупка, тож керування підпискою мало непропорційно велику комерційну вагу. І все це працює на живому магазині, який контент-команда щодня редагує через Shopify Customizer, тож кожна зміна має потрапляти в продакшн, не перезаписуючи їхню роботу. Саме це обмеження сформувало архітектуру не менше, ніж будь-яка функція.

Покупець сприймає пропозицію, набір, підписку, кошик, checkout і підтвердження як одну неперервну систему.

Шлях покупки

Шість поверхонь, один шлях, кожна залежить від шарів під нею.

Платний мобільний трафік
PDP або цільова сторінка
Спільний buy box
Набір і тип покупки
Кошик
Shopify checkout
Підписка або разове замовлення

Допоміжні шари

  • Видима ціна
  • Стан комерції
  • Продуктивність
  • Аналітика
  • Релізи в продакшн

До і після

Підписка

До

Віджет постачальника тримав власний стан цін, тож видима пропозиція підписки могла розходитися з обраним набором.

Після

Власний інтерфейс на Shopify Selling Plans тримав узгодженими набір, періодичність списання, видиму ціну та ціну списання.

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

Кошик

До

Загальносторінкові DOM-запити спричиняли неправильну кількість, зникнення стану drawer і мертву кнопку додавання в кошик.

Після

Доступ до стану та DOM я обмежив реальним контекстом buy box, усунувши три приховані збої в їхній спільній першопричині.

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

Продуктивність

До

Тему оцінювали за лабораторними балами, які пропускали зсув верстки, з яким стикалися реальні відвідувачі.

Після

Моніторинг реальних користувачів знайшов цей зсув, і кожну причину я ізолював та прибрав.

Підтвердження: Сплеск із польових даних, до і після підтверджено в лабораторії та sandbox.

Аналітика

До

Воронка гасла на checkout, а карта подій ризикувала надсилати імена клієнтів.

Після

Checkout я інструментував через Web Pixel, без імен клієнтів у payload.

Підтвердження: Карта подій спрацьовує на вітрині та в checkout після виправлень.

Релізи

До

Звичайний push міг перезаписати мерчандайзинг, який контент-команда щойно опублікувала.

Після

Спільні файли я підтягую перед тим, як пушити, і кожна зміна виходить одним зворотним pull request.

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

Підтверджені результати

Кожен позначено тим, як його виміряно.

  • +45%

    Продажі за вісім тижнів після релізу проти восьми тижнів до нього

    Shopify Analytics, період до періоду

  • 66 / 66

    Перенесених підписок підтверджено активними

    Операційна перевірка

  • 3

    Приховані збої кошика зведено до однієї спільної причини

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

  • ~0.9 CLS

    Польовий сплеск виявлено через моніторинг реальних користувачів

    Польове спостереження

  • < 0.001 CLS

    Результат на шляху drawer після виправлення

    Перевірка в лабораторії та sandbox

  • Без жорстко прописаних ID

    Мапінг selling plan виведено з даних плану, а не з фіксованих ID

    Реалізація

  • Ізольований відкат

    Один незалежно зворотний pull request на кожну зміну в продакшні

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

Ключові інженерні історії

Ключова історія · 01

Власний buy box підписки на вбудованих selling plans

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

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

Читати розбір
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 це три компоненти, селектор набору, перемикач типу покупки та add-to-cart, які не мають спільного DOM на сторінці без фронтенд-фреймворку, з прихованою другою формою товару та стороннім застосунком, що може прибрати cart drawer. Три збої в продакшні, неправильна кількість, зникнення drawer і мертва кнопка, зведено до однієї причини: загальносторінкові DOM-запити на сторінці, де більше однієї форми. Кожне читання я обмежив реальним контекстом buy box і скоординував компоненти через передавання повідомлень.

ПідтвердженоКожне виправлення виходило зворотним pull request і повторно перевірялося в чистому headless Chrome.

Читати розбір
Кілька форм
Загальносторінковий запит
Неправильний контекст

03

Продуктивність, виміряна на реальних користувачах

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

ПідтвердженоСплеск із польових даних підтверджено, до і після виміряно в лабораторії та sandbox.

Читати розбір
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 більше не було.

Читати розбір
Dev-тема
Підтягнути спільний JSON
Ізольований PR
Опублікована тема

Допоміжна операція

66 живих підписок, міграція під розмір задачі

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

66

Expected

66

Imported

66

Active

Operational verification

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

Читати історію міграції

Результати та межі

Комерційний результат публічний в одній цифрі: продажі за вісім тижнів після релізу виявилися на 45% вищими, ніж за вісім тижнів до нього (Shopify Analytics, період до періоду). Абсолютна виручка, середній чек і утримання належать бренду й залишаються під NDA; інженерну частину нижче показано повністю.

Підтверджена інженерія

  • Поведінка реалізації, підтверджена в коді та ізольованих тестах
  • Вимірювання в лабораторії та sandbox під обмеженням ресурсів
  • Спостереження з польових даних моніторингу реальних користувачів
  • Операційна перевірка міграції та робочого процесу релізів
  • 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, які трапляються лише в коді стороннього page-builder
  • Theme App Extensions від постачальників
  • Налаштування GA4, Meta Pixel і TikTok Pixel, за яке відповідає маркетинг-команда

Я діагностував, переглядав або інтегрувався навколо них, де це було доречно, але не писав і не налаштовував їх.

Знеособлені витяги коду, про який тут ідеться, без бренду й секретів, відкриті: shopify-subscription-storefront на GitHub

Інженерні історії

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

Наступний кейс

Absolute Support

Власний досвід комерції компресійного одягу на Dawn зі збереженням вбудованих рушіїв товару та фільтрації Shopify.

Дивитися кейс

Передайте вітрину й вважайте питання закритим.

Надішліть задачу й мету. Далі розберуся в коді, доведу роботу до релізу й перевірю сам.

Почати розмову