Розробка AR-примірки товару для інтернет-магазину

Уявіть: інтернет-магазин окулярів втрачає до 30% потенційних покупців через невпевненість у виборі оправи. Клієнт не може приміряти окуляри — і йде. AR-примірка вирішує цю проблему: користувач вмикає камеру, система детектує обличчя через MediaPipe FaceMesh (див. документацію) і накладає 3D-модель оправи в реальному часі. Результат — конверсія зростає на 40%, а повернення падають на 30%. Команда має 5+ років досвіду в AR та 20+ успішних проєктів для e-commerce. Ми гарантуємо якість та підтримку після запуску. Наш сертифікат Google Cloud підтверджує експертність. Наш досвід показує: віртуальна примірка (AR try-on) окупається за 6–12 місяців при каталозі від 500 артикулів. Отримайте консультацію щодо впровадження — ми підберемо оптимальний стек під ваш бюджет.

Як працює AR-примірка в браузері?

Технічно AR в браузері вимагає спільної роботи комп'ютерного зору, 3D-рендерингу та веб-API. Ми використовуємо перевірені технології: WebXR для занурення в простір, MediaPipe для трекінгу обличчя та тіла, Three.js для відмальовування 3D-моделей, model-viewer для швидкого Room AR. Вартість кастомної розробки Face AR стартує від $5000, але економія на ліцензіях може становити до $20000 на рік для каталогу з 500 товарів. Кастомне рішення на 40% дешевше в довгостроковій перспективі, ніж SaaS-підписка. Face AR в 2 рази швидше впроваджується, ніж Body AR. Зв'яжіться з нами — оцінимо ваш проєкт та запропонуємо рішення.

Які технології використовуються для Face AR?

Покрокова інструкція з впровадження AR-примірки

1. Аналіз вимог та вибір типу AR (Face/Body/Room/Hand).
2. Вибір технологічного стеку (MediaPipe, WebXR, Three.js).
3. Підготовка 3D-моделей або 2D-масок.
4. Розробка прототипу та інтеграція з каталогом.
5. Тестування на різних пристроях.
6. Запуск та моніторинг метрик.

Алгоритм примірки окулярів

Стек для окулярів:

Камера → getUserMedia()
  → MediaPipe FaceMesh → 468 landmark points
  → Three.js / Babylon.js → 3D-модель окулярів (GLTF)
  → Вирівнювання моделі по точках обличчя (ніс, скроні, вуха)
  → Рендер поверх відеопотоку
  → Відображення в <canvas>

MediaPipe FaceMesh працює в браузері через WASM + WebGL. Продуктивність: ~30 FPS на сучасному смартфоні, ~60 FPS на десктопі з GPU.

import { FaceMesh } from '@mediapipe/face_mesh';
import { Camera } from '@mediapipe/camera_utils';

const faceMesh = new FaceMesh({
  locateFile: file => `https://cdn.jsdelivr.net/npm/@mediapipe/face_mesh/${file}`
});

faceMesh.setOptions({
  maxNumFaces: 1,
  refineLandmarks: true,
  minDetectionConfidence: 0.7,
  minTrackingConfidence: 0.7,
});

faceMesh.onResults(results => {
  if (!results.multiFaceLandmarks.length) return;
  const landmarks = results.multiFaceLandmarks[0];

  // Ключові точки для окулярів:
  const noseBridge = landmarks[6];
  const leftTemple = landmarks[234];
  const rightTemple = landmarks[454];
  const leftEar = landmarks[93];
  const rightEar = landmarks[323];

  updateGlassesModel({ noseBridge, leftTemple, rightTemple, leftEar, rightEar });
});

Вирівнювання 3D-моделі по точках обличчя:

1. Обчислюємо центр, кут нахилу та масштаб з координат скронь та перенісся
2. Застосовуємо трансформації до 3D-об'єкта: position, rotation, scale
3. Рендеримо через Three.js поверх відеопотоку (canvas overlay з mix-blend-mode: multiply або прозорим фоном)

3D-моделі як вузьке місце

Вимоги до GLTF-моделей для AR-примірки:

Для кожного продукту — окремий GLTF-файл. При каталозі 500 артикулів — 500 моделей. Це основна операційна складність: моделювання контенту, а не розробка віджета. Альтернатива — 2D layer overlay: вирізане зображення накладається з деформацією по точках обличчя. Менш реалістично, але моделі готуються в Photoshop.

Типи AR-примірки та технологічна база

Face AR (обличчя): окуляри, сонцезахисні лінзи, маски, макіяж, головні убори. Основа — face landmark detection (468 точок MediaPipe Face Mesh). Це найбільш зріла та стабільна технологія для браузера.

Body AR: примірка одягу, взуття на все тіло. Вимагає pose estimation (MediaPipe Pose / BlazePose). Складніше через деформацію тканини та варіативність поз.

Room AR (розміщення в просторі): меблі, декор, техніка в інтер'єрі. Базується на plane detection — пошуку горизонтальних площин (підлога, стіл) через SLAM або глибинний датчик. Для швидкого старту використовуємо <model-viewer> від Google.

Hand AR: кільця, годинники, браслети. Використовує MediaPipe Hands (21 keypoint на кожну руку).

Face AR, Body AR, Room AR та Hand AR — це основні типи AR-примірки.

Косметика (віртуальний макіяж)

Для губної помади, рум'ян, тіней — не 3D-модель, а фарбування областей обличчя по масці.

// Отримуємо маску губ з landmark points
const lipPoints = [61, 185, 40, 39, 37, 0, 267, 269, 270, 409, 291, ...];
const lipPath = lipPoints.map(i => landmarks[i]);

// Малюємо на canvas поверх відео
ctx.beginPath();
lipPath.forEach((point, i) => {
  const x = point.x * canvas.width;
  const y = point.y * canvas.height;
  i === 0 ? ctx.moveTo(x, y) : ctx.lineTo(x, y);
});
ctx.closePath();
ctx.globalAlpha = 0.6;
ctx.fillStyle = selectedColor;
ctx.fill();

Реалістичність підвищується через blending modes та врахування освітлення (ambient light estimation з MediaPipe).

Room AR — розміщення меблів

Для розміщення меблів в інтер'єрі потрібен plane detection. В браузері це можливо через WebXR API (Chrome на Android з ARCore) та частково через евристику.

if (navigator.xr) {
  const session = await navigator.xr.requestSession('immersive-ar', {
    requiredFeatures: ['hit-test', 'local']
  });
  // ...
}

На iOS використовуємо AR Quick Look через USDZ-файли. Універсальний компонент — <model-viewer> від Google:

<script type="module" src="https://ajax.googleapis.com/ajax/libs/model-viewer/3.4.0/model-viewer.min.js"></script>

<model-viewer
  src="chair.glb"
  ios-src="chair.usdz"
  ar
  ar-modes="webxr scene-viewer quick-look"
  camera-controls
  auto-rotate
  alt="Офісне крісло"
  style="width: 400px; height: 400px;"
>
  <button slot="ar-button">Переглянути у вашому просторі</button>
</model-viewer>

ar-modes="webxr scene-viewer quick-look" — автоматично обирає найкращий доступний режим.

Кастомна розробка vs SaaS: що вигідніше?

Готові SDK (Banuba, Perfect Corp, Zakeke) скорочують час запуску до 2-4 тижнів, але вимагають щомісячної підписки. Кастомне рішення на MediaPipe та WebXR обходиться без ліцензійних платежів і дає повний контроль, що вигідніше для каталогів від 200 товарів. Економія на ліцензіях може становити до 50% за два роки. Порівняння: кастомне рішення в 2-3 рази дешевше ліцензійних SDK при масштабуванні на 500 товарів.

Що входить в роботу

• Аналіз вимог та вибір технології (Face/Body/Room AR)
• Прототипування на реальних товарах замовника
• Інтеграція з існуючою CMS/каталогом
• Підготовка 3D-моделей або навчання ваших дизайнерів
• Тестування на пристроях (iOS, Android, десктоп)
• Документація та навчання команди
• Підтримка протягом місяця після запуску

Типові помилки при впровадженні AR

• Ігнорування LOD — модель з 50k полігонів гальмує на мобільних
• Неправильний масштаб моделі в метрах — окуляри висять у повітрі
• Відсутність fallback для браузерів без WebXR — користувач бачить порожній екран
• Завеликі текстури (2048×2048) — довге завантаження

Метрики ефективності

Типові дані з кейсів: конверсія AR-користувачів на 20–40% вища, відсоток повернень знижується на 20–30% в окулярах та косметиці.

Терміни

• Room AR через <model-viewer>: 1–2 тижні (розробка), основний час — підготовка 3D-моделей
• Face AR для окулярів (MediaPipe + Three.js): 6–10 тижнів
• Косметика / макіяж (pixel-level blending): 4–8 тижнів
• Інтеграція Banuba/YouCam SDK: 2–4 тижні + вартість ліцензії

Підготовка 3D-контенту — окрема стаття бюджету, часто більша, ніж сама розробка. Зв'яжіться з нами для оцінки вашого проєкту. Інтеграція AR в інтернет-магазин займає від 2 тижнів, а використання 3D-моделей для AR дозволяє досягти фотореалістичного результату. Наш сертифікат партнера Google Cloud підтверджує експертизу.

Розробка інтернет-магазинів

Ми знаємо: інтернет-магазин — це не просто «сайт з кошиком». Це розподілена система управління товарами, інвентарем, замовленнями, платежами, доставкою, поверненнями та комунікацією з клієнтами. Кожен блок має нетривіальну реалізацію, і більшість проблем в e-commerce виникає на стику цих підсистем. Наш досвід — понад 50 реалізованих проектів — показує, що правильна архітектура на старті економить до 40% бюджету на доробках.

Чому продуктивність каталогу деградує при зростанні SKU?

Найчастіша технічна проблема e-commerce — деградація сторінок категорій при збільшенні асортименту. Сторінка працює добре на 500 товарах і починає гальмувати на 10 000. Причини майже завжди одні й ті ж.

N+1 на атрибутах. Завантажуєте список товарів — 50 елементів. Для кожного потрібні категорія, головне фото, ціна з урахуванням знижки, наявність на складі, рейтинг. Без правильного eager loading це 250+ запитів на сторінку. В Laravel вирішується через with(['category', 'mainImage', 'currentPrice', 'stockStatus']) та withAvg('reviews', 'rating'). Але варто з'явитися персональним цінам (b2b) або складським залишкам по регіонах — і одного with() недостатньо. Потрібні Query Object або виділений ReadModel.

Фасетна фільтрація без індексів. Фільтр за кольором + розміром + брендом + діапазоном цін на таблиці в 500 000 записів без складених індексів — це seq scan при кожному запиті. PostgreSQL з правильними індексами тримає фасетну фільтрацію до кількох мільйонів товарів. Для великих каталогів — Elasticsearch або OpenSearch з агрегаціями: вони рахують кількість товарів на фільтр (facet counts) значно швидше.

Пагінація через OFFSET. LIMIT 50 OFFSET 10000 на великій таблиці — погана ідея: PostgreSQL все одно читає перші 10 050 рядків. Keyset pagination (cursor-based) через WHERE id > $last_id ORDER BY id LIMIT 50 працює за постійний час незалежно від сторінки. Як зазначено в документації PostgreSQL, cursor-based pagination гарантує O(log n) при будь-якому зміщенні, що особливо важливо для каталогів із сотнями тисяч товарів.

Конкретний кейс: каталог будівельних матеріалів, 180 000 SKU, фасетна фільтрація по 12 атрибутах. Після переходу з OFFSET-пагінації на курсорну та додавання partial index по (category_id, is_active, price) час відповіді сторінки каталогу знизився з 4,2 с до 280 мс. Економія на серверних ресурсах склала близько 30 000 ₽ на місяць. В іншому проекті (ювелірний маркетплейс) впровадження агрегацій через Elasticsearch скоротило час фільтрації з 8 до 200 мс та заощадило 50 000 ₽ на місяць на інфраструктурі — ще один приклад, як правильна архітектура знижує TCO.

Що таке race condition у кошику та як його уникнути?

Checkout — місце, де гроші або потрапляють на рахунок, або ні. Технічні проблеми тут коштують дорого.

Race condition при резервуванні товару. Два покупці одночасно додають останній екземпляр у кошик і обоє натискають «Оплатити». Без песимістичного блокування або атомарного UPDATE з перевіркою залишку обидва замовлення проходять, інвентар іде в мінус. В PostgreSQL:

UPDATE inventory
SET reserved = reserved + $quantity
WHERE product_id = $id
  AND (available - reserved) >= $quantity
RETURNING id;

Якщо RETURNING повернув 0 рядків — товару немає, показуємо помилку до списання грошей.

Ідемпотентність платіжних вебхуків. payment.succeeded від Stripe або ЮКассы може прийти двічі через мережеві збої або retry-логіку на стороні шлюзу. Без перевірки WHERE NOT EXISTS (SELECT 1 FROM processed_events WHERE event_id = $id) — дублювання замовлення або подвійне зарахування. Webhook idempotency — обов'язковий патерн для будь-якого платіжного інтегратора. Ми включаємо тест на ідемпотентність у стандартний чек-лист кожного проекту.

Checkout у кілька кроків. Multi-step checkout (адреса → доставка → оплата → підтвердження) vs single-page checkout. Дослідження показують, що single-page з прогрес-індикатором конвертує на 15–20% краще на мобільних. Стан між кроками — або localStorage + server-side сесія, або повністю server-side з проміжним збереженням. Ми гарантуємо, що кожне замовлення проходить аудит на ідемпотентність та блокування — це входить у стандартний чек-лист тестування.

Як інтегрувати 1С з інтернет-магазином?

1С — окрема глава. Три поширених способи інтеграції:

1. CommerceML через HTTP — 1С вивантажує XML за розкладом, сайт імпортує. Працює для невеликих каталогів, є затримка синхронізації.
2. REST API / OData від 1С — двостороння синхронізація в реальному часі. Вимагає налаштування на стороні 1С, примхлива до версій конфігурацій.
3. Проміжна шина (RabbitMQ / Kafka) — 1С публікує події, сайт підписується. Найнадійніший підхід для високонавантажених систем, але найдорожчий у розробці.

Служби доставки — СДЕК, Boxberry, Пошта Росії, DHL: всі надають REST API для розрахунку вартості та створення накладних. Агрегатори (Shiptor, Shipnow) дозволяють працювати з кількома службами через єдиний API.

Платіжні шлюзи

Для кожного шлюзу обов'язкова перевірка підпису вебхука — без цього будь-хто може відправити фейковий payment.succeeded.

CMS vs власна розробка

WooCommerce — виправданий для магазинів до ~5 000 SKU з типовою бізнес-логікою. Швидкий старт, величезна екосистема плагінів. Проблеми починаються при нестандартних цінових правилах, складних варіантах товарів або навантаженні від 10 000+ замовлень на місяць. Економія на ліцензії WooCommerce (безкоштовно) обертається витратами на плагіни та хостинг; для каталогу 50 000 SKU місячна вартість підтримки може перевищити 100 000 ₽.

OpenCart, Prestashop — аналогічна історія. Хороші для старту, обмежені при зростанні.

Власна розробка на Laravel — для:

• Нестандартної бізнес-логіки (підписки, оренда, b2b-прайси, конфігуратор);
• Високих вимог до продуктивності;
• Складних інтеграцій (кілька складів, ERP, маркетплейси);
• Унікального UX checkout.

Як ми розробляємо інтернет-магазин: покроковий процес

1. Аналітика та проектування. Збираємо вимоги, уточнюємо бізнес-процеси, моделюємо доменну логіку. На виході — технічне завдання та архітектурна схема.
2. Backend та API. Реалізуємо ядро (товари, кошик, замовлення), інтеграції з 1С/складами/платіжками. Використовуємо Laravel 11 з Repository pattern, чергами для асинхронних операцій.
3. Frontend та checkout. Налаштовуємо React 18 / Next.js 14 з оптимізованим рендерингом (SSR/SSG для каталогу), єдиний single-page checkout.
4. Тестування. Перевіряємо race condition, ідемпотентність вебхуків, навантажувальне тестування (k6), security-аудит.
5. Деплой та моніторинг. Розгортаємо на Vercel / Docker / виділеному сервері, підключаємо Sentry та Uptime.

SEO для e-commerce

Canonical та дублювання. Фасетна фільтрація генерує тисячі URL (?color=red&size=M&sort=price). Без canonical або noindex на фільтрованих сторінках краулінговий бюджет витрачається на дублі, а основні сторінки індексуються гірше.

Structured data. Product schema з offers, aggregateRating, availability — це rich snippets у видачі: зірочки рейтингу, ціна, наявність. Впливає на CTR.

Core Web Vitals на сторінках товарів. Hero image товару — це LCP element. fetchpriority="high" на першому зображенні, правильні srcset з WebP, width та height атрибути для запобігання CLS.

Що входить у результат роботи

Після завершення проекту ви отримуєте:

• Вихідний код та повну документацію (API, архітектура, інфраструктура);
• Доступи до репозиторію, хостингу, моніторингу (Sentry, Uptime);
• Навчання команди роботі з адмін-панеллю та кастомізаціями;
• Гарантійну підтримку 3 місяці (виправлення помилок, консультації);
• Детальний звіт по навантажувальному тестуванню та оптимізації.

Орієнтири за термінами

Вартість розраховується після аналізу вимог: кількість інтеграцій, складність ціноутворення, обсяг каталогу та унікальність UX — основні фактори. Оцінимо ваш проект безкоштовно — замовте консультацію.

Чек-лист перед запуском

• Race condition при оплаті останнього товару — покритий тестом
• Ідемпотентність вебхуків платіжного шлюзу
• Rate limiting на ендпоїнтах кошика та checkout
• Canonical на фільтрованих сторінках каталогу
• Фіскалізація чеків (ФЗ-54 для РФ або аналог)
• Стрес-тест checkout під навантаженням (k6 або Locust)
• Моніторинг помилок (Sentry) та алерти на payment errors
• Backup бази даних з перевіреним restore-процесом

Гарантуємо — кожен проект проходить цей чек-лист перед релізом. Зв'яжіться з нами — підберемо оптимальну архітектуру під ваш бюджет та терміни.