Классическая жалоба покупателя: на сайте товар стоил 2 490 рублей, а на кассе пробили 2 790. Или наоборот — в приложении позиция «в наличии», а на складе ее нет уже вторую неделю. Внутри компании это почти всегда трактуют как ошибку сайта и отправляют задачу в веб-команду. На деле сайт чаще всего честно показывает то, что ему передали. Причина лежит уровнем ниже — в мастер-данных.
Симптом на витрине, причина в контуре
В типичном ритейле данные о товаре живут одновременно в нескольких системах. ERP хранит учетную карточку и себестоимость, PIM — описания и характеристики, система ценообразования — прайс и акции, WMS — остатки по складам, кассовое ПО — собственную локальную копию всего перечисленного. E-commerce-платформа в этой схеме шестой потребитель, а не источник.
Пока эти системы обмениваются данными по расписанию и каждая имеет право что-то дописать от себя, расхождения неизбежны. Вопрос только в том, как быстро их замечают: покупатель на кассе или отчет через месяц.
Три схемы обмена и почему они ломаются
Ночная выгрузка файлами. Самая распространенная и самая хрупкая. Между выгрузками система живет с устаревшими данными до суток. Акция, стартовавшая в десять утра, доедет до витрины к следующему утру.
Точечные интеграции «каждый с каждым». Пять систем — до двадцати связей. Каждая новая система увеличивает их число нелинейно, а изменение формата в одной точке ломает сразу несколько соседних.
Обмен через одну «главную» систему. Обычно этой ролью нагружают ERP, к которой она не приспособлена: учетный контур не рассчитан ни на онлайн-нагрузку, ни на маркетинговые атрибуты товара.
Все три схемы работают, пока ассортимент небольшой, а каналов продаж один-два. Дальше начинают сыпаться. Если ваш внутренний отдел разработки не справляется, воспользуйтесь услугой выделенной команды под ваш проект, которая есть у digital-агентство в Москве.
Золотая запись и слой мастер-данных
Решение состоит из двух договоренностей. Первая: для каждого атрибута назначается ровно один источник истины. Цена — из системы ценообразования, остаток — из WMS, описание и медиа — из PIM, учетные реквизиты — из ERP. Как только владельцев атрибута становится двое, расхождения возвращаются.
Вторая: сведение данных выносится в отдельный слой. Он собирает из этих кусков одну эталонную карточку товара — «золотую запись» — и раздает ее всем потребителям: сайту, приложению, кассам, маркетплейсам, партнерам. Витрина перестает быть местом, где данные склеиваются на лету, и становится обычным подписчиком.
Отдельная задача этого слоя — дедупликация. Один и тот же товар приходит из разных источников с разными артикулами, названиями и единицами измерения, и без правил сопоставления в каталоге неизбежно появляются двойники. Именно они дают самые заметные расхождения в отчетах о продажах.
Событийный обмен вместо расписания
Второй элемент — переход от выгрузок по часам к обмену по событиям. Изменилась цена — система ценообразования публикует событие, подписчики забирают его и обновляют свое состояние за секунды.
Это дает не только скорость. Событийная шина решает вопрос устойчивости: если сайт временно недоступен, сообщения не теряются, а ждут его в очереди и доедут после восстановления. При ночных выгрузках сбой означает потерянные сутки и ручной разбор.
Как понять, что чинить нужно данные, а не сайт
Есть несколько узнаваемых признаков:
- один и тот же товар называется по-разному в приложении, на сайте и на маркетплейсе;
- запуск акции требует ручной сверки нескольких систем;
- подключение нового канала продаж занимает месяцы, хотя товар тот же самый;
- на вопрос «сколько у нас активных SKU» разные отделы дают разные цифры;
- дубли карточек накапливаются, и их регулярно чистят руками.
Если совпадает хотя бы три пункта, переделка витрины проблему не снимет.
Вывод
Расхождение цен — это не баг фронтенда, а следствие того, что в компании нет единого согласованного представления о товаре. Наведение порядка в мастер-данных обычно окупается быстрее редизайна: оно снимает ручные сверки, ускоряет запуск новых каналов и убирает самую раздражающую для покупателя ошибку.