> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sprig.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Gabor Granger
*Build a demand curve from survey responses, calculate a revenue-optimizing price, and verify it before calling it an answer. This example has been tested and validated with Claude.*
You have a short list of candidate prices and want to know how each one performs. Gabor-Granger answers "which of these specific numbers should we charge"- not "what would people pay for something like this in general." It's a single-product read that doesn't model competitor pricing, and it works best when respondents already understand what they're paying for.
**Note on survey design:**
This prompt handles both fixed-sequence surveys (every respondent sees every price) and branching surveys (respondents are routed up or down based on their answer). Steps 1–2 normalize either shape of data into the same clean table; everything from step 3 on is identical either way.
For the full walkthrough, including a side-by-side comparison of two plain-prompt attempts that each produced different wrong prices, the demand curve output, and notes on how Gabor-Granger compares to Van Westendorp, see the [full Gabor-Granger guide](https://sprig.com/guides/gabor-granger-analysis-claude).
## Prompt
Replace the bracketed placeholders with your own column names, price list, and threshold.
```text expandable lines theme={null}
I have a Gabor-Granger pricing survey dataset. I want to build a
demand curve, calculate a revenue index at each price point, and
identify the revenue-optimizing price with confidence intervals.
What this prompt does:
- Turns purchase-intent answers into a cumulative demand curve and
revenue index at each tested price
- Checks whether the top price is statistically distinguishable from
its closest rival before calling it a winner
What it returns:
- A verified table: price, n, % willing to pay, 95% CI, flagged/not,
revenue index, 95% CI on the index
- A demand curve and revenue index chart with error bars
- A plain-language summary distinguishing what the data supports from
what's simply the highest point estimate
Please:
1. If a pre-coded outcome column exists, verify it against the raw
answer columns before using it and show the check. For branching
surveys, reconstruct cumulative willingness-to-pay from the raw
columns rather than trusting the coded field alone.
2. For fixed-sequence surveys: check monotonicity (a respondent who
says yes to a higher price and no to a lower one). Report the
fraction of inconsistent respondents, then run steps 3-8 twice —
excluding and including them — and report whether the conclusion
changes. For branching surveys, skip this step.
3. For each tested price, calculate the percentage of respondents
willing to pay at least that price using cumulative logic: a
respondent whose price ceiling is $249 is also counted as willing
at $99. Use code, not estimation.
4. Flag any price point backed by fewer than [N, e.g., 30] respondents
as too few to trust. A zero base counts as too few, not just small
nonzero counts.
5. Add a 95% confidence interval around each percentage that clears
the minimum sample threshold.
6. Calculate a revenue index (price × full-precision % willing) at
each price, carrying the confidence interval through. Round only
at display time, not during calculation.
7. Identify the price with the highest revenue index. Check whether
its confidence interval overlaps the next-highest price's interval.
If it does, report a leading candidate, not a settled answer.
8. Recompute every number independently using a genuinely different
method or code path. Flag any mismatch rather than silently
correcting it.
9. Present the verified numbers as a table: price, n, % willing,
95% CI, flagged/not, revenue index, 95% CI on the index.
10. Plot the demand curve and revenue index with error bars, built
only from the table in step 9.
11. Summarize in 2-3 sentences. Distinguish what the data actually
supports from what is simply the highest point estimate.
```
## Setup
**Code execution must be enabled** for step 4's verification to run. It's on by default for Team and Enterprise accounts. Free, Pro, and Max users: enable it under **Settings > Capabilities**.
If your survey data lives in Sprig, skip the export, the [Sprig MCP](/docs/native-ai/sprig-mcp) connects live surveys and responses directly into Claude so the analysis runs on current data.
## How it works
If a pre-coded price column exists, the prompt checks it against the raw answer columns before using it. Branching surveys reconstruct cumulative willingness-to-pay from raw columns rather than trusting a derived field.
Fixed-sequence surveys can produce a contradiction branching ones can't: a respondent who says yes to a higher price and no to a lower one. The prompt reports how many do this, then runs the analysis both ways- with and without those respondents- and tells you whether the conclusion changes.
Calculates % willing to pay *at least* each price using cumulative logic. A respondent whose ceiling is \$249 is counted as willing at \$99, \$149, and \$199 too. Skipping this step is what caused two wrong prices (\$149 and \$249) in plain-prompt testing on identical data.
Any price backed by fewer than your threshold (e.g., 30 respondents) is flagged. Zero counts as too few, not just small nonzero counts.
Every percentage and revenue index (price × % willing) gets a 95% confidence interval. Rounding happens only at display time to avoid compounding errors.
Every percentage and revenue index (price × % willing) gets a 95% confidence interval. Rounding happens only at display time to avoid compounding errors.
Identifies the highest revenue index, then checks whether its confidence interval overlaps the next-highest price's. If it does, both are reported as viable, not a single winner. In testing on a 300-response synthetic dataset, \$99 was the leading candidate with \$149 flagged as statistically tied.
Every number is recomputed using a genuinely different method before it's reported.
A verified table and a demand curve + revenue index chart with error bars, both built from the same verified numbers.
A verified table and a demand curve + revenue index chart with error bars, both built from the same verified numbers.
2–3 sentences that separate what the data supports from what's simply the highest point estimate.
## Verify your own results
* **Demand should decline monotonically.** A curve that rises between two price points is a signal something went wrong in the cumulative calculation- check before acting on any individual number.
* **State each column's population.** Confirm whether a yes-rate was calculated against the full sample or a branching-created subset. A wrong denominator is a real error, not a rounding issue.
* **Check whether the top two prices are actually separate.** Overlapping confidence intervals mean the data can't pick between them. Don't force a single winner from a statistical tie.