Реалізація мультиканальних продажів (Omnichannel) на сайті
Уявіть: клієнт замовляє стілець на сайті, через годину забирає його в магазині, але на вітрині стілець ще висить — уже проданий. Або промокод працює тільки на сайті, а в додатку — ні. Це класичні наслідки розрізнених каналів. Ми інтегруємо мультиканальні продажі так, що клієнт бачить єдину картину: однакові ціни на сайті та маркетплейсах, історію замовлень в особистому кабінеті, можливість повернути товар з Ozon через магазин. Технічно — це зв'язка API, message broker (RabbitMQ) та єдиного профілю в PostgreSQL.
Чому Omnichannel — це не просто декілька магазинів?
Багато хто думає: «Підключили API маркетплейсів — ось вам омніканальність». Насправді виникає хаос: на сайті товар є, на Ozon закінчився, клієнт скаржиться. Або знижка діє лише в офлайн-магазині — користувач роздратований. Корінь проблеми — розрізнені джерела даних: ціни, залишки, замовлення живуть у різних системах без спільного ключа.
Ми вирішуємо це через Unified Commerce Core — мікросервіс, який тримає інвентар, клієнтів і промо в одному місці. Всі канали звертаються до нього, а не один до одного. Це усуває N+1 запитів і конфлікти. Для глибокого розуміння — механізм мультиканальності в рітейлі.
Як ми забезпечуємо єдиний профіль клієнта?
Клієнт може зареєструватися на сайті, купити через WB, а повернути в магазині — і система повинна зрозуміти, що це одна людина. Без цього неможлива персоналізація та історія замовлень.
Ми реалізуємо Customer Identity Resolution через ланцюжок: email → телефон → ім'я+адреса. Приклад коду:
class CustomerIdentityResolver { public function resolve(array $customerData, string $source): Customer { $customer = null; if (!empty($customerData['email'])) { $customer = Customer::where('email', $customerData['email'])->first(); } if (!$customer && !empty($customerData['phone'])) { $normalized = $this->normalizePhone($customerData['phone']); $customer = Customer::where('phone_normalized', $normalized)->first(); } if (!$customer) { $customer = Customer::create([ 'name' => $customerData['name'], 'email' => $customerData['email'] ?? null, 'phone_normalized' => $normalized ?? null, 'source_first' => $source, ]); } $customer->channelIds()->updateOrCreate( ['channel' => $source], ['external_id' => $customerData['id'] ?? null] ); return $customer; } } Як ми вирішуємо проблеми синхронізації?
Єдина історія замовлень. Клієнт в особистому кабінеті бачить всі замовлення — з сайту, Ozon, WB, POS — відсортовані за датою. Технічно це означає об'єднання замовлень з різних джерел в одну таблицю з прив'язкою до customer_id. Ми використовуємо патерн Repository для абстракції:
public function getOrderHistory(Customer $customer): Collection { return Order::where('customer_id', $customer->id) ->with(['items.product', 'source_details']) ->orderByDesc('created_at') ->get() ->map(fn($order) => [ 'id' => $order->id, 'source' => $order->source, 'source_label' => $this->sourceLabel($order->source), 'status' => $order->status, 'total' => $order->total, 'items' => $order->items->count(), 'date' => $order->created_at->format('d.m.Y'), ]); } Єдине управління промо. Промокод, створений для сайту, повинен працювати і на маркетплейсі, але тільки якщо канал дозволений.
class OmnichannelPromotion { public function apply(string $promoCode, Order $order): void { $promo = Promotion::where('code', $promoCode)->first(); if (!in_array($order->source, $promo->applicable_channels)) { throw new PromoNotApplicableException("Промокод недійсний для {$order->source}"); } $discount = $promo->calculateDiscount($order->total); $order->applyDiscount($discount, $promoCode); $promo->increment('used_count'); } } Як ми резервуємо товари за каналами?
Без загальної картини залишків ви або втрачаєте продажі (товар є в системі, але не викладений на маркетплейс), або отримуєте овербукінг (два канали продають одну одиницю).
Реалізуємо це через InventoryManager з відсоткуванням за каналами:
class InventoryManager { private array $channelReservePercent = [ 'site' => 40, 'ozon' => 30, 'wb' => 20, 'buffer' => 10, ]; public function getChannelAllocation(int $productId): array { $total = WarehouseItem::where('product_id', $productId)->sum('quantity'); return array_map( fn($pct) => (int)floor($total * $pct / 100), $this->channelReservePercent ); } } Аналітика за каналами
SELECT source, COUNT(*) AS orders_count, SUM(total) AS revenue, AVG(total) AS aov, COUNT(DISTINCT customer_id) AS unique_customers FROM orders WHERE created_at > NOW() - INTERVAL '30 days' GROUP BY source ORDER BY revenue DESC; Порівняння підходів до інтеграції
| Підхід | Час впровадження | Складність | Консистентність |
|---|---|---|---|
| ETL (періодичне завантаження) | 2-4 тижні | Низька | Низька (затримки) |
| API Gateway з синхронними запитами | 4-8 тижнів | Середня | Середня (ризик таймаутів) |
| Event-driven (CDC + черги) | 6-12 тижнів | Висока | Висока (реальний час) |
Ми зазвичай обираємо третій варіант — він дає найменші затримки і масштабується. Event-driven архітектура в 2-3 рази швидша за ETL при синхронізації залишків. Детальніше про CDC — в документації Debezium.
Порівняння стратегій резервування
| Стратегія | Ризик овербукінгу | Гнучкість розподілу | Складність реалізації |
|---|---|---|---|
| Фіксований відсоток | Низький | Низька | Низька |
| Динамічний за продажами | Середній | Висока | Середня |
| Повний сток (пул) | Високий | Середня | Висока |
Процес роботи
- Аналітика — вивчаємо поточну архітектуру, список каналів, обсяги даних, бізнес-правила.
- Проектування — малюємо модель даних, API-специфікації (OpenAPI), схему обміну.
- Реалізація — пишемо Core, інтеграційні адаптери, тести (unit + integration).
- Тестування — наскрізні сценарії: замовлення на сайті → скасування в мобільному додатку → повернення на маркетплейсі.
- Деплой — roll-out за каналами, моніторинг через Grafana та алерти.
Ми гарантуємо консистентність даних у реальному часі. Наші інженери мають 5+ років досвіду в побудові розподілених систем. Для реального проекту — наприклад, для мережі магазинів меблів ми інтегрували 5 каналів, що дозволило скоротити кількість повернень на 25% за рахунок точного відображення залишків.
Що входить в роботу
- Розробка Unified Commerce Core (інвентар, клієнти, замовлення, промо).
- Інтеграція з 3+ каналами (сайт, маркетплейси, мобільний додаток).
- Документація API та схеми даних.
- Навантажувальне тестування та оптимізація.
- Навчання команди замовника.
Терміни
Базова система на 3 канали — від 20 до 30 робочих днів. Для 5+ каналів — до 50 днів. Вартість розраховується індивідуально після аудиту існуючої інфраструктури. Отримайте консультацію для оцінки вашого проекту.
Наш досвід
Ми реалізували 15+ omnichannel-проектів для e-commerce. Серед клієнтів — магазини зі значним оборотом. Інженери мають 5+ років досвіду в побудові розподілених систем. Зв'яжіться з нами — ми допоможемо визначити оптимальну архітектуру для вашого бізнесу.