← {{ backLabel }}
AI Lab — Experiment

Experiment hypothesis generator

An AI-assisted workflow that turns a product problem into testable experiment hypotheses — a preview of how it works below.

1. Problem
"New users aren't reaching activation fast enough during onboarding."
↓
2. Context
Funnel data, past experiment history, and product constraints pulled in automatically.
↓
3. Hypotheses
If we shorten the setup flow to 3 steps, activation will increase because friction drops before value is shown.
If we surface a sample result immediately, activation will increase because users see value before setup.
↓
4. Experiment brief
Structured brief with metric, method, sample size, and success criteria — ready to hand to research/eng.

This is a working preview of the tool's output shape, not a live model call.

Example prompt

I feed the assistant a rough problem statement — it asks clarifying questions before it commits to a hypothesis, rather than jumping straight to a brief.

"We're seeing a lot of trial signups for our reporting tool, but only 22% of trials connect a data source in the first session. I think the setup flow is too long before people see any value. Help me turn this into an experiment."

Output screens

The assistant returns a structured brief I can hand straight to research and eng — problem framing, hypothesis, and success metrics, each as its own reviewable screen.

Hypothesis

(Suggested) If we move the data source connection to the start of onboarding for new trial signups, and ask the profile questions afterward, then the share of trials that connect a data source will increase. This is because users currently answer four questions that give them nothing back before they reach the step that leads to value.

Supporting hypotheses

(Suggested, candidates for follow-up tests, not part of this experiment)

  • Sample data first. Users who aren't ready to connect would engage more if they could see a sample-data dashboard before connecting.
  • Invite a teammate. Some sign-ups don't have credentials or permission to connect the data source. Letting them invite a colleague who does would recover part of the drop-off.

Primary metric

(Suggested) The percentage of trials that successfully connect a data source within 7 days of signup.

Secondary metrics

  • First-session connection rate. Current benchmark — shows whether connections happen earlier.
  • Trial-to-paid conversion. The real business outcome; treated as a directional signal.
  • Step-by-step drop-off in both versions.
  • Time from signup to first connection.

Experiment Brief

Connect-First Onboarding

Only 22% of trial users connect a data source in their first session, and connecting is strongly linked to converting to paid. We'll test whether moving the data source connection to the start of onboarding, and asking the profile questions afterward, increases the share of trials that connect.

Problem

Most trial users never connect a data source. Without data, they can't see the product's core value, and they rarely convert to paid. (Known)

Context

  • The current flow is: segment step → agency name and URL → intent → client count → connect data source. (Known)
  • Some users connect in a later session, but most who don't connect in the first session never do. (Known)
  • The product is a reporting tool, and the profile questions suggest the audience is agencies. (Known / inferred)

Evidence

  • 22% of trials connect a data source in the first session. (Known)
  • Connecting a data source is associated with converting to paid. (Known) — a correlation, not proof of cause.
  • Gap: no evidence yet that flow length is the cause — no drop-off data, research, or feedback. (Needs validation)

Desired Outcome

More trial users connect a data source early, which should lead to more trial-to-paid conversions.

Hypothesis

(Suggested) If we move the data source connection to the start of onboarding for new trial signups, and ask the profile questions afterward, then the share of trials that connect a data source will increase — because users currently answer four questions that give them nothing back before reaching the step that leads to value.

Supporting Hypotheses

(Suggested, candidates for follow-up tests, not part of this experiment)

  • Sample data first. Users who aren't ready to connect would engage more if they could see a sample-data dashboard before connecting.
  • Invite a teammate. Some sign-ups don't have credentials or permission to connect. Letting them invite a colleague who does would recover part of the drop-off.

Experiment

An A/B test on the onboarding flow. Only the order of steps and when profile questions appear changes — the connection step, its UI, and available data sources stay the same, so a clean result can be attributed to reordering.

Target Audience

New trial signups entering onboarding after launch. (Suggested) Exclude existing accounts, internal/test accounts, and invite-based joins.

Control

The current flow: segment → agency name and URL → intent → client count → connect data source.

Variant

The data source connection comes first, after any fields required to create the account. The four profile questions come after, either in the same session or as a short prompt later.

Open question: does anything in the profile steps affect the connection step (e.g. does segment change which data sources show)? If so, that step may need to stay first, or the connection screen needs a default.

Experiment Type

(Suggested) A/B test, 50/50 split at signup — trial volume appears meaningful and the change is low-risk and easy to reverse.

Primary Metric

(Suggested) The percentage of trials that successfully connect a data source within 7 days of signup.

  • "Successfully connect" should mean the connection worked, not just that the user clicked "connect" — otherwise errors can inflate the number.
  • A 7-day window catches users who return later, adding safety without much delay since most users don't come back after that.

Secondary Metrics

  • First-session connection rate. Current benchmark — shows whether connections happen earlier.
  • Trial-to-paid conversion. The real business outcome; treat as a directional signal, may lack power.
  • Step-by-step drop-off in both versions — fills the evidence gap.
  • Time from signup to first connection.

Guardrail Metrics

  • Profile question completion rate in the variant — agree beforehand on acceptable data loss.
  • Connection error or failure rate.
  • Support contacts during onboarding.

Success Criteria

(Suggested, confirm before launch) The variant succeeds if the 7-day connection rate improves by at least a pre-agreed minimum, with statistical significance, and no guardrail gets meaningfully worse.

Decision Framework

  • Connection up, guardrails OK, paid conversion flat/up → ship, then test sample-data or invite-a-teammate.
  • Connection up, but conversion down or data loss unacceptable → iterate on which questions come upfront.
  • No meaningful change → check drop-off data; move to sample-data or invite-a-teammate tests.
  • Connection down → stop and look at where variant users drop off.

Risks & Limitations

  • The cause might be elsewhere — without drop-off data, reordering may miss the actual problem.
  • More connections from lower-intent users may not produce more paid customers.
  • Losing profile data could affect sales follow-up or personalized onboarding.
  • May lack power to detect changes in trial-to-paid conversion.
  • Timing effects — run for full weeks to avoid seasonal or campaign skew.

Instrumentation & Analytics

  • Viewed / completed / abandoned events for each onboarding step.
  • A distinct "successful connection" event, separate from clicking "connect."
  • Connection error records.
  • Experiment version stored on the account for later analysis.
  • Sample size (needs validation) — illustratively, ~1,800 trials per version to detect 22%→26%, ~1,150 per version for 22%→27%.

Design & Engineering Requirements

  • Reorder the flow behind a feature flag with random assignment.
  • Design where/how profile questions appear after connection.
  • Handle any dependency of the connection step on profile answers.

Open Questions

  • Where do users actually drop off today? (needs validation)
  • Which profile fields do sales/onboarding truly need, and how soon?
  • Does any profile answer change the connection experience?
  • What is the weekly trial volume?
  • What improvement would be worth shipping?

Next Steps

  • Pull step-by-step drop-off data and use it to confirm or rethink this test.
  • Confirm with sales/onboarding which profile data is essential.
  • Agree on the minimum improvement worth shipping; estimate test length from trial volume.
  • Add the missing tracking events, then launch.

Why I built this

I made this skill at AgencyAnalytics to level up the other designers on the team, giving them a way to learn and explore running experiments on their own. It's part of a broader push to share the experimentation philosophy with the company.