Introducing Simulations: pressure-test ideas before you spend real traffic

Real traffic is expensive. Most sites can only run a handful of tests at once, and a lot of that budget still goes to finding something obvious: a buried button, a headline that doesn't match the ad, a page that asks for the sale too early. Simulations is the step before that spend.

See Simulations

What you can run

A simulation starts with something to explore. That can be a live page, an existing experiment, a single variant, any URL, or a mockup nobody has built yet. You set the goal, such as a trial start, a demo request or a click on the main button, and you choose who visits.

The visitors are defined by how they behave. Patience, reading depth and intent decide what each one notices and where they give up. A person who just clicked an ad, a mobile skimmer, a skeptical researcher and a returning visitor are different models. They are not one prompt with the name swapped.

RunPivot runs each visitor through every candidate. You see which version each type preferred, why, where they engaged and where they dropped off. When a skimmer loves a variant and a researcher doesn't, you know what the real test needs to settle.

Prediction, simulation, and experiment

These are three different questions, and mixing them up is how teams waste traffic.

A forecast cannot tell you how a new headline will land. A live test can, but only after you have spent the visits. Simulation is the part in between: change the inputs and see what shifts. RunPivot runs the simulation and the experiment, so a promising idea does not have to be rebriefed into another tool.

A model of the visit, not a prompt

Asking a chatbot to pretend it is a customer gives you a paragraph. A simulation gives you a visit.

A language model can read the page. The visit comes from a behavioural model: how long someone stays, how much they read, and how ready they are to act. Those traits follow how people use the web. Some scan a screen and leave. Some read the proof. Some arrive from an ad already checking whether the promise matches.

The visitor has to get through the layout in front of them, toward the goal you set. A trial button on the first screen is a different visit from one two scrolls down, because a mobile skimmer may never reach it.

What comes back is a trace: the preference, the reason and the drop-off. It is a useful signal. It is not a measured lift, and it is not a reason to skip the experiment.

Where experimentation goes from here

The scarce resource in a testing program is not ideas. It is traffic, and the weeks those visits take. Teams that learn faster will be the ones that stop using live experiments to discover obvious problems.

Simulated customer behaviour changes the order of the work. Explore a wider set of ideas while they are still cheap to change. Narrow five concepts down to the two worth a real test. Spend traffic on the question the simulation could not answer, usually the one where visitor types disagree.

That loop is the future of the program, not a replacement for it. Real visitors still decide what ships. Simulation is what you do before the experiment: pressure-test the page, the offer and the audience, then confirm the winner with a proper A/B test.

Over time, the same workspace should hold both steps. Change something, see how different visitors might respond, and measure what actually happened, without exporting notes into a slide and starting again somewhere else.

Run the first one

Simulations is available in RunPivot now. Point it at a page you already have, pick the visitors who match your traffic, and read the trace before you commit a test slot.

See how Simulations works

Run a simulation →