A supplier raised their price, but a competitor didn't: when it's not worth changing your price right away

A supplier changed their price. A competitor hasn't yet. Are you already changing yours?

A change in cost price is a signal to investigate, not an automatic instruction to change your storefront price right away. Before making a decision, it's important to capture the initial state, check data quality, compare what's available on the market, and assess your own pricing constraints.

Below is a demonstration scenario. It does not describe a real customer and is not a universal rule for every category.

What to capture at the moment of the signal

If the supplier's price changed, save:

1. The supplier's previous and current price.
2. The time the change was detected.
3. Your own price for the product in your storefront.
4. Your minimum allowable price and any other active constraints.
5. The prices of the competitors you're tracking.
6. Whether the product is in stock at the sources you're tracking, if that data is available.
7. The data source and the time of the last check.
8. Previous values and any available change history.
9. Errors or incomplete responses from the source, if they appear in the system you're using.

Capturing this helps separate the initial signal from subsequent changes. Otherwise, it becomes hard to establish what changed first: the supplier's price, a competitor's offer, availability, or your own price.

Validate the signal first

A single new price doesn't prove that a durable commercial condition has changed. The cause could be a delayed update, a different product variant, a new bundle, or a source error.

Before recalculating, check:

1. Whether the product, variant, size, and bundle match.
2. Whether the link or product identifier is current.
3. Whether the source responded correctly.
4. When the last check ran.
5. Whether the history contains a previous value and a sequence of changes.

Monitoring services may collect prices, availability, and product details on a schedule, keep a history of checks, and surface source errors. But the exact fields, update frequency, and history retention period can vary by source and workspace settings. Before publishing any specific product capability, they should be verified against current documentation and configuration.

Why you shouldn't automatically change your storefront price

If a supplier raised their price and the competitor you're tracking hasn't changed theirs, the market hasn't yet given an unambiguous signal that warrants an automatic response. Several explanations are possible: the supplier's change may be durable, may apply to only one condition, or may not yet be sufficiently confirmed.

So you can't change your price automatically based on a single new cost price alone. First you need to compare it against:

1. The prices and availability of the competitors you're tracking.
2. Your own product economics.
3. Your minimum allowable price and other constraints.
4. Promotions, supply terms, and your sales model.
5. The history of previous changes.

In the provided context, there is no universal numeric threshold above which a change in cost price automatically requires a change in the storefront price. The decision depends on the seller's rules, the category, supplier terms, and the quality of the available data.

When watching is more useful than reacting immediately

Continuing to watch may be the sensible move if the change is isolated, the source was updated recently, the data is incomplete, or the competitor is holding their price. That doesn't mean the signal should be ignored. It should be captured, and you should define which changes will serve as the basis for the next decision.

You can change the price after verifying the signal's durability, the product's match, your own economics, and your active constraints. Leaving the price unchanged is also a deliberate decision, if reacting immediately creates more uncertainty than value.

What data is available across different sources

Public descriptions of monitoring services may include tracking supplier and competitor prices, scheduled checks, change history, availability data, and logging of source errors. This doesn't mean every source provides the same set of fields, or that any marketplace's official API contains the full price and stock history of competitors.

In the provided context, Yandex Market documentation confirms retrieving your own seller price along with the time of the last update, as well as your own stock data. Wildberries documentation describes retrieving your own prices, managing your own stock, and separate stock history data. Ozon's help center confirms that sellers work with their own price, minimum price, and stock in the product card.

These details can't be automatically interpreted as confirmation that full competitor price and stock history is available through a marketplace API. For each source, you need to separately verify the data it contains, how often it's updated, and any usage restrictions.

A safe algorithm

1. Capture the supplier's new and previous price.
2. Save your own price, constraints, the time, and the signal's source.
3. Verify that the product, variant, and bundle match.
4. Make sure the source responded correctly and the data is fresh enough.
5. Compare prices and availability for the competitors you're tracking, if that data is available.
6. Recalculate the product's economics using your own rules.
7. Check promotions, supply terms, the minimum price, and the sales model.
8. Choose one action: change the price, leave it unchanged, or continue monitoring.
9. Record the decision you made and the condition under which it will be revisited.

The main principle is simple: a supplier price change is a reason to recalculate your pricing decision and check the market, not an instruction to automatically push the new cost onto your storefront.

For a single product, compile a list of the data that should be recorded before a price change: the supplier's price and the time it changed, your own price and pricing constraints, the prices and availability of the competitors you track, the data source, and the time of the last check. Then review which of these data you can regularly obtain and store in your system.