On this page

Protect your margin when you change prices

The outcome: know whether a price change made you money, before you roll it out further or quietly undo it.

Who this is for: whoever owns the number. This is a board-level question answered badly almost everywhere, usually because the first chart people look at is the one that cannot fail.

Time: an afternoon for the first pass, fifteen minutes per change after that.

Before you start

  • You need an API key with the copilot scope. Every step here is a question, not an endpoint — the analysis tools are reachable through the assistant, not the four public GETs. Scopes are fixed at creation.
  • You need a connected store, with orders either side of the change.
  • You need at least 14 days of orders after the change before the causal step can say anything. Do the first three steps immediately; come back for step 4.

The chart that cannot fail

Raise prices, then look at AOV. It went up.

It was always going to. AOV is a ratio, and a price rise moves it mechanically — the same basket at a higher price is a higher average order value whether or not a single customer changed their behaviour. Watching AOV rise after a price rise is watching arithmetic, not evidence.

This is why pricing decisions go wrong in a specific direction: the metric that is easiest to check is the one that confirms the decision regardless of whether it worked. The interesting questions are all downstream of it.

  • Did people buy fewer units to hold their spend flat?
  • Did fewer people buy at all?
  • Did revenue move once both of those settled?
  • And is any of it attributable to your change rather than the season?

Signal can answer all four. It cannot answer the fifth — whether margin improved — and the honest reason is at the bottom of this page.

Stage 1 — Establish that the change happened, and when

Before reasoning about an effect, confirm the cause exists. People misremember launch dates, staged rollouts drift, and a change made in the store admin is not always the change customers saw.

{"question": "When did prices actually change on the Membership product?"}

This reads your order history for actual recorded price changes rather than your intentions. Two things worth catching here:

A change you did not know about. Someone else edited a price, a discount expired, a currency rounding rule shifted. If the tool reports a change you cannot account for, stop and find out what it was — everything downstream is about the wrong event otherwise.

A change that happened over a week, not a day. A gradual rollout has no treatment date, and step 4 needs one. If that is what happened, pick the date the majority of traffic saw the new price and say so in your write-up, or accept that the causal step will be inconclusive and honest about why.

Stage 2 — Decompose, do not admire

AOV is average unit price × average units per order. A price rise moves the first term by construction. What you want to know is what happened to the second.

{"question": "How did AOV change before and after 2026-07-14, and what were the unit price and basket size components?"}

Three shapes come back, and they mean very different things.

Unit price up, units per order flat. Customers absorbed it. This is the result you hoped for and the least common.

Unit price up, units per order down. Customers held their spend and bought less. AOV may be flat or even up while you sell fewer units — and unit volume is what drives your costs, your fulfilment and often your renewals. A "successful" price rise that quietly shrinks basket size is how a good quarter becomes a bad year.

Unit price up, units per order up. Suspect this rather than celebrate it. It usually means the mix changed — the price rise pushed away the small orders and left the big ones, which looks like growth and is actually a smaller, richer customer base. Check the customer count before you believe it.

Stage 3 — Count the people, not just the orders

The decomposition tells you about orders that happened. It says nothing about the orders that did not.

{"question": "How many distinct customers bought in the 30 days before 2026-07-14 versus the 30 days after?"}

This is the number most likely to be quietly bad. A price rise that holds revenue while losing 8% of buyers has not held anything — it has borrowed from next year, because the buyers you lose are disproportionately the new ones who would have become repeat customers.

If buyer count fell and revenue held, you have a decision to make that the revenue line alone would never have surfaced.

Stage 4 — Test it causally, once you have 14 days

Everything above is description: it tells you what the numbers did. It does not tell you whether your change is why. Revenue moves every week.

{"question": "Did the price change on 2026-07-14 move revenue?"}

Then ask the same about orders. Two questions, because the interesting case is when they disagree — revenue held and orders fell means you are extracting more from fewer people, which is a strategy, but it should be a chosen one.

This runs a Bayesian interrupted time series: it models the trend before your change, projects what would have happened without it, and reports the gap with a credible interval. Seasonality is in the pre-period trend, so the projection carries it. That is the whole point — it is what separates "we had a good July" from "the price rise worked".

"Inconclusive" is a real answer here and you should accept it rather than reaching for a weaker method. See Prove a change actually worked for how to read the interval.

Stage 5 — Do the margin arithmetic yourself

Signal does not know your costs. There is no COGS in the order data, so nothing here can tell you whether margin improved — only what happened to price, volume, buyers and revenue.

That is a real limit and worth stating plainly rather than implying otherwise. What it gives you is every input except one:

margin delta  ≈  (new price − unit cost) × new units
               − (old price − unit cost) × old units

You supply unit cost. Signal supplies both prices and both unit counts, and the causal step tells you whether the change in units is attributable to you or to the weather. That is the hard part; the multiplication is not.

The failure this prevents is the common one: approving a price rise on a revenue chart, when the unit volume drop meant margin went sideways and the customer count drop meant next year got worse.

Stage 6 — Write down what you decided and why

Not ceremony. The next price change will be argued about by people who were not in this conversation, and the only thing that settles it is a record of what you predicted, what happened, and how sure you were.

Record four things: the date, the decomposition, the causal interval, and the buyer count. Four numbers and a date fit in a paragraph.

Teach it to the assistant so later answers are framed against it:

{"question": "Remember that we raised Membership pricing on 2026-07-14 and that unit volume is the metric we watch for it."}

That is stored for the whole workspace and shapes how later questions are interpreted, so keep it factual. You can see and delete anything it has kept under Settings → Privacy.

What will go wrong

You will look after seven days. The causal step needs fourteen either side and will correctly refuse. Waiting is the work.

Two changes will land in the same week. A price rise and a campaign on the same date are one treatment and cannot be separated. Plan changes apart if you want to learn from them — a week of separation is cheap compared to a year of not knowing.

Revenue will look fine and you will stop there. Revenue is the last metric to move and the first to mislead. The buyer count moves first.

Someone will quote AOV. They will be right that it went up and wrong about what it means. Stage 2 exists for that conversation.

Next

This page is maintained next to the service it describes and rendered here. Read it as markdown if you are pointing an agent at it.