Back in Stock: уведомления о поступлении товара

Отметим: когда товар заканчивается на складе — 80% покупателей уходят к конкурентам и не возвращаются. Форма подписки «Уведомить о поступлении» превращает эту потерю в лид: вы получаете контакт заинтересованного человека и можете вернуть его ровно в тот момент, когда товар снова в наличии. Мы реализуем Back in Stock под ключ за 1-2 рабочих дня, с интеграцией в вашу CRM и любыми каналами связи (email, Telegram, SMS). Наши инженеры имеют 5+ лет опыта в e-commerce, гарантируем стабильную работу уведомлений даже при пиковых нагрузках. Свяжитесь с нами для оценки проекта — и получите консультацию бесплатно.

Как работает уведомление Back in Stock?

Система состоит из нескольких модулей: форма на фронтенде, API для подписки, очередь задач для отправки уведомлений и механизм защиты от дубликатов. Рассмотрим каждый на примере стека Laravel + React, но реализация возможна на любой платформе.

Схема данных

CREATE TABLE back_in_stock_requests (
    id BIGSERIAL PRIMARY KEY,
    product_id BIGINT NOT NULL REFERENCES products(id) ON DELETE CASCADE,
    variant_id BIGINT REFERENCES product_variants(id) ON DELETE CASCADE,
    user_id BIGINT REFERENCES users(id) ON DELETE SET NULL,
    email VARCHAR(255) NOT NULL,
    notified_at TIMESTAMP,
    created_at TIMESTAMP DEFAULT NOW()
);

CREATE UNIQUE INDEX idx_bis_email_product
    ON back_in_stock_requests(email, product_id, COALESCE(variant_id, 0))
    WHERE notified_at IS NULL;

Уникальный индекс предотвращает дублирование подписок от одного email на один товар/вариант, пока уведомление не отправлено.

Форма подписки

Форма показывается вместо кнопки «В корзину» при stock = 0:

const BackInStockForm = ({ product, variant }: BackInStockProps) => {
  const { user } = useAuth();
  const [submitted, setSubmitted] = useState(false);
  const { register, handleSubmit, formState: { errors, isSubmitting } } = useForm({
    defaultValues: { email: user?.email ?? '' },
  });

  const onSubmit = async (data: { email: string }) => {
    await api.post('/back-in-stock', {
      product_id: product.id,
      variant_id: variant?.id ?? null,
      email: data.email,
    });
    setSubmitted(true);
  };

  if (submitted) {
    return (
      <div className="flex items-center gap-2 text-green-600 text-sm">
        <CheckIcon className="w-4 h-4" />
        <span>Мы сообщим, когда товар появится в наличии</span>
      </div>
    );
  }

  return (
    <form onSubmit={handleSubmit(onSubmit)} className="space-y-2">
      <p className="text-sm text-gray-600">Товара нет в наличии. Оставьте email — уведомим при поступлении.</p>
      <div className="flex gap-2">
        <input
          type="email"
          placeholder="[email protected]"
          className="flex-1 border rounded px-3 py-2 text-sm"
          {...register('email', { required: true, pattern: /^[^\s@]+@[^\s@]+\.[^\s@]+$/ })}
        />
        <Button type="submit" size="sm" loading={isSubmitting}>
          Уведомить
        </Button>
      </div>
      {errors.email && <p className="text-red-500 text-xs">Введите корректный email</p>}
    </form>
  );
};

API-эндпоинт подписки

public function subscribe(Request $request): JsonResponse
{
    $request->validate([
        'product_id' => 'required|exists:products,id',
        'variant_id' => 'nullable|exists:product_variants,id',
        'email'      => 'required|email|max:255',
    ]);

    // Проверяем, что товар действительно не в наличии
    $product = Product::find($request->product_id);
    if ($product->stock > 0) {
        return response()->json(['message' => 'Товар уже в наличии'], 422);
    }

    BackInStockRequest::firstOrCreate([
        'product_id' => $request->product_id,
        'variant_id' => $request->variant_id,
        'email' => strtolower($request->email),
        'notified_at' => null,
    ], [
        'user_id' => $request->user()?->id,
    ]);

    return response()->json(['message' => 'Подписка оформлена']);
}

Почему важно уведомлять о поступлении?

Товар с нулевым остатком — не потерянный спрос, а отложенный. Уведомления возвращают до 30% таких клиентов. Подписка через форму эффективнее всплывающих окон в 2–3 раза по конверсии, так как не прерывает пользователя насильно. Кроме того, аналитика подписок помогает прогнозировать спрос: товары с большим количеством ожиданий — сигнал к дозаказу у поставщика.

Как выбрать канал уведомления?

Email — экономичный вариант для массовых уведомлений, но открываемость ниже. Telegram и SMS дают более высокую конверсию, особенно для срочных товаров. Мы подключаем любой канал по вашему желанию.

Автоматическая отправка при пополнении склада

Триггер срабатывает при обновлении остатков. Это может происходить через импорт из 1С/ERP, ручное обновление в admin-панели или API поставщика. Используем очередь (Redis/Beanstalkd) для асинхронной отправки, чтобы не блокировать основной поток.

// Observer на модели Product — объединяем проверку и отправку
class ProductObserver
{
    public function updated(Product $product): void
    {
        if ($product->isDirty('stock') && $product->stock > 0 && $product->getOriginal('stock') === 0) {
            NotifyBackInStockSubscribers::dispatch($product)->onQueue('notifications');
        }
    }
}

class NotifyBackInStockSubscribers implements ShouldQueue
{
    public function handle(): void
    {
        $requests = BackInStockRequest::where('product_id', $this->product->id)
            ->whereNull('variant_id')
            ->whereNull('notified_at')
            ->get();

        foreach ($requests as $request) {
            Mail::to($request->email)->queue(new BackInStockNotification($this->product, $request));
            $request->update(['notified_at' => now()]);
        }
    }
}

Особенности для товаров с вариантами

Если товар имеет размеры или цвета, уведомление должно учитывать конкретный вариант. В схеме данных поле variant_id позволяет подписываться на нужную модификацию. При поступлении только выбранного варианта уведомление получат только те, кто ждал именно его. Это повышает релевантность и конверсию.

Email-уведомление

Письмо содержит:

• Фото и название товара
• Текущую цену с учётом скидок
• Прямую ссылку на товар с UTM-меткой utm_source=back_in_stock
• Предупреждение «Количество ограничено — успейте купить»

Письмо отправляется один раз — notified_at фиксирует факт отправки. Повторных уведомлений не бывает.

Отписка

Ссылка «Отписаться» в письме ведёт на /back-in-stock/unsubscribe?token={token}. Токен — HMAC-подпись от email и product_id, что исключает подделку. После перехода подписка удаляется без необходимости входа.

Аналитика

Метрики блока:

Товары с высоким числом подписок — приоритет для дозаказа у поставщика. Например, если на товар подписалось 50 человек, а поступило 10 единиц, стоит увеличить закупку.

Что делать, если подписка не сработала?

Редкая, но возможная ситуация: товар поступил, но уведомление не отправилось. Чаще всего причина — сбой в очереди задач или неверное состояние склада. Мы настраиваем мониторинг (алерты в Telegram/Slack) и автоматический повтор отправки. В базовой реализации очередь использует retry-механизмы Laravel: если письмо не отправлено, оно повторяется через 60 секунд, до 3 попыток.

Что входит в работу

Разработка Back in Stock под ключ включает:

• Интеграцию формы подписки в карточку товара
• API для сохранения подписок с валидацией
• Очередь уведомлений (email, по желанию Telegram/SMS)
• Шаблоны писем с адаптивным дизайном
• Механизм отписки и аналитический дашборд
• Документацию и обучение вашей команды

Закажите разработку Back in Stock — мы реализуем функционал за 1–2 дня. Свяжитесь с нами, чтобы уточнить детали и получить точную оценку.

Для дополнительной информации о механизме Back in Stock вы можете прочитать на Wikipedia.

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

Мы знаем: интернет-магазин — это не просто «сайт с корзиной». Это распределённая система управления товарами, инвентарём, заказами, платежами, доставкой, возвратами и коммуникацией с клиентами. Каждый блок имеет нетривиальную реализацию, и большинство проблем в 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-процессом

Гарантируем — каждый проект проходит этот чек-лист перед релизом. Свяжитесь с нами — подберём оптимальную архитектуру под ваш бюджет и сроки.