> ## Documentation Index
> Fetch the complete documentation index at: https://docs.erdo.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Persona panel — the wind tunnel

> Test page variants against your brand's customer cohorts before spending a cent of paid traffic: synthetic personas predict each variant's micro-conversions, rank the field, and flag the losers.

# 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](/experiments) 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](/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](/attention) proposing a new persona, rather than quietly
  minting one.

Because every prediction records which version of a persona made it, the
[judge calibration readout](/experiments) 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](/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](/experiments) 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:

```bash theme={null}
# CLI — starts the panel and waits for the ranking
erdo experiment panel hero-copy-test --wait

# Restrict to specific personas or variants, or change the draw count
erdo experiment panel hero-copy-test --persona persona-acme-robotics-roi-led --draws 8
```

```bash theme={null}
# REST
curl -X POST https://api.erdo.ai/v1/experiments/hero-copy-test/panel \
  -H "Authorization: Bearer $ERDO_TOKEN" \
  -d '{"draws": 5}'
```

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:

```bash theme={null}
# The ranking + kill list (one decision_check row carries them)
erdo experiment observations hero-copy-test --type decision_check

# Every per-persona prediction
erdo experiment observations hero-copy-test --type prediction
```

## 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:

```bash theme={null}
# Uses the latest panel ranking, sessions on the top 3 survivors
erdo experiment diagnose hero-copy-test

# Your own survival order, more survivors, specific personas
erdo experiment diagnose hero-copy-test --top-k 4 --survivor b a d --persona persona-acme-robotics-roi-led
```

```bash theme={null}
# REST
curl -X POST https://api.erdo.ai/v1/experiments/hero-copy-test/diagnose \
  -H "Authorization: Bearer $ERDO_TOKEN" \
  -d '{"top_k": 3}'
```

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:

```bash theme={null}
erdo experiment observations hero-copy-test --type action_taken
```