Анализ6 мин чтения

Цены на Amazon: ваш оффер против Featured Offer

Как сравнивать свой оффер на Amazon с Featured Offer: сопоставленный контекст, известная доставка и протестированная офлайн-модель, сохраняющая отсутствующие данные.

На этой странице

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

Это диагностика для разработчиков авторизованных инструментов продавца. Скачиваемая модель делает это решение явным, прежде чем считать промежуточный итог «товар плюс известная доставка» до промоакций. Все примеры записей синтетические. Фиксированный скоуп — US/USD, Consumer, New, одна единица; поля количества нет, поэтому ввод с одной единицей — допущение, которое должен обеспечивать ваш адаптер.

Более низкая цена товара может дать более высокий промежуточный итог

В первом синтетическом случае ваш продавец — seller-A. Обе записи используют один ASIN, членство NON_PRIME, репрезентативную локацию и одинаковые метки службы доставки, а время наблюдений отличается на 30 секунд:

НаблюдениеТоварИзвестная доставкаПромежуточный итогПродавец
Ваш оффер$19.00$4.00$23.00seller-A
Выбранный Featured Offer$21.00$0.00$21.00seller-B

Модель считает (19 + 4) - (21 + 0) = +2.00 USD. Цена вашего товара ниже, но ваш определённый промежуточный итог выше на $2. Положительный результат означает, что ваш промежуточный итог выше; отрицательный — ниже. Известная нулевая доставка — это свидетельство; отсутствующую доставку нельзя заменить нулём.

Второй случай даёт обоим продавцам цену товара $20 и известную доставку $0. Разрыв равен 0.00, при этом featured_is_own_seller равен false: выбранный Featured Offer по-прежнему принадлежит seller-B. Третий случай меняет этого продавца на seller-A и возвращает true. Равенство цен и идентичность продавца отвечают на разные вопросы.

Эти результаты объясняют переданные записи. Они не объясняют, почему Amazon выбрала оффер, и не устанавливают цену, которая выиграет.

Выбирайте ответ, который отвечает на ваш вопрос

Имя поля «price» — недостаточное указание на происхождение. Выбирайте запись по вопросу, на который она отвечает:

ВопросПодходящее свидетельствоРоль в сравнении
Какой оффер сообщает мой продавец/SKU?Запрошенные offers из getListingsItem в скоупе маркетплейса и типа оффераНаблюдение собственного оффера
Какой оффер является featured для выбранного сегмента?featuredBuyingOptions из getCompetitiveSummary в скоупе ASIN/маркетплейсаНаблюдение Featured Offer
Какие офферы самые дешёвые?Отдельные данные lowestPricedOffers в руководстве по получению данныхДругой вопрос; не могут заменить данные о featured-оффере
Какой внешний ценовой ориентир сообщается?CompetitivePrice вне Японии; CompetitivePriceThreshold в ЯпонииОриентир по внешним ретейлерам; см. объявление о миграции
Какая цена могла бы сделать мой оффер featured?Featured Offer Expected Price, или FOEPВычисленная рекомендация, отдельная от наблюдаемого оффера

FOEP описывает вычисленную цену листинга до промоакций. Amazon явно не даёт гарантии Featured Offer, потому что на выбор могут влиять конкурирующие офферы и возможности фулфилмента для конкретного покупателя.

Для собственной стороны запрашивайте offers явно: getListingsItem по умолчанию возвращает summaries. Проверьте контекст запроса продавца/SKU и сопоставьте SKU выбранного маркетплейса с целевым ASIN, прежде чем объединять с конкурентными данными. Выберите применимый оффер B2C и аудиторию. Модель Listings Items держит эти поля оффера отдельно от сводки.

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

Сделайте сопоставимость явным контрактом

Модель принимает нормализованные записи, а не сырые ответы Amazon. Её полный файл случаев показывает точную форму. Каждая пара объявляет expected_own_seller_id независимо от обоих наблюдений, а затем передаёт тип источника, продавца, ASIN, маркетплейс, валюту, состояние, тип покупателя, членство, локацию, службу доставки, отметку времени и компоненты цены.

Выполняйте эти проверки, прежде чем передавать реальные наблюдения в эту форму:

  1. Проверяйте каждый отдельный ответ. Успешный конверт пакетного запроса не устанавливает успех каждого его элемента. Проверяйте статус, тело, ASIN, маркетплейс и запрошенный набор данных каждого элемента. Сохраняйте неудачные, отсутствующие и неполные наблюдения. Модель Pricing определяет статус по каждому элементу и необязательные наборы данных.
  2. Выбирайте целевой контекст. Featured-офферы сегментированы по членству и региональному контексту. Необязательный sampleLocation представляет локацию внутри сегмента, а не точную оценку доставки для каждого покупателя. Сохраняйте только то, что источник действительно устанавливает.
  3. Сохраняйте неизвестные компоненты. listingPrice в Pricing исключает доставку, Points и промоакции; варианты доставки — необязательные оценки. Поэтому та же модель не может оправдать молчаливое приравнивание отсутствующей доставки к бесплатной.
  4. Держите расчёт узким. Amazon предупреждает, что возвращённые промоакции могут не включать активные. Этот промежуточный итог исключает налоги, Amazon Points, применимость купонов, полное покрытие промоакций и качество фулфилмента. Это не итог на кассе. Покрытие промоакций.

Исполняемый файл проверяет точное равенство нормализованных строк членства, локации и службы. Это доверенные метки, а не доказательство эквивалентности контекстов Amazon. Он также доверяет меткам источника, продавца и товара от адаптера. Используйте null, когда контекст неизвестен; две выдуманные строки unknown создали бы ложную уверенность. US и STANDARD — лабораторные метки, а не сырой идентификатор маркетплейса и не заявленное значение варианта доставки Amazon.

Запустите модель и изучите приостановки

Распакуйте полный ZIP-архив сравнения, откройте терминал в каталоге с compare.py и выполните:

sh
python3 -B compare.py
python3 -B compare.py --csv
python3 -B -m unittest -v test_compare.py

Пакеты и учётные данные аккаунта не нужны. README документирует контракт; compare.py и набор тестов можно изучить по отдельности. Сравните stdout с записанным JSON и CSV-матрицей.

14 синтетических случаев дают три сравнения и 11 приостановок при политике по умолчанию:

СлучаиРезультатИнтерпретация
Ниже цена товара, выше промежуточный итогСравнение; +2.00Определённый собственный промежуточный итог выше
Равные промежуточные итоги, другой продавецСравнение; 0.00, флаг продавца falseСовпадающая сумма не идентифицирует вашего продавца
Равные промежуточные итоги, тот же продавецСравнение; 0.00, флаг продавца trueВыбранная запись идентифицирует вашего продавца
Нет доставки; несовпадение членства/локации/валюты; неверный собственный продавецПять приостановокВосполнить недостающие свидетельства или исправить неверное объединение
Неудачный или отсутствующий Featured OfferДве приостановкиСохранять недоступные наблюдения
Подмена внешним ориентиром, FOEP или самой низкой ценойТри приостановкиВыбрать свидетельство о Featured Offer
Наблюдения с разницей в 360 секундОдна приостановкаПревышает политику допустимого расхождения по времени по умолчанию

У приостановки нет вычисленных промежуточных итогов и разрыва: в JSON это null, в CSV — пустые ячейки. Невалидный ввод вместо этого останавливает команду с ненулевым кодом выхода. Для экспериментов отредактируйте копию cases.json и передайте --cases your-cases.json; CSV — формат вывода, а не ввода.

Максимальное расхождение по умолчанию — 300 секунд включительно, настраивается через --max-skew-seconds. Оно проверяет расстояние между временем наблюдений. Оно не проверяет ни абсолютный возраст, ни свежесть данных Amazon: две одинаково старые записи можно сравнить. Выберите политику возраста свидетельств отдельно, прежде чем использовать результат в операционной работе.

Метод: ipvolt подготовил этот анализ с помощью ИИ, проверил первичные источники и запустил офлайн-модель плюс 14 проходящих тестов 16 сентября 2026 года на CPython 3.14.7. Целевая версия исходного кода — Python 3.11+; версия 3.11 в этом записанном прогоне не проверялась. Ни аккаунт продавца, ни маппинг ответов API, ни сбор розничных цен не тестировались.

Для расхождения между отправленной ценой и вашим собственным наблюдаемым листингом используйте статью Обновления листингов Amazon: «принято» не значит «в продаже». Чтобы планировать надёжные обновления после событий листинга, используйте сопутствующее руководство по уведомлениям SP-API. Держите результат этого сравнения привязанным к двум его наблюдениям и заявленной базе промежуточного итога, прежде чем принимать ценовое решение.

ipvolt находится в разработке. Присоединяйтесь к списку раннего доступа, чтобы получить одно письмо, когда откроется доступ. Больше ничего.

Источники

  1. getListingsItem
  2. Listings Items API 2021-08-01 model, pinned revision
  3. getCompetitiveSummary
  4. Retrieve featured offers for a batch of ASINs
  5. Product Pricing API 2022-05-01 model, pinned revision
  6. Competitive-price migration and Japan exception
  7. getFeaturedOfferExpectedPriceBatch

Теги:ProxiesTroubleshooting