Introduction
Claude can run a full Gabor-Granger pricing analysis — build a demand curve from survey responses, calculate a revenue-optimizing price, and check whether that price actually beats its closest rival before calling it an answer. A plain prompt run twice on identical data produced two different wrong prices, $149 and $249. An engineered prompt, run on the same data, found $99 as the leading price with $149 flagged as statistically tied — and got the same answer every time. Code execution needs to be turned on in Settings > Capabilities for the verification step to run.
A note on what's real here: the "AI-assisted analysis add-on" in this guide doesn't exist — it's invented for this post, not a real Sprig product. The 300 survey responses are synthetic, generated to behave like a real pricing study, including realistic survey drop-off. Nothing here is a real finding, price, or usage number.
What is Gabor-Granger pricing analysis?
Gabor-Granger is a pricing survey method, developed by economists André Gabor and Clive Granger in the 1960s, that asks respondents whether they'd buy a product at each of several prices. The pattern of yes/no answers across those prices builds a demand curve. Multiplying that curve by price produces a revenue index you can use to compare candidate prices directly.
The method does one specific thing well: it shows where revenue peaks along a demand curve for a single product. It doesn't model how respondents would react to a competitor's price, and it assumes respondents already understand roughly what they'd be paying for — it isn't built for a product people have never encountered.
When should you use Gabor-Granger instead of another pricing method?
Use Gabor-Granger when you already have a short list of candidate prices and want to know how each one performs — not when you're starting from zero on an unfamiliar product. It answers "which of these specific numbers should we charge," not "what would people pay for something like this in general." Treat the output as one input into a pricing decision, not the whole decision, since it's a single-product read that ignores competitor pricing.
What data does this Gabor-Granger example use?
This guide tests five prices for a fictional AI-assisted analysis add-on: $49, $99, $149, $199, and $249 a month, across 300 synthetic survey responses. The survey started respondents at $149 (the median price) and branched them up or down depending on their answer, so each person saw only two or three of the five prices. Starting at the median is one option; randomly assigning each respondent a starting price and laddering from there works too — the analysis doesn't care which one you used.
If your own pricing survey already lives in Sprig, you can skip the export step entirely: Sprig MCP gives Claude direct access to your surveys and responses, so you're working from current data instead of an hour-old CSV.
What's the difference between branching and fixed-sequence Gabor-Granger surveys?
Gabor-Granger surveys use one of two designs, and each trades something real for something else.
What is a fixed-sequence Gabor-Granger survey?
Every respondent answers about every price point independently — five separate questions per person in a five-price study, instead of two or three. That's more time in the survey, but it can catch something branching structurally can't: a respondent who says yes to a higher price and no to a lower one. That contradiction is real, and it can come from fatigue, a misread question, or genuinely unstable preferences. When it shows up, it's a signal to look closer at that response.
What is a branching (laddered) Gabor-Granger survey?
Respondents start at a given price and get routed up or down based on their answer — say no, and you're routed toward lower prices only; say yes, and you're routed higher. It's shorter to sit through, which helps completion rates, but it makes the yes-then-no contradiction impossible to observe, not because respondents become more consistent, but because the survey stops asking the question that would reveal it.
This guide uses the branching design, since it's what most current survey tools default to. The engineered prompt below (step 2) still covers the fixed-sequence case: it checks for non-monotonic answers, then runs the analysis with and without those respondents to see if the conclusion changes. A second synthetic dataset, built specifically to test this with known inconsistent answers planted in it, confirmed the check finds exactly those respondents without changing any other part of the pipeline.
What happens if you don't engineer the prompt?
A plain prompt — "run the analysis and tell me what price we should charge" — produced two different wrong prices on two separate runs: $149 and $249, a hundred dollars apart, with nothing in either output flagging that something might be off. Both failed for the same underlying reason: Gabor-Granger requires cumulative demand, since a respondent whose ceiling is $249 would also say yes at $99, and neither run accounted for that.
| Attempt | Data source used | Method | Recommended price | Why it's wrong |
|:---:|:---:|:---:|:---:|:---:|
| 1 | Pre-coded price_bucket column | Treated each bucket's share of the sample as demand at that price | $149 | Skips cumulative logic — a $249-ceiling respondent never gets added back into the $99 figure |
| 2 | Raw branching answer columns | Treated each column's yes-rate as independent demand | $249 | Ignores that branching excluded respondents from being asked each price, so the denominator is wrong |
Both attempts still showed demand that exists and declines somewhere across the tested range — useful for a rough gut check on whether a price range is in the right neighborhood. Neither is defensible enough to put in front of an actual pricing decision.
What prompt gets Claude to run a verified Gabor-Granger analysis?
The reusable prompt below turns purchase-intent answers into a cumulative demand curve and a revenue index at each price, then checks whether the top price is statistically distinguishable from its closest rival. It works whether your survey asked every price independently or used branching — steps 1–2 get either shape of data into a clean table, and everything from step 3 on is identical either way.
What should the Gabor-Granger prompt include?
- If a coded outcome column exists, verify it against the raw answer columns before using it, and show the check.
- For fixed-sequence surveys: check monotonicity, report the fraction of inconsistent respondents, then run steps 3–8 twice (excluding and including them) and report whether the conclusion changes.
- For each tested price, calculate the % willing to pay at least that price, using code — not estimation.
- Flag any price backed by fewer than 30 respondents as too few to trust; a zero base counts as too few too.
- Add a 95% confidence interval around each % that clears that bar.
- Calculate a revenue index (price × full-precision % willing) at each price, carrying the confidence interval through; round only at display time.
- Identify the highest revenue index and check whether its confidence interval overlaps the next-highest price's — report a leading candidate, not a settled answer, if it does.
- Recompute every number independently, ideally with a different method or code path, and flag any mismatch rather than silently correcting it.
- Present the verified numbers as a table: price, n, % willing, 95% CI, flagged/not, revenue index, 95% CI on the index.
- Plot the demand curve and revenue index with error bars, built only from the table in step 9.
- Summarize in 2–3 sentences, distinguishing what the data actually supports from what's simply the highest point estimate.
What setting do you need to turn on first?
Code execution and file creation must be turned on for every number in this prompt to come from executed code rather than an estimate. It's on by default for Team and Enterprise accounts; Free, Pro, and Max users turn it on under Settings > Capabilities. If your survey data already lives in Sprig, connect the Sprig MCP integration to point Claude at the live study instead of an exported CSV.
What did the verified analysis find?
Before touching pricing, the pipeline checked the coded outcome field against the raw answers — all 300 matched. The cumulative willingness-to-pay curve came out clean and monotonic: 94.3% at $49, 76.7% at $99, 47.3% at $149, 23.0% at $199, 12.7% at $249. Every price point cleared the 30-respondent minimum (the thinnest had 38).
The revenue index peaks at $99 — the highest point estimate of the five. But its 95% confidence interval overlaps $149's, so the two are statistically tied. $199 and $249 are genuinely out; their intervals don't come close. What the data supports is "$99 or $149, probably $99," not a confident single winner.
Plain vs. engineered prompt: which price can you trust?
| | Plain prompt | Engineered prompt |
|---|:---:|:---:|
| Demand curve shape | Non-monotonic both times, rises where it should only fall | Cleanly declining across all five prices |
| Recommended price | $149 (attempt 1), $249 (attempt 2) | $99, with $149 explicitly flagged as statistically tied |
| Coded outcome field | Trusted without being checked | Verified against raw answers before use |
| Sample size per price | Never checked | Checked against a 30-respondent floor; zero counts as too few |
| Uncertainty | None, either attempt | Every number carries a 95% confidence interval |
| Reproducibility | Two runs, two different prices, $100 apart | Same data, same result, every time |
Best for: any pricing decision you'd need to defend to a team, a finance function, or a board — situations where "I asked Claude and it said $149" isn't an acceptable citation on its own. Not ideal for: a five-second gut check on whether a price range is even in the right neighborhood — the plain prompt is faster and adequate for that narrower job.
What should you check before trusting an AI-run pricing analysis?
- Ordinal outcome variables need cumulative handling. If a higher answer implies the lower ones too (a price ceiling, a rating), a raw share-per-category read isn't the same as a cumulative one — check which your calculation actually produced.
- State each column's population explicitly. Say whether a column reflects the full sample or a branching-created subset; a yes-rate on the wrong denominator is a real error, not a rounding difference.
- Ask for a confidence interval on every number, and have Claude check whether the top two candidates actually clear each other before naming a winner.
- A zero base counts as too few, not just small nonzero counts — the same gap caused a real miscount in a related cross-tabs guide before it was closed here.
- Run both versions when a data-quality decision could go either way (excluding vs. including a flagged respondent), and report whether the conclusion changes, not just whether the point estimate does.
- Run the plain version of your own prompt once, honestly, before deciding the engineered version was overkill — the gap here showed up twice, by two different mechanisms.
Frequently Asked Questions
Why not just ask Claude to run this directly? A plain prompt produced a curve that rises and falls where it should only fall, on both attempts, landing on $149 first and $249 second — with nothing in either output suggesting the number might be wrong. It's fast either way; whether it's actionable depends on what you asked for.
Is this a Claude-specific problem, or would other AI tools hit it too? This guide only tested Claude. The actual failure — treating an ordinal ceiling variable as independent, non-cumulative shares — comes from how the data gets interpreted, not from anything Claude-specific. Any tool working from branching survey data without knowing Gabor-Granger requires cumulative handling would plausibly land somewhere similar.
Does Gabor-Granger tell you the exact price to charge? Not by itself. It gives a demand read and the inputs for a revenue-maximizing calculation. A genuinely profit-maximizing price also requires your actual costs, and for subscriptions, retention and acquisition cost — plus accounting for the known gap between what people say they'd pay and what they pay at checkout.
How is this different from Van Westendorp's Price Sensitivity Meter? Van Westendorp asks four open-ended questions (bargain, good deal, expensive, too expensive) and lets respondents supply the prices, mapping an acceptable range from perceived value. Gabor-Granger flips that: you supply specific candidate prices, and respondents give a direct yes/no on each. Van Westendorp suits an unfamiliar product with no known plausible range; Gabor-Granger suits a specific shortlist of prices you're already choosing between.
Can I use this prompt if my survey didn't use branching? Yes. Step 2 is written for fixed-sequence data: it checks for monotonicity (a contradiction fixed-sequence surveys can produce and branching ones structurally can't), then compares results with and without inconsistent respondents included. A second synthetic dataset with known violations confirmed the rest of the pipeline works the same regardless of survey design.
What do I do if my top two prices come back statistically tied? Report both as viable and let other factors decide — round pricing tiers, competitor comparisons, page clarity. If the decision is high-stakes enough to resolve statistically, increase the sample size; tighter confidence intervals will either separate the two prices or confirm they're genuinely equivalent.
How do you know the plain version wasn't set up to fail? It was run twice, independently, with genuinely different approaches: attempt 1 used the pre-coded column and pandas; attempt 2 used the raw branching columns, plain Python, and the standard csv module instead. Different source data, different tool, different mechanism — both times the curve was non-monotonic and the price was wrong.
Does this mean a quick, unengineered analysis is never worth trusting? No. Both plain attempts still showed demand existing and declining somewhere across the tested range. For a fast, rough read on whether a price range is in the right neighborhood, that's genuinely useful. The gap shows up once you need a specific number defensible enough for an actual pricing decision.
