What we read, what we never touch, and where it goes.
Written for the person your champion has to convince. You can answer all of it before you talk to us: the data flow, how long we keep things, what determinism guarantees, and the schema every run returns.
A URL is enough. Nothing has to be installed.
No SDK. No tag. No script on your site. No agent in your network. WhyUser reads public assets the way a browser does.
- The public URL you submit, rendered as a browser sees it
- Ad creatives, subject lines and email bodies you paste in
- Public buyer evidence: product reviews, community threads, competitor comparisons
- Optional and opt-in, after you are a customer: call transcripts you choose to upload
- Optional and opt-in: analytics access, used only to grade past predictions
- Anything behind your authentication
- Your CRM, unless you explicitly connect it later
- Your production systems, in any direction
- Live visitor traffic. Nothing runs on your page
- Personal data of your customers. We work from public voice, not identities
Four stages, in order.
Everything crosses the boundary once, at stage one. After that the run happens inside WhyUser.
Ingest
You submit a URL or paste an asset. We fetch it over TLS, as an anonymous visitor would. No credentials are used or stored.
Compile
Ground Reality builds your committee from public buyer evidence. Each trait carries a fingerprint and a compile date, so you can see it predates the asset.
Run
Agents read the asset in separate passes across three declared moods. Seeds are fixed, so a run can be replayed rather than re-rolled.
Return
Findings, conflict graph, ranked fixes and the full audit trail. In the app, as a standalone HTML report, or over the API.
Where it is processed
See the security page for regions, sub-processors and the current certification status.
How long it is kept
Runs are retained so the evidence ledger can grade them later. Retention windows and deletion on request are covered in the DPA.
Tenant isolation
Your compiled committee and your runs are scoped to your workspace. Enterprise supports multiple workspaces separated by business unit.
Same fingerprints, same buyers. Replayed, not re-generated.
This is what separates an instrument from an opinion generator, and it is the thing your technical reviewer should press hardest on.
Ask a general assistant the same question twice and you get two answers. That is fine for drafting and useless for measuring. You can never tell whether a score moved because of your fix or because of the model.
WhyUser fixes the seeds. A committee built on a given date carries a fingerprint. Run the same asset against the same fingerprint and the same buyers read it the same way. Change one section and only that section can move.
That is what makes a version to version comparison mean something. It is also what lets us seal a prediction before the outcome exists and grade it honestly afterwards.
Every field a run returns.
The shape below is what the interactive report renders. Nothing in the UI is computed from a summary. The report is a view over this record.
// A run record, abbreviated. Every finding traces to a compiled trait // and a verbatim line, and every fix traces to the findings it closes. { "experiment_id": "AN-90670518", "asset": { "type": "landing_page", "url": "https://example.com/lp" }, "committee": { "fingerprint": "6f744b870006001f", "compiled_at": "2026-08-12", "roles": ["CH", "TD", "EB", "EU", "GR"], "seeds_per_role": 10, "behavioural_profiles": ["distracted", "skeptic", "ideal"] }, "verdict": { "driver": "goal_approached", "converted": 45, "abandoned": 5, "submitted": 0 }, "findings": [{ "id": "B3", "state": "broken", "zone": "nav", "severity": "high", "confidence": 0.20, "sample": 50, "roles_reacted": ["GR", "TD"], "summary": "Technical validation path unclear", "verbatim": "I can't find a 'Developers' or 'Docs' link...", "compiled_trait": { "kind": "evidence_need", "fingerprint": "6f744b870006001f", "predates_asset": true }, "repaired_by": [2] }], "conflict_graph": { "edges": [ { "from": "EU", "to": "TD", "weight": 0.9, "state": "snaps", "reason": "no docs evidence" }, { "from": "CH", "to": "EB", "weight": 0.9, "state": "snaps", "reason": "no proof evidence" } ], "snapped": 2, "total": 7 }, "fixes": [{ "rank": 2, "kind": "signposting", "zone": "nav", "closes": ["B3", "B2"], "unblocks": ["CH", "EB", "EU", "GR", "TD"], "spec": { "component_type": "nav_item_with_dropdown" } }] }
No orphan claims
Every finding carries confidence and sample. Low confidence findings come back marked low confidence, not quietly dropped.
Traits predate the asset
predates_asset shows the trait was built before the page was opened. That is what stops a finding being reverse engineered from the page.
Fixes map to edges
A fix is ranked by which snapped handoff it reconnects, not by page order. That is why the queue can be ordered at all.
Headless runs.
Included on Scale and Enterprise. Start a run from CI, from a CMS publish hook, or from whatever owns your launch checklist.
# Start a landing page run. SCAFFOLD: replace with the real endpoint curl -X POST https://api.whyuser.com/v1/runs \ -H "Authorization: Bearer $WHYUSER_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "type": "committee_simulation", "asset": { "url": "https://example.com/pricing" }, "committee_fingerprint": "6f744b870006001f" }' # → 202 Accepted, returns experiment_id. Poll or receive a webhook. curl https://api.whyuser.com/v1/runs/AN-90670518 \ -H "Authorization: Bearer $WHYUSER_API_KEY"
The questions we get asked in security review.
01Do we have to install anything on our site?
No. No tag, no script, no SDK. WhyUser fetches the public URL over TLS the way an anonymous visitor would. Nothing runs on your infrastructure and nothing touches live traffic.
02Does our customer data go into a model?
A first run needs no customer data. A public URL is enough. Call transcripts and analytics access are optional, opt-in, and come after you are a customer. Both are covered by the DPA, which you can read before sending us anything.
03Can we test a page that is not public yet?
Yes, and that is the normal case, since the whole point is testing before launch. Staging URLs behind basic auth work. So does a pasted HTML export or a screenshot. What we cannot read is anything behind your product login.
04How do we verify the simulated buyers are not just made up?
They are simulated and we will never claim otherwise. What you can check is the sourcing. Every finding traces to a trait with a fingerprint and a compile date that predates the asset, plus the line the agent was reading. For a harder test, run WhyUser on a campaign whose outcome you already know and grade it yourself. The accuracy page shows how we score ourselves, misses included.
05What does a WhyUser outage cost us?
Nothing in production. WhyUser sits entirely before launch and has no runtime link to your site. If we are down, your campaigns still ship. You just ship them untested, which is where you were before.
Read a real run before you talk to anyone.
We published four full reports, including the one our own simulation produced about our own homepage. Findings, conflict graph, audit trail, and the five things it told us to fix.