Verified against ChatGPT · 2026-08-14
Design a pricing test that will actually tell you something, instead of a price change you can't interpret afterward
Produces a structured pricing experiment design — hypothesis, price points, control variables, and the read-out criteria — so a price test produces a decision rather than an ambiguous result you can't act on.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Design a pricing test for Everstitch canvas tote bag — I don't just want price ideas, I want a test structure that will actually tell me something afterward, because my last price change taught me nothing since too many other things changed at the same time.
CURRENT PRICE AND CONTEXT
Currently $38, roughly 55% margin, price hasn't changed in 14 months
WHAT I'M ACTUALLY UNCERTAIN ABOUT
Not sure if we're leaving money on the table at $38 or if raising it would tank conversion — also wondering if a $42 price with free shipping included would do better than either flat option
CONSTRAINTS ON THE TEST
Can only run a geo-split test since we're on a platform without proper A/B pricing infrastructure; roughly 3,000 monthly orders total across all regions
WHAT ELSE IS CHANGING AROUND THE SAME TIME
A new paid ad campaign launches in the same window targeting a similar audience, and it's not easily paused
STEP 1 — SHARPEN THE HYPOTHESIS
Restate my pricing uncertainty as a specific, falsifiable hypothesis ("raising price by X% will not reduce conversion rate by more than Y%" — not "see if a higher price works"). If what I described is actually two different questions bundled together, split them and say so, since a test can't cleanly answer two hypotheses stacked into one price change.
STEP 2 — PRICE POINTS AND STRUCTURE
Propose the specific price point(s) to test against the current price, and the test structure (simple A/B, sequential before/after, or a specific reason one is better suited than the other given the constraints).
STEP 3 — CONFOUND CHECK
Given what else is changing around the same time, name specifically what could contaminate the result and make the test uninterpretable, and propose either a way to isolate the pricing change from that confound or an honest statement that the test result will need to be read with that limitation in mind.
STEP 4 — READ-OUT CRITERIA
State in advance, before the test runs, what specific result would count as a clear win, a clear loss, and an inconclusive result requiring a longer test — decide this now, not after seeing the data, since deciding the bar after the result invites rationalizing whatever number comes back.
WHAT NOT TO DO
Do not propose a test design requiring a sample size or timeframe I haven't confirmed is realistic — ask me for current traffic/order volume if you need it to sanity-check whether this test can reach a meaningful result at all before treating the design as final.
OUTPUT FORMAT
Four labeled sections above, plus a one-line flag if you don't have enough volume information to confirm the test is statistically viable.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Asked for "pricing test ideas," GPT-5.1 tends to produce a plausible-sounding list of price points to try without addressing the actual reason most merchant-run pricing tests fail to produce a usable answer — not picking the wrong price, but running a test whose result can't be cleanly attributed to the price change because something else moved at the same time, or deciding what counts as a win only after seeing a number that's convenient to rationalize. Requiring the hypothesis to be restated as a specific, falsifiable statement rather than a vague "see if it works" question forces a decision about what result the test is actually trying to produce before any price point is chosen, which is the same discipline a real experimentation team applies and that ad hoc merchant price changes almost always skip. The confound-check step, built around whatever concurrent change was actually named (a new ad campaign in this example), directly targets the single most common reason merchants misread their own pricing tests: attributing a conversion change to the price when a simultaneous traffic-quality or channel-mix shift was the real driver — without explicitly naming and checking for that overlap, GPT-5.1 has no way to know a concurrent change exists at all, since it isn't implied by the pricing question alone. Setting read-out criteria in advance, before the test data exists, is a deliberate defense against a well-documented human bias (not a model failure) — deciding after the fact what counts as "good enough" tends to fit whatever number came back, and locking the bar in beforehand, in the AI-assisted design document itself, gives the merchant something concrete to hold themselves to later.
What you get back
Hypothesis: Raising price from $38 to $42 will not reduce conversion rate by more than 8% (the margin gain at $42 breaks even against an 8% conversion drop; anything worse than that is a net loss). Confound check: the new ad campaign launching in the same window will shift traffic mix toward a colder audience regardless of price, which could depress conversion independent of the price change — recommend holding the ad campaign to existing geos only during the test window, or explicitly noting in the read-out that a conversion drop can't be fully attributed to price alone otherwise...
Verified against
ChatGPT GPT-5.1 · 2026-08-14
Changelog
- 2026-08-14 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — Google Ads management, built and maintained for you — that's Scult's day job.
EXPLORE GOOGLE ADS MANAGEMENT
