Бренду, ритейлеру и дистрибьютору нужны не «данные маркетплейса вообще», а разные ограниченные наборы наблюдений. Бренд может проверять карточки согласованного каталога и отображаемых продавцов. Ритейлер — сравнивать собственную цену с сопоставимыми публичными предложениями. Оба сценария требуют источника, региона, времени, состояния сопоставления и доказательства.
Рабочая спецификация начинается с решения, а не с длинного списка доступных колонок. Затем поля проверяют на выборке и делят на публично наблюдаемые, согласованные входные, не публикуемые источником, не проверенные и не предлагаемые. Такой порядок не позволяет выдать пропуск за ноль, а частные данные — за доступный источник.
Сначала решение, затем набор данных
Одно и то же публичное поле имеет разную ценность в зависимости от владельца решения. Отображаемый продавец нужен бренду для проверки присутствия согласованного товара. Опубликованная цена может потребоваться ритейлеру для сравнения при одинаковой валюте, единице и типе цены. Метка наличия показывает только текст источника в момент наблюдения и не раскрывает складской остаток.
Перед выбором источников фиксируют:
- роль и конкретный вопрос, который должны поддержать данные;
- каталог или собственный SKU, переданный как согласованный вход;
- публичные поля, без которых решение невозможно;
- источники, регионы и окно наблюдения;
- правило сопоставления и перечень исключений;
- владельца проверки и формат передачи результата.
После этого ограниченная выборка подтверждает, какие поля наблюдаются на выбранных площадках. Выборка не является производственным результатом и не гарантирует одинаковое покрытие в будущем.
Какие наблюдения нужны бренду
Для бренда исходной сущностью обычно служит позиция согласованного каталога. По ней ищут публичную карточку и сохраняют URL, название, бренд, модель, отображаемого продавца, опубликованную цену и её тип, метку наличия, источник, регион и время.
Вопросы формулируются наблюдаемым образом:
- найдена ли точная карточка согласованного товара в выбранном источнике;
- какой продавец отображается в контексте карточки или предложения;
- какие публичные поля карточки отличаются от версии каталога бренда;
- какая опубликованная цена и метка наличия наблюдались в указанном регионе и времени.
Такой набор поддерживает мониторинг продавцов бренда, но не даёт выводов об общей узнаваемости, продажах, скрытой идентичности продавца или соблюдении правил. Эти решения остаются за командой бренда и требуют дополнительных оснований.
Если продавец, цена или наличие не показаны источником, строка получает явное состояние. Нельзя достраивать скрытое значение по соседней карточке или считать его нулевым.
Какие наблюдения нужны ритейлеру или дистрибьютору
Ритейлер или дистрибьютор может передать согласованные собственные SKU и цены, чтобы сопоставить их с публичными предложениями выбранных источников. В этом случае собственная цена остаётся входом клиента, а цена площадки — публичным наблюдением. Они хранятся в разных полях с явным происхождением.
Сравнение допустимо только для точных совпадений и сопоставимых условий. Нужно подтвердить валюту, единицу товара, тип цены, регион и окно времени. Если условия акции неясны или карточка относится к другой комплектации, строку исключают из однородного сравнения.
Набор может поддерживать мониторинг цен конкурентов, но не формирует рекомендуемую цену и не делает выводов о спросе или ценовой эластичности. Подготовительный контур описан в материале о том, как подготовить данные для мониторинга цен.
Общая модель: товар, карточка, продавец, источник, регион и время
Общая модель связывает сущности по цепочке: CatalogueSKU ↔ SourceCard ↔ DisplayedSeller ↔ Source ↔ Region ↔ ObservedAt. Она нужна, чтобы не смешивать каталог, публичную карточку и предложение продавца.
| Сущность | Что означает | Граница |
|---|---|---|
CatalogueSKU |
Согласованный товарный ключ | Не доказывает идентичность публичной карточки |
SourceCard |
Карточка или предложение выбранного источника | Один SKU может иметь несколько кандидатов |
DisplayedSeller |
Текст продавца, показанный источником | Не является выводом о юридическом лице |
Source |
Проверенная площадка или сайт | Покрытие ограничено согласованной выборкой |
Region |
Явный регион наблюдения | Неизвестный регион остаётся отдельным состоянием |
ObservedAt |
Время проверки с часовым поясом | Не обещает текущее или будущее состояние |
Эта связь обязательна и для бренда, и для ритейлера. Различаются поля решения и владельцы, но происхождение публичного наблюдения должно оставаться проверяемым.
Как сопоставлять сущности и хранить доказательство
Состояния сопоставления не объединяют: exact, analogue, ambiguous, unmatched и source_error. Только exact входит в основное сравнение одинаковых товаров. Аналог может быть полезен для отдельного обзора, но не заменяет точное совпадение. Неоднозначная, несопоставленная и ошибочная строка остаётся исключением.
На практике сопоставление товаров и карточек должно опираться на согласованные ключи: артикул, GTIN, модель или проверяемую комбинацию признаков. Похожее название само по себе недостаточно.
В строке сохраняют ссылку на доказательство: публичный URL, контрольный хэш или другой сохраняемый идентификатор. Доказательство связано с источником, регионом и временем. Если оно отсутствует, строка не может считаться готовой для основного сравнения.
Изменение правила сопоставления требует новой версии и повторной проверки затронутых строк. Нельзя молча перевести спорную строку в точную только потому, что повторная попытка вернула похожее значение.
Какие поля публичны, согласованы или недоступны
Доступность поля описывается точным состоянием:
publicly_observed— значение наблюдалось публично в выбранной выборке;agreed_client_input— значение передано как согласованный вход, например собственный SKU или цена;not_exposed— источник не показывает поле в проверенном контексте;not_checked— поле не проверялось в этой выборке;not_offered— поле не входит в предлагаемый контур.
Публично могут наблюдаться URL карточки, отображаемый продавец, название, бренд, модель, опубликованная цена и её тип, метка наличия, регион и время. Фактический набор зависит от источника и выборки. Каталожный идентификатор, собственная цена или RRP могут быть согласованным входом.
Заказы, выручка, конверсия, рекламные показатели, поисковые запросы внутри площадки, профиль аудитории и аналитика частного кабинета не входят в этот набор. Их нельзя представлять как доступные публичные поля или выводить косвенно из карточек.
Как учитывать пропуски, ошибки и устаревшие наблюдения
Пропуск всегда получает причину. Поле может быть не опубликовано, не проверено, отсутствовать в согласованном входе или оказаться недоступным из-за ошибки источника. Эти состояния нельзя объединять.
| Состояние | Действие | Чего не делать |
|---|---|---|
ambiguous |
Исключить из основного сравнения и передать на проверку | Не выбирать совпадение автоматически |
not_exposed |
Сохранить явное отсутствие публичного поля | Не подставлять ноль |
source_error |
Зафиксировать ошибку и выполнить ограниченную повторную проверку | Не считать товар отсутствующим |
| Устаревшее наблюдение | Исключить из текущего среза и обновить | Не выдавать старое значение за текущее |
| Несопоставимые условия цены | Отделить до проверки валюты, единицы и типа | Не включать в однородное сравнение |
Журнал исключений хранит ключ сущности, код, источник, регион, время, доказательство, способ обработки, ответственную роль и версию правила. Это позволяет повторить проверку и объяснить, почему строка не попала в готовый набор.
Как выбрать формат и регулярность передачи
Формат выбирают после подтверждения схемы и процесса приёмки. Для одного проекта достаточно регулярного файла, для другого нужен отчёт или API. Способ передачи не меняет требований к источнику, региону, времени, сопоставлению и исключениям.
При согласовании фиксируют:
- точные поля и типы данных;
- формат цены, валюту и единицу;
- часовой пояс
ObservedAt; - периодичность и допустимую задержку;
- правила повторной проверки и версионирования;
- срок хранения доказательств и историю;
- владельца приёмки со стороны бренда или ритейлера.
Регулярный отчёт, файл или API могут быть согласованы для конкретного проекта. Универсальной периодичности, одинаковой задержки и обязательного режима реального времени нет.
Матрица ролей: решение → поле → проверка → ограничение
| Роль и решение | Минимальные поля | Проверка | Ограничение |
|---|---|---|---|
| Бренд: где наблюдается товар | SKU, URL, источник, регион, время, состояние совпадения | Точное совпадение и доказательство | Не общая доля рынка и не узнаваемость |
| Бренд: какой продавец и цена показаны | Отображаемый продавец, опубликованная цена, тип | Публичный срез с регионом и временем | Не скрытая идентичность, не продажи и не правовой вывод |
| Ритейлер: сравнение собственной цены | Собственные SKU и цена как согласованные входы, а также точные публичные наблюдения | Одинаковые условия, окно времени и журнал сопоставления | Не рекомендация цены, не спрос и не эластичность |
| Ритейлер: доступность поля | Публичное значение или точное состояние доступности | Источник, регион, время и код исключения | Не складское количество и не будущая доступность |
Матрица показывает главное: роли используют разные поля, а решение остаётся у назначенного владельца. Синтетическая схема может помочь согласовать контракт, но не является действующим API-методом, производственной схемой или универсальным предложением.
Чтобы определить рабочий набор, передайте роль, каталог, источники, регионы и нужные решения. Следующий шаг — Согласовать поля и тестовую выборку, отдельно обозначив публичные наблюдения, согласованные входы и недоступные поля.
Применить к вашей задаче
Нужны регулярные данные, а не разовая выгрузка?
Покажите список товаров и источников. Проверим доступность данных и предложим структуру первого теста.
