Shopify automated repricing needs a trustworthy cost floor before it follows a competitor's price. In BC Supply Ops, I separated market repricing from a minimum-price audit that only raises prices. That lets the business review competitive changes without confusing them with repairs to prices already below the floor.
Why do I keep two pricing jobs?
In BC Supply Ops, the market-pricing view imports competitor research workbooks and resolves a cost-based minimum per supplier. It proposes one cent below the cheapest market listing only when that price clears the minimum. When the market sits at twice our minimum, the row is flagged as suspect and excluded from automatic application.
That threshold is a documented rule in this project, not a universal definition of a bad competitor price. For another store, I would choose review thresholds with the merchant and test them on actual comparisons. A review flag should ask someone to check the source; it should not declare the source wrong.
The minimum-price audit has a narrower job: classify variants as below minimum, at or above minimum, or missing cost. The case study records one audit of 70,418 variants: 35,869 were at or above minimum, 34,525 had no cost, and 24 were below it. Those are a recorded snapshot, not live counts or a claim about current profitability.
The missing-cost group matters as much as the underpriced group. I would never label an unauditable variant safe because no floor violation was calculated. That distinction is the foundation of the proposed review contract below.
Which cost should the floor use?
Start with the specific supplier offer that can supply the sellable variant. In this project, suppliers arrive through different APIs and spreadsheets, including different currencies. I would keep the source reference and currency beside every cost so a reviewer can trace the proposed price back to its input.
Shopify's product pricing fields describe Cost per item as the product or variant cost excluding taxes, shipping, and other costs. A populated field therefore does not prove that every expense your pricing policy cares about is included. I would document the business's cost basis before using that field in automation.
For each supplier, my proposed setup sheet would specify the cost source, freshness requirement, currency conversion policy, unit quantity, and owner. It would also say whether the rule protects a margin percentage, a markup, or an absolute contribution. Those are policy choices to resolve with the merchant, not interchangeable labels for the same calculation.
Do not repair an ambiguous product match inside the pricing job. Send it through the supplier barcode matching review first. A perfectly calculated floor attached to the wrong pack or variant is still the wrong price decision.
What should each row do before prices change?
I would build a read-only plan with an explicit action and reason for every row. Keep “not evaluated” separate from “evaluated and safe.” The operator should see why a row is excluded without reverse-engineering the calculation.
| Condition | Minimum-price audit | Market repricing |
|---|---|---|
| Cost missing or outside the accepted freshness window | Hold as unauditable | Hold; do not guess a minimum |
| Supplier or pack identity unresolved | Hold for mapping review | Hold for mapping review |
| Current price below a verified minimum | Propose a lift to the minimum | Require the same minimum before any proposal |
| Current price at or above minimum | Leave unchanged | Evaluate the verified market comparison |
| Proposed market price below minimum | Not a reason to lower the floor | Reject the undercut; review a floor-level proposal if appropriate |
| Market comparison flagged as suspect | Continue only with independently verified cost | Hold the competitive recommendation |
| Inputs changed after approval | Rebuild the plan | Rebuild the plan |
In my implementation, repricing is among the actions that produce a reviewable plan before live writes. Typed confirmations and write flags are additional controls. The table extends that documented approach into an acceptance checklist; it does not claim every listed state exists under these exact names in the project.
How do you review a competitor comparison?
I would require the comparison record to show the observed item, its source URL, observation time, price, and the matched store variant. Add the packaging, quantity, and availability evidence used to accept the comparison. Reject a comparison whose item identity cannot be explained.
For example, consider a hypothetical supplier row for a refill and a market result for a retail bottle. I would hold the comparison until someone confirms equivalence. This is an illustrative review case, not a reported incident from BeautyCorner.
Review suspiciously high prices as carefully as low ones. The documented twice-minimum guard exists to stop suspect market data from authorizing a large automatic increase. I would keep the captured evidence with the hold so a corrected source can produce a new plan.
The output should remain understandable when no change is proposed. “Unchanged because the current price clears the floor” and “unchanged because cost is missing” require different follow-up work. Put them in different queues with an owner for the missing evidence.
What should happen between approval and application?
I would save the old price, proposed price, variant ID, supplier-cost version, floor-policy version, and approval alongside the plan. Immediately before a write, recheck that the source and destination still match the approved evidence. If another operator or job changed the price, hold that row for a fresh decision.
For a custom Shopify integration, productVariantsBulkUpdate updates variants belonging to one product and returns userErrors. Its allowPartialUpdates option controls whether valid changes can persist when another variant has invalid data. The default is false; an integration must still inspect the response and reconcile what actually changed.
I would record application results per variant, then read back the relevant prices. A request sent is not an audit completed. Keep the response, observed result, and any retry decision connected to the original plan.
Rollback also needs a current check. I would restore a previous price only when the current value still matches this operation's applied value. Otherwise, an operator needs to resolve the intervening change before an old snapshot overwrites newer work.
Before enabling writes, exercise missing cost, stale cost, a packaging mismatch, a below-floor proposal, a changed destination price, and a partial failure. These are my recommended acceptance cases, not claimed test results. Keep supplier input validation separate, as described in the feed acceptance workflow.
Where should you start?
Run a read-only minimum-price audit for a bounded group of variants. Count verified safe rows, proposed lifts, and rows you cannot evaluate. Resolve the missing-cost queue before treating the audit as evidence that the catalog is protected.
Then introduce competitor proposals as a separate reviewed operation, using the multi-supplier operations overview for context. If your repricer cannot explain its cost source and exclusion reason per row, book a call. Bring a sanitized pricing export and a few disputed recommendations so we can define the rules before changing live prices.