Skip to main content

​
Persona panel — the wind tunnel

Paid traffic is the most expensive way to find out a landing page doesn’t work. A statistically useful read on one variant costs hundreds of dollars of clicks; a field of five variants costs five times that, mostly spent on the losers. The persona panel is the wind tunnel you run first: a jury of synthetic visitors — built from your own brand research — reads each variant the way a real visitor would and predicts how it will perform, for cents rather than hundreds of dollars, in minutes rather than weeks. The panel prunes, it never concludes. Even the best published systems for predicting A/B winners are right roughly three times out of four, so a panel ranking is a prior for which variants deserve real traffic — the experiment with live visitors still makes the call. What makes the panel more than a guess is that every prediction it writes is later scored against what reality measured on the same variant and metric, so its track record is a number you can check, not a promise.

​
Personas come from your brand brief

A persona is not a stock demographic. When the lead-engine flow researches a customer and writes its Brand Brief, each marketing angle is grounded in a real buyer cohort — who they are, what outcome they want, what makes them skeptical, what language they read in. Each active cohort is materialised as a persona skill: a Knowledge skill whose body is that identity, plus declared sampling ranges (patience, scroll speed, device mix) so no two simulated visits are identically robotic. Personas are addressed by slug — persona-{customer}-{cohort}, e.g. persona-acme-robotics-roi-led — and that slug is how every prediction is attributed in the experiment ledger. You can refine a persona like any other skill (“make the ROI-led persona more price-sensitive”), or create one directly by asking an agent, and the next panel run uses it.

​
Personas learn from your real traffic

A brand-brief cohort is a good starting point, but it encodes what you believe about your audience, not what your audience does. Once your published pages have accumulated real traffic, Erdo grounds your personas in it. A weekly grounding pass clusters the last 28 days of your first-party page-events sessions into behavioral archetypes — by where they arrived from, how far they engaged, and whether they converted — and rewrites each matching persona in place: the authored identity (its voice, its objections) stays, but a measured section now carries the cohort’s real intent rates, and the persona’s sampling ranges come from the cluster’s statistics instead of an authored guess. The slug never changes, so the persona’s calibration history stays continuous across the update. Grounding is conservative by design, because a persona built on noise poisons every prediction that uses it:
  • It never runs on thin data. No grounding below 1,000 sessions in the window, and no cohort becomes a persona below 150 sessions and 10 conversions. Below those gates the pass is a silent no-op — a data-starved org keeps its authored personas untouched.
  • It updates, it doesn’t multiply. Each cluster refreshes the persona closest to it in channel and intent shape. A cluster that matches nothing — a genuinely new segment in your traffic — files a single item in your Activity feed proposing a new persona, rather than quietly minting one.
Because every prediction records which version of a persona made it, the judge calibration readout splits each persona’s accuracy by grounding source — authored vs. measured — so you can watch grounded personas out-predict their authored selves as your traffic teaches them.

​
What a panel run does

Given an experiment whose variants are pages — Erdo pages or external page URLs (see below) — the panel:
  1. Renders each variant once, mobile-first — the full page, the lead-form modal open, and the modal with the keyboard up: the three views a phone visitor actually experiences. Every persona judges the same renders, so variants are compared like-for-like.
  2. Runs each persona over each variant, several times. Each persona×variant cell is sampled K times (default 5) and the prediction is the average — single reads of a synthetic visitor are noisy in a way repeated draws largely cancel.
  3. Predicts the standard page metrics. Each cell forecasts, as per-visit probabilities, the same micro-conversion vocabulary your live pages emit — scrolling halfway and to the end, clicking the call-to-action, starting the form, submitting a lead, playing a video — plus an attention walk over the page’s sections and the point where the persona would give up and why.
  4. Writes it all into the experiment ledger. Every forecast is an ordinary experiment observation attributed to its persona, and one aggregate records the ranking and the kill list — the variants predicted at less than half the leader’s rate.
Because predictions and real measurements share one vocabulary and one ledger, calibration is automatic: once live traffic measures the same variants, the judge calibration readout shows how often each persona ordered variants the way reality did.

​
Panelling pages that aren’t Erdo pages

A variant’s page doesn’t have to be built in Erdo. When you set a variant’s treatment to an external URL instead of an Erdo page, the panel renders that public page directly and predicts on its screenshots exactly as it does for an Erdo page — so an agency can paste a client’s live landing pages, run the panel over them, and get a ranking without rebuilding anything first. Set it with url=<https://…> on the CLI’s --variant flag, or treatment_url when you create the experiment over MCP/REST; it is mutually exclusive with an Erdo-page treatment (a variant is one or the other). External pages get fewer renders than Erdo pages: only the mobile full-page shot, not the lead-modal-open and keyboard-up views. Those extra shots depend on knowing the page’s own lead call-to-action, which an arbitrary page doesn’t expose, so the panel captures what it safely can and records exactly which views each persona saw alongside every forecast. Only public http(s) URLs are visited — a private address or a signed-in Erdo workspace URL is refused, because the renderer is anonymous and would only capture a login screen.

​
Running a panel

The panel is part of how Erdo operates experiments, not just an endpoint: the agent that runs your workstreams and experiments carries the panel, the diagnosis sessions, and the decision-policy readout as its own tools, and its operating rules tell it to run the panel on any new variant set before paid traffic is spent, to treat predicted magnitudes as pruning evidence until the calibration record supports them, and to use Stage B only for diagnosis. So when experiments run autonomously, the wind tunnel is already in the loop — you don’t have to remember to ask. Ask an agent in a thread:
“Run the persona panel on the hero-copy experiment and kill the losers.”
Or run it directly:
The MCP tool is erdo_run_persona_panel. All three surfaces return a panel_run_id immediately — the panel runs in the background, and its results are ordinary observations:

​
Reading the output honestly

  • Compare within a run, not across runs. A panel run pins its screenshots, prompt, and model, so its numbers are comparable to each other; a different run may sit higher or lower overall.
  • The ordering is the signal. Absolute probabilities from synthetic visitors are uncalibrated until enough real measurements have paired against them; which variant beats which is the part that transfers.
  • Reasoning is explanation, not evidence. Each prediction carries the persona’s one-line rationale and each cell a bail point — useful for diagnosing why a variant loses, never a substitute for the numbers.

​
Stage B — diagnostic sessions on the survivors

The panel tells you which variants win and lose; it can’t always tell you why the losers lose. Stage B answers that: for the top surviving variants, each persona actually browses the page in a real mobile browser session and narrates its walk — what it read, where its attention broke, and where it gave up and why. Sessions are deliberately diagnostic only. A handful of browsing agents is far too small a sample to estimate conversion, so Stage B never produces a number, only the story behind the panel’s numbers — the personas are even barred from submitting forms, because the surviving pages are live and a submission would write a fake lead. Run it after the panel, on the panel’s ranking (the default), or hand it your own:
The MCP tool is erdo_diagnose_experiment_personas. Sessions run in the background; each persona×survivor session lands as an action_taken observation carrying the bail narrative and the typed browsing trace: