Інтеграція віджета вибору ПВЗ: агрегація, кластеризація, фільтри

Інтеграція віджета вибору пункту видачі на карті

Покупець додає товари в кошик, переходить до оформлення — і застрягає на виборі пункту видачі. Карта завантажується довго, маркери накладені один на одного, незрозуміло, де найближчий поштомат. Така поведінка з'їдає до 20% конверсії на етапі самовивозу. Наше завдання — об'єднати дані СДЕК, BoxBerry, DHL, 5Post та Яндекс.Доставки в єдиний віджет, який працює без гальм навіть при 5000+ точках.

Ми проектуємо схему під PostgreSQL з геоіндексами, налаштовуємо кластеризацію для продуктивності та адаптуємо інтерфейс під мобільні екрани. В результаті користувач за 10–15 секунд знаходить потрібний ПВЗ, а магазин отримує +5–10% до конверсії на етапі самовивозу. Місто користувача визначається через IP-геолокацію, що дозволяє одразу показати ПВЗ у його регіоні.

Проблеми, які вирішуємо

• Фрагментація даних: кожна служба доставки віддає точки у своєму форматі. Потрібно уніфікувати та оновлювати їх за розкладом.
• Продуктивність при великій кількості маркерів: без кластеризації браузер зависає вже на 1000 точках.
• Мобільна адаптація: карта на маленькому екрані конкурує з прокруткою.
• Точність геокодування: не всі сервіси коректно працюють в Україні, особливо для адрес у регіонах.

Як агрегувати дані кількох служб доставки?

Кожен провайдер надає API для отримання списку ПВЗ. Для СДЕК це GET /v2/deliverypoints?city_code={id}&type=PVZ, для BoxBerry — власний ендпоінт з авторизацією. Ми створюємо інтеграційні модулі для кожного джерела, мапимо поля в єдину схему:

pickup_points (
  id, provider, external_id, name, address, city_id,
  lat, lng, working_hours (jsonb),
  max_weight, max_dimensions (jsonb),
  has_fitting_room, has_cash, has_card,
  is_active, updated_at
)

Оновлення даних запускається по Cron через scheduled job раз на 6–12 годин. При падінні одного провайдера — точки залишаються з останнього успішного снапшоту. Згідно з рекомендаціями Яндекс.Карт, кластеризація доступна з версії 3.0 і дозволяє групувати маркери при масштабі нижче 12.

Порівняння картографічних сервісів

Яндекс.Карти ми обираємо для українських інтернет-магазинів з трафіком до 300 000 відвідувачів на місяць — оптимально за якістю та бюджетом. Leaflet — для корпоративних порталів з низьким навантаженням. Google Maps використовувати не рекомендуємо через юридичні та фінансові ризики.

Порівняння підходів до оновлення даних ПВЗ

Рекомендуємо комбінувати pull-запити з ручним імпортом для екстреного оновлення.

Чому кластеризація критична при великій кількості ПВЗ?

Якщо на карті 2000+ маркерів, браузер починає гальмувати — FPS падає до 5–10. Користувач не може ні вибрати точку, ні наблизити карту. Рішення — групування маркерів при масштабі менше 12. Для Яндекс.Карт використовуємо Clusterer:

import { Clusterer } from '@yandex/ymaps3-clusterer';

const clusterer = new Clusterer({
    clusterize: (coordinates, zoom) => zoom < 12
});

Для Leaflet — плагін leaflet.markercluster з аналогічною логікою. Результат: навіть на 10 000 точок карта працює плавно. Кластеризація покращує FPS у 10 разів порівняно з відображенням усіх маркерів.

Фільтри та пошук

Фільтрація ПВЗ за типом (поштомат або ПВЗ зі співробітником), режимом роботи (зараз відкрито, 24 години), додатковими сервісами (примірювальна, оплата карткою) та максимальною вагою посилки (слайдер від 1 до 30 кг). Пошук за адресою реалізуємо через геокодування — вводить адресу, отримує координати, карта центрується, підсвічуються найближчі точки. Для Яндекса використовуємо ymaps.geocode, для Leaflet — Nominatim (OSM).

Мобільна адаптація

На мобільних пристроях карта часто конкурує з прокруткою сторінки. Рішення: кнопка "розгорнути карту" — карта відкривається на повний екран через CSS position: fixed. Або — окрема bottom sheet з картою поверх контенту. Додатково: додаємо "липкий" пошук і кнопку "поруч зі мною" через геолокацію браузера.

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

• Архітектура даних: проектування та нормалізація таблиці pickup_points під PostgreSQL (з індексами по lat/lng для швидкої геопросторової вибірки).
• Інтеграція провайдерів (СДЕК, BoxBerry, DHL, 5Post, Яндекс.Доставка, власні точки).
• Розробка карти (Яндекс.Карти або Leaflet) з кластеризацією, фільтрами та геокодуванням.
• Мобільна адаптація (fullscreen/bottom sheet).
• Передача даних у замовлення (JSON-схема для API).
• Документація (api-специфікація, схема БД, інструкція з оновлення ПВЗ).
• Підтримка 1 місяць після запуску (виправлення багів, консультації).

Процес роботи

1. Аналітика — вивчаємо вимоги, список провайдерів, очікувану кількість точок.
2. Проектування — створюємо схему БД, API-контракти, прототип інтерфейсу.
3. Реалізація — пишемо інтеграційні модулі, віджет карти, backend-агрегатор.
4. Тестування — перевіряємо на 5000+ мок-точках, заміряємо Core Web Vitals (LCP < 2.5s, CLS < 0.1).
5. Деплой — розгортаємо на продакшен-сервер (Docker + Nginx + PostgreSQL), налаштовуємо моніторинг.

Терміни та вартість

Орієнтовний термін розробки віджета з агрегацією 3–5 провайдерів, кластеризацією та фільтрами — від 3 до 8 робочих днів. Точна вартість розраховується індивідуально після аналізу вимог. Зв'яжіться з нами для консультації — ми оцінимо ваш проект і запропонуємо оптимальне рішення.

Замовте інтеграцію віджета — отримайте готове рішення для вашого інтернет-магазину.

Як інтеграція служб доставки впливає на конверсію?

Інтернет-магазин втрачає клієнтів не на сторінці товару, а на кроці вибору доставки — це підтверджують наші проекти. Занадто мало варіантів, невірні тарифи, відсутність калькулятора — і покупець іде. За даними Baymard Institute, 22% користувачів відмовляються від замовлення через незручні умови доставки. Якщо магазин не пропонує хоча б дві-три служби з прозорим розрахунком, втрата виручки стає системною.

Ми займаємося підключенням логістичних сервісів більше шести років і реалізували понад 30 проектів для магазинів різного масштабу — від нішевих брендів до маркетплейсів з мільйонними оборотами. Інтеграція — це не просто «вивести список ПВЗ». Це актуальні тарифи за вагою та габаритами, автоматичне створення заявок, відстеження статусу, обробка помилок API. Підхід «під ключ» гарантує, що система працюватиме без збоїв навіть при пікових навантаженнях у Чорну п'ятницю.

Які проблеми вирішує налаштування доставки?

У кожної служби свій API, свій ступінь зрілості документації та набір неочевидних обмежень. Розберемо три найчастіші складнощі.

СДЭК API v2 — найбільш зрілий з російських перевізників. OAuth 2.0 авторизація (токен живе 24 години, потрібна логіка рефрешу), REST JSON. Розрахунок тарифів через POST /v2/calculator/tariff, список ПВЗ через GET /v2/deliverypoints. Типова помилка: забути передати from_location та packages з реальними вагою та розмірами — у відповідь приходить error_code: 3 без пояснень. ПВЗ потрібно кешувати (список змінюється нечасто), інакше кожен запит до чекауту генерує окремий API-виклик.

Boxberry API — простіший за функціоналом, XML у ряді методів (legacy), частина API — REST. Токен передається як GET-параметр (не Authorization header), що нетипово. Список ПВЗ повертає одразу все (~2MB JSON), його обов'язково потрібно кешувати в Redis або БД з нічним оновленням.

Почта Росії API — найскладніший з російських. SOAP + REST гібрид, вимагає договору та налаштування в ОС. x-user-authorization + Authorization — два різних заголовки одночасно. Нормативні відправлення, EMS, 1-й клас — різні тарифні групи. Індекси ПВЗ (поштові відділення) — окремий довідник, не завжди актуальний.

DHL Express API — для міжнародної доставки. XML-based API (DHL XML Services), хоча є більш новий MyDHL+ API. Вимагає зареєстрованого account number. Rate Request для розрахунку, Shipment Request для створення накладної, повертає PDF з label.

Чому кешування ПВЗ та тарифів обов'язкове?

Кешування — не опція, а необхідність. API СДЭК має ліміт 1000 запитів на хвилину, Boxberry — 300. Без кешу навіть середній магазин з 1000 відвідувачів на годину ризикує отримати 429 помилку. Ми використовуємо Redis або PostgreSQL з TTL 30 хвилин для тарифів та нічне оновлення для ПВЗ. Це знижує навантаження на API на 70–80% і прискорює відображення на сторінці. Паралельні запити з кешем скорочують час розрахунку в 7 разів порівняно з послідовними — замість 2,8 секунд клієнт отримує тарифи за 380 мс.

Що входить в роботу з підключення?

Кожен проект включає:

• документацію: опис архітектури, схеми даних, інструкції з експлуатації
• надання доступів: API-ключі, вебхуки, тестові контури
• навчання команди: вебінар або письмова інструкція з роботи з адмінкою
• підтримку на старті: 2 тижні пост-релізного моніторингу та виправлень

Як будуємо інтеграцію

1. Абстракція над провайдерами. Жоден магазин не використовує одну службу доставки вічно. Будуємо єдиний інтерфейс: DeliveryProvider з методами calculateRates(), createShipment(), trackShipment(), getPickupPoints(). Кожна служба — окрема реалізація. Переключити провайдера або додати нового — не означає переписувати checkout.

2. Кешування ПВЗ. Геопошук ПВЗ за координатами або містом — частий запит. Тягнути з API щоразу не можна (ліміти, затримка). Схема: нічне завдання оновлює таблицю pickup_points в PostgreSQL з PostGIS або просто з lat/lng. Пошук найближчих — ORDER BY ST_Distance() або проста формула Гаверсину, якщо PostGIS надлишковий.

3. Віджет на фронтенді. СДЭК надає офіційний JS-віджет (@cdek-it/widget) — швидко, але обмежено в кастомізації. Для нестандартних дизайнів — кастомний віджет: карта (Яндекс.Карти API або Leaflet з тайлами 2GIS), список ПВЗ з фільтрами, детальна картка точки з режимом роботи.

4. Трекінг статусів. Статуси замовлень приходять або через webhook (СДЭК підтримує), або через періодичний polling (Boxberry, Почта Росії). Для polling — черга задач (Laravel Queue, Bull для Node.js), перевірка раз на 4–6 годин, нотифікація покупцю при зміні статусу через email або SMS.

Кейс: мультиперевізник для WooCommerce. Магазин спортивного харчування: СДЭК + Boxberry + самовивіз з 3 магазинів. Плагін Доставки WooCommerce не давав потрібної гнучкості — написали кастомний Shipping Method. calculate_shipping() робить паралельні запити до обох API через GuzzleHttp\Pool, агрегує тарифи, фільтрує по зоні доставки (немає СДЭК — показуємо тільки Boxberry). Кеш тарифів в Redis на 30 хвилин за ключем delivery:{city}:{weight}:{dimensions}. Час розрахунку: було 2.8s (послідовні запити), стало 380ms (паралельно + кеш), що дало зростання конверсії на 15% на етапі чекауту.

Процес та терміни

Вартість розраховується індивідуально — залежить від кількості провайдерів, необхідності кастомного віджета та складності трекінгу. Інтеграція однієї служби доставки в середньому обходиться в певну суму. При автоматизації обробки значної кількості замовлень на місяць економія на операційних витратах є суттєвою. Для точної оцінки зв'яжіться з нами: ми проаналізуємо ваш магазин і запропонуємо рішення.

Типові помилки при самостійному налаштуванні

• Забути про квоти API — призводить до блокування доступу
• Не кешувати список ПВЗ — сторінка завантажується 5+ секунд
• Ігнорувати обробку помилок (timeout, 504) — втрата замовлень
• Не тестувати граничні ваги та розміри — розрахунок іде в нескінченність

Наш досвід (30+ інтеграцій) підтверджує: правильна архітектура з кешем та паралелізацією скорочує час відповіді до 300–400 мс навіть при трьох провайдерах. Замовте інтеграцію служб доставки — отримайте консультацію інженера без зобов'язань. Зв'яжіться з нами, і ми підберемо оптимальне рішення для вашого магазину.