How it works
How Jonbar rehearses a decision, end to end.
Jonbar copies how your market reacts to prices and campaigns, using your own sales history. Then it plays every version of your decision in that copy, side by side. This page walks through each step.
The synthetic market
We don't ask anyone what they'd buy. We model the market from what people did buy.
Jonbar keeps its own simulated market: a model of how shoppers in a category respond to price, discounts, timing and competitors, built from published research and the data we accumulate. Your sales history fine-tunes it to your products, so it reacts to a decision the way your real market has reacted before. Every version of your decision is played out in it, side by side, before a single real customer sees it.
How the market model is fitted to you
01 · Read
Your sales history.
Product × day sales, prices, campaigns and unit cost. No personal customer data: what people bought is enough, who they are is not needed.
02 · Calibrate
How your market reacts.
Price elasticity, promo lift, pull-forward, the dip after a campaign, sales your other products lose. The market model starts from published ranges and is tuned with your history; where your history is thin, the run says so.
03 · Multiply
Many plausible markets.
Each version is run many times. In every run, sales fluctuate the way real weeks do; where your data can't pin an effect down, each run also tries a different plausible value for it.
04 · Play
Same markets, every version.
Every version meets exactly the same markets, so the gap between versions comes from the decision, not from luck. You get a probable range, not a single number.
Why not ask an AI to play your customers?
Asking a language model to play your customers is fast, but research keeps finding it a weak stand-in for real behaviour. Sales history is the behaviour itself.
40.8/100
the best language models' score at simulating human behaviour across 20 datasets.
Source: SimBench, ICLR 2026
r = 0.20
average correlation between people and their AI twins, even when each twin was built from 500+ of that person's own answers.
−20.3%
future revenue from existing customers after deep discounts: the kind of effect a model of real behaviour has to carry.
We test the engine on markets whose answer we know.
Before any real decision, we generate synthetic sales histories with a price response we set ourselves, and check that the engine finds it again. Only then do we move on to the harder test: blind runs on real past decisions.
How it works
Six steps from your sales history to a decision you can defend.
Every panel below is real engine output from one sample run: ground coffee sold on two channels, decision on one of them.
Sample scenario · synthetic data · sim-core v0
One loop: see, rehearse, choose, learn.
- See
- 01 Connect
- Rehearse
- 02 Fork
- 03 Simulate
- 04 Compare
- Choose
- 05 Explain
- Learn
- 06 Ship and measure
- SeeIn pilot
- RehearseIn pilot
- ChooseIn pilot
- LearnBuilding
Upload a CSV: date, SKU, units, price, unit cost, campaign flag. At least 12 weeks. No customer data.
Define the versions of the decision. Here: keep as is, a price change, a 10% campaign in weeks 3-4.
Each world runs on the same market: price elasticity from your history plus a prior, promo lift, after-window dip, cannibalization.
Totals per world, with a range under the model's own assumptions.
Where the result comes from: units in the campaign window, the dip after it, cannibalized units, discount cost.
A winner per metric, or "no clear winner" when the ranges overlap. Not yet backtested, and labelled so.
| date | product_id | units | net_price | unit_cost | campaign | channel |
|---|---|---|---|---|---|---|
| 2026-09-07 | CF-250 | 392 | 250.0 | 140 | — | mkt_a |
| 2026-09-14 | CF-250 | 747 | 200.0 | 140 | discount | mkt_a |
| 2026-09-21 | CF-250 | 388 | 250.0 | 140 | — | mkt_a |
| 2026-09-28 | CF-250 | 404 | 250.0 | 140 | — | mkt_a |
| 2026-09-07 | CF-250 | 119 | 250.0 | 140 | — | own_site |
| 2026-09-14 | CF-250 | 120 | 250.0 | 140 | — | own_site |
| 2026-09-21 | CF-250 | 118 | 250.0 | 140 | — | own_site |
| 2026-09-28 | CF-250 | 135 | 225.0 | 140 | — | own_site |
Whole file: 58 rows · 2 channels · 2 campaign rows · 2026-03-16 → 2026-09-28
own history: CF-250 after-window effect and extra lift read from its past campaigns (mixed with the prior); other campaign dynamics are prior-based
- Two channels · one decision
- 8 weeks
- 3 worlds
- seed 42
- 80% range
- Not yet backtested
01 Connect
Upload a CSV: date, SKU, units, price, unit cost, campaign flag. At least 12 weeks. No customer data.
sales_history.csv · 58 rows · synthetic date product_id units net_price unit_cost campaign channel 2026-09-07 CF-250 392 250.0 140 — mkt_a 2026-09-14 CF-250 747 200.0 140 discount mkt_a 2026-09-21 CF-250 388 250.0 140 — mkt_a 2026-09-28 CF-250 404 250.0 140 — mkt_a 2026-09-07 CF-250 119 250.0 140 — own_site 2026-09-14 CF-250 120 250.0 140 — own_site 2026-09-21 CF-250 118 250.0 140 — own_site 2026-09-28 CF-250 135 225.0 140 — own_site Whole file: 58 rows · 2 channels · 2 campaign rows · 2026-03-16 → 2026-09-28
own history: CF-250 after-window effect and extra lift read from its past campaigns (mixed with the prior); other campaign dynamics are prior-based
- Two channels · one decision
- 8 weeks
- 3 worlds
- seed 42
- 80% range
- Not yet backtested
02 Fork
Define the versions of the decision. Here: keep as is, a price change, a 10% campaign in weeks 3-4.
- A Keep as is
- B CF-250 price 250 → 265
- C CF-250 −10% · wk 3–4
- Two channels · one decision
- 8 weeks
- 3 worlds
- seed 42
- 80% range
- Not yet backtested
03 Simulate
Each world runs on the same market: price elasticity from your history plus a prior, promo lift, after-window dip, cannibalization.
- Two channels · one decision
- 8 weeks
- 3 worlds
- seed 42
- 80% range
- Not yet backtested
04 Compare
Totals per world, with a range under the model's own assumptions.
Units by world · 8 weeks World Value 80% range A 3,823 baseline B 3,463 3,293 – 3,632 C (Winner) 4,242 4,051 – 4,396 Three metrics: total, difference vs. A, range World Total vs. A Range Gross profit A 420,516 — — B 432,809 +12,293 −6,120 … +29,272 C 432,053 +11,537 −1,236 … +26,749 Volume A 3,823 — — B 3,463 −360 −530 … −191 C 4,242 +419 +228 … +573 Revenue A 955,719 — — B 917,556 −38,163 −74,676 … +4,500 C 1,025,896 +70,177 +28,087 … +116,661 - Two channels · one decision
- 8 weeks
- 3 worlds
- seed 42
- 80% range
- Not yet backtested
05 Explain
Where the result comes from: units in the campaign window, the dip after it, cannibalized units, discount cost.
World C · where the result comes from - Units in campaign window
- Dip after the window
- Cannibalized units
- Discount cost
- Gross profit vs. A
own history: CF-250 after-window effect and extra lift read from its past campaigns (mixed with the prior); other campaign dynamics are prior-based
- Two channels · one decision
- 8 weeks
- 3 worlds
- seed 42
- 80% range
- Not yet backtested
06 Ship
A winner per metric, or "no clear winner" when the ranges overlap. Not yet backtested, and labelled so.
Decision · winner by metric - Gross profitNo clear winnerB +12,293 · range −6,120 … +29,272 · crosses zero
- VolumeCWinner
- RevenueCWinner
- Two channels · one decision
- 8 weeks
- 3 worlds
- seed 42
- 80% range
- Not yet backtested
Try a rehearsal
Pick a decision. Pick what you care about.
The versions
- AKeep as is
- BPrice +8%
- C20% off as a pack, weeks 5-6
Gross profit by world · 12 weeks
2,200,918Winner · B
| World | Value | 80% range |
|---|---|---|
| A | 2,087,395 | baseline |
| B (Winner) | 2,200,918 | 2,133,428 – 2,256,772 |
| C | 2,071,071 | 2,019,176 – 2,125,434 |
Why
Gross profit: Winner B, 2,200,918.
On gross profit, world B leads world A by +5.4%. World C sells the most during the campaign window (1,288,900 revenue), but world B keeps the most gross profit over 12 weeks (2,200,918).
Engine notes (3)
- ! user-set: HP-100 elasticity was entered, not estimated
- ! user-set: HP-200 elasticity was entered, not estimated
- ! prior-based, no own campaign history: HP-100
The market model
The whole market, layer by layer.
A decision meets shoppers, a shelf of competitors, a platform's fees and its ranking. We're building them as separate layers, because each one is calibrated with different data, and we open a layer only when there is data that could prove it wrong.
- CalibrationBuilding
Every forecast will be locked at decision time and compared with the real result, so the model can be corrected.
- Ranking algorithmRoadmap
How the platform's ranking responds to price, campaigns and ratings. Not modelled today; it needs ranking history to calibrate.
- Platform economicsBuilding
Commission, shipping or courier share, the discount the platform funds and product cost will come off each order. Output: contribution margin.
- ShelfBuilding
The competing list at the moment you decide, taken as one snapshot: prices, ratings, campaigns. How competitors react will stay your assumption.
- Shoppers (demand)In pilot
Demand fitted to your own sales: price response, promo lift, pull-forward, the dip after a campaign, cannibalization.
How we know
Until it's rehearsed, your campaign is a guess.
And a rehearsal is only worth something if it's been checked against reality.
Backtest first
We publish the backtest before the claim.
Before we tell you how accurate Jonbar is, we will test it blind on past pricing and campaign decisions whose outcomes are public, and publish the result next to what a simple rule scored on the same cases. We develop the model on 26 public past decisions. The blind test set is still being assembled; it is sealed before the model runs. Until it's published, every run says "not yet backtested".
Read the methodologyLearn Building
Every forecast is locked, then checked.
When you choose a version, its forecast is locked before it goes live. Checking it against what really happened, and writing the miss onto your scorecard and into the model, is what we're building. In a chain, the decision will roll out branch by branch in waves, so there is always a group that hasn't changed yet to compare with.
Illustration: 40 branches split into three waves of 14, 13 and 13, a week apart; each wave switches one week after the previous one.
Alternatives
Four ways to test a campaign.
| Live A/B test | Spreadsheet forecast | LLM shopper survey | Jonbar | |
|---|---|---|---|---|
| Cost | Real discount spend | Your time | Low | Pilot |
| Time | One campaign period | Hours | Minutes | 2-week pilot |
| Risk to customers | Real shoppers see both | None | None | None |
| Competitor reaction | Real | Manual | — | Simple rule |
| How far to trust it | Measured | Unknown | Unknown | Blind backtest being built; published good or bad |
| On a marketplace | Often not possible | Yes | Yes | Yes |
Qualitative comparison, no named vendors.
FAQ
Questions sellers ask first.
What is Jonbar, in one sentence?
A simulation and decision engine for commercial decisions. Jonbar keeps a simulated market of how shoppers react to prices, campaigns and the world around them, calibrates it to your products with your sales history, and shows which plan leaves the most gross profit before you run it.
Where does the market come from? Do you make up data?
No invented customers, no invented sales. Jonbar keeps its own market model: how shoppers in a category respond to price, discounts, timing and competitors, built from published research and the data we accumulate. Your sales history fine-tunes that model to your products and your price levels. Where your history is too thin to pin an effect down, the run falls back to published ranges and says so.
How accurate is it?
We don't know yet, and we won't give you a number before we do. We are building a blind backtest on past decisions with public outcomes: the model is developed on 26 of them, and the test set is sealed before it runs. We will publish the result, good or bad, next to what a simple rule scored on the same cases. In a pilot, we first run one of your own past campaigns blind so you can see our miss before you trust a new run.
Isn't this just asking an AI what shoppers think?
No. Language models are a weak stand-in for real shoppers: the best ones score 40.8 out of 100 at simulating human behaviour (SimBench). Jonbar's engine learns from what people actually bought. A language model may help explain a result in plain words later; it never makes the decision.
What can I ask it today?
Three things are live. Give it a goal and your limits and get the three best plans (goal to decision). Compare versions of a campaign. Test a price change before you make it. Bundles, launches and restaurant chains are on the roadmap, labelled as such on the site.
What data do I need?
Product × day (or week) sales for the last 12 weeks or more: units, net price, list price, campaign flag and unit cost. A CSV export is enough. We never need customer names, addresses or order numbers.
Does it work for marketplace sellers and my own store?
Yes, both. We read marketplace-funded discounts as their own column and flag them, so you can see where the price moved without your decision. We have not validated accuracy on Turkish data yet; your pilot's blind test is where that happens.
Can't I just A/B test the campaign?
On a marketplace you usually can't show two prices or two campaign mechanics for the same product at once, and peak campaigns come once a year. Jonbar lets you compare versions before the one real run.
What does the pilot cost?
The pilot has a fixed price; we share it when we invite you from the waitlist.
What happens to my data?
It is used only for your runs, isolated from other customers at the database level, deleted on request and kept no longer than 90 days. Runs use no AI language model today, so your data is not sent to one.
What happens after the pilot?
You keep the decision memo and the blind-test result. If it was useful, we agree on an ongoing plan for your decision calendar; if our miss was too big, you'll know that too.