For technical and security review

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.

Data flow Output schema Security & DPA

The short answer

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.

What WhyUser reads

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

What it never touches

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

What this means for your review. A first run needs no integration, no data processing agreement in place, and no access grant. Your security review can run alongside the evaluation instead of blocking it. The DPA is readable before you send anything at all.

Data flow

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.

Determinism

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.

Run header · example Replayable

experiment_idAN-90670518

committee_fingerprint6f744b870006001f

compiled_at2026-08-12

seeds_per_role10

behavioural_profiles3

replayDETERMINISTIC

A test to run on us. Submit the same asset twice under the same fingerprint. The findings should match. Then submit it under a fingerprint built a month later. They should differ only where the buyer evidence changed. Any vendor claiming determinism should survive both.

Output schema

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.

API

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"

Two things to tell your reviewer up front. A run is asynchronous and takes about thirty minutes, so this belongs in a publish hook, not a blocking CI gate. And an API run costs the same credits as an in-app one: 10 for a page, 30 per ad creative. Full rates are on the pricing page.

Technical review

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.

Read the sample report Request access