Реализация мультиканальных продаж (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. Среди клиентов — магазины с оборотом от 10 млн руб/мес. Инженеры имеют 5+ лет опыта в построении распределённых систем. Свяжитесь с нами — мы поможем определить оптимальную архитектуру для вашего бизнеса.