Pricing Bugs in Ecommerce Are Usually Data Bugs

A lot of ecommerce pricing problems do not start with a pricing team making a bad call. They start with a cron job, a stale competitor feed, a missing cache key, or a checkout calculation that does not match the product page. The symptom looks commercial: margin drops, conversion falls, carts get abandoned. The cause is often technical.

Matching competitors without context breaks margins

The most obvious mistake is also the easiest to automate badly: competitor X dropped the price, so we drop ours too.

That works until the competitor price is tied to something you did not capture. Maybe they are clearing inventory. Maybe the product is out of stock. Maybe the low price only appears for logged-in users, mobile users, or one postal code. If your system stores only sku and price, you cannot tell the difference.

A useful competitor observation needs context:

{
  "sku": "EARBUDS-001",
  "competitor": "example-store",
  "price": 45.00,
  "currency": "USD",
  "in_stock": false,
  "shipping": 6.99,
  "channel": "web",
  "location": "US-CA",
  "observed_at": "2026-08-18T10:15:00Z"
}

That in_stock field matters. If the competitor is out of stock, copying their price may throw away revenue. If they are running a temporary clearance sale, matching them for a week may train your own customers to wait.

For teams that need competitor price and stock extraction across messy pages, Wire fits this part of the problem as a structured extraction layer rather than just another price number in a spreadsheet.

Put guardrails around dynamic pricing

Dynamic pricing is not just “update prices often.” It is updating prices within rules that protect margin, trust, and sanity.

A basic pricing function should refuse to make changes when the inputs are incomplete or suspicious. For example:

from decimal import Decimal

MIN_MARGIN = Decimal("0.18")
MAX_DAILY_CHANGE = Decimal("0.12")


def propose_price(current_price, unit_cost, competitor_observation):
    if competitor_observation is None:
        return current_price, "no_competitor_data"

    if not competitor_observation["in_stock"]:
        return current_price, "competitor_out_of_stock"

    competitor_price = Decimal(str(competitor_observation["price"]))
    floor_price = unit_cost / (Decimal("1.00") - MIN_MARGIN)

    proposed = min(current_price, competitor_price - Decimal("0.50"))
    proposed = max(proposed, floor_price)

    max_down = current_price * (Decimal("1.00") - MAX_DAILY_CHANGE)
    max_up = current_price * (Decimal("1.00") + MAX_DAILY_CHANGE)

    if proposed < max_down:
        return max_down, "capped_daily_decrease"

    if proposed > max_up:
        return max_up, "capped_daily_increase"

    return proposed, "ok"

This is not a complete pricing engine, but it shows the pattern: competitor data is an input, not the authority. Margin floor, stock status, and max daily movement all matter.

Without these checks, failure is quiet. Nobody gets a stack trace. You just sell 2,000 units at a price that looked competitive and later discover that shipping and payment fees pushed the order below contribution margin.

Static prices are stale data with a nice UI

The opposite problem is leaving prices fixed while demand, inventory, and competitors move around you.

If a price was set manually three months ago, it may still look valid in the admin panel. That does not mean it is valid in the market. The technical issue is usually that price is treated as a field, not a decision backed by observations.

A better model stores price history and the reason for each change:

create table price_events (
  id bigserial primary key,
  sku text not null,
  old_price numeric(10,2) not null,
  new_price numeric(10,2) not null,
  reason text not null,
  source text not null,
  created_at timestamptz not null default now()
);

When conversion drops, you can inspect what changed. Was it a competitor match? A seasonal rule? A margin correction? A manual override?

That audit trail also helps you spot bad automation. If 80 percent of changes say competitor_match but sales did not improve, your matching rule probably needs more context.

Segmented pricing needs explicit cache keys

Customer bucketing can be useful: first-time visitors, repeat buyers, wholesale accounts, loyalty members, regional markets. It can also create nasty bugs.

The classic failure is showing one price on the product page and another at checkout because the systems used different segmentation logic. Another common one is CDN caching a logged-in or regional price and serving it to everyone.

If price depends on segment, your cache key must include the segment inputs:

price:{sku}:{currency}:{country}:{channel}:{customer_segment}

Do not hide this logic inside three services with slightly different definitions of “repeat buyer.” Put the segment calculation somewhere testable and version it. If you change the rules, you should know which orders used which version.

Price sensitivity should be measured, not guessed

Developers often get asked to “test a lower price.” That request needs an experiment design, not just a database update.

At minimum, track units sold, conversion rate, gross margin, and cart abandonment for each price variant. Revenue alone can mislead you. A lower price may increase orders while reducing total contribution margin.

A simple sensitivity check looks like this:

sensitivity = (new_quantity - old_quantity) / (new_price - old_price)

If earbuds move from $50 to $45 and monthly units increase from 1,000 to 1,300:

(1300 - 1000) / (45 - 50) = -60

The negative sign is expected: price went down, demand went up. The size tells you demand moved a lot for a $5 change. That does not automatically mean $45 is better. You still need margin math.

Checkout surprises are pricing defects

Shipping, tax, handling fees, and payment surcharges should not appear as a surprise at the last step. Users read that as a bait-and-switch, even if your backend thinks it calculated everything correctly.

This is worth testing like any other contract between services:

import { test, expect } from "@playwright/test";

test("product page estimated total matches checkout total", async ({ page }) => {
  await page.goto("/products/earbuds-001?postalCode=94107");

  const productTotal = await page.locator("[data-testid=estimated-total]").innerText();

  await page.click("[data-testid=add-to-cart]");
  await page.goto("/checkout");

  const checkoutTotal = await page.locator("[data-testid=order-total]").innerText();

  expect(checkoutTotal).toBe(productTotal);
});

This test will fail when tax rules, shipping estimates, or promotions drift between page and checkout code. That is exactly the point.

Automation needs failure modes you can see

Manual competitor checks do not scale, but automation without visibility creates a different problem. You need to know when extraction failed, when a selector changed, when a competitor blocked requests, and when the data looks statistically weird.

A pricing job should emit counts like:

competitor_observations_total
competitor_observations_failed
price_changes_proposed
price_changes_rejected_margin_floor
price_changes_rejected_missing_stock

If competitor pages vary by location, account state, or device type, Wire can help collect those observations with the surrounding context that pricing rules need.

Start with one SKU category. Store contextual competitor observations, add margin and movement guardrails, write one checkout total test, and log every price change with a reason. That small slice will show whether your pricing problem is strategy, data quality, or code.