Reasoning & math
AuraScore 81/100

Landing Page Experimentation Sizing Specification

Calculate required sample sizes, run duration, and minimum detectable effect math for conversion rate optimization tests.

Use this template prior to launching landing page A/B tests to prevent underpowered experiments and false positives. It produces an experimentation specification with exact statistical power parameters.

Template

Role: Senior Experimentation Statistician and Conversion Rate Optimization (CRO) Architect.

Context

  • Page Under Test: {{campaign_landing_page}}
  • Baseline Conversion Rate: {{baseline_conversion_rate}}
  • Desired Minimum Detectable Effect: {{minimum_detectable_effect}}
  • Weekly Unique Traffic: {{weekly_visitor_volume}}
  • Statistical Significance Threshold: {{statistical_significance_target}}
  • Maximum Test Window: {{max_runtime_weeks}} weeks

Task

Generate a rigorous statistical experimentation specification for {{campaign_landing_page}} that calculates exact sample size requirements per variant, validates test feasibility against traffic constraints, and outlines decision rules.

Method

  1. Convert {{baseline_conversion_rate}} and {{minimum_detectable_effect}} into relative and absolute uplift targets.
  2. Calculate the required sample size per variant using standard two-tailed hypothesis testing math at {{statistical_significance_target}} with 80% statistical power.
  3. Divide total required sample size across two variants by {{weekly_visitor_volume}} to determine runtime in days and weeks.
  4. Compare projected runtime against {{max_runtime_weeks}} to assess whether the test is adequately powered.
  5. Compute the risk of false positives (alpha) and false negatives (beta) based on the stated significance level.
  6. Formulate sample size adjustments needed if traffic drops by 15% during testing.
  7. Draft definitive sample-stopping rules and invalidation criteria to prevent peeking bias.

Constraints

  • MUST show the exact formula used for sample size determination.
  • MUST NOT permit early stopping based on interim significance before reaching target sample size.
  • All traffic allocation splits must be modeled assuming a 50/50 control/treatment split.
  • If required runtime exceeds {{max_runtime_weeks}}, MUST specify the required MDE adjustment.

Output format

Structure the specification into four parts:

  1. Statistical Parameters & Mathematical Calculations (Formula, sample per branch, total sample)
  2. Feasibility & Duration Assessment (Runtime timeline and power validation)
  3. Stopping Rules & Invalidation Guardrails (Numbered policy constraints)
  4. Sensitivity Adjustment Table (MDE trade-offs if runtime is fixed) Keep the specification concise and under 600 words.

Self-review

  • Is the mathematical formula for sample sizing explicitly written out?
  • Did I accurately compare required runtime against the maximum runtime window?
  • Are stopping rules explicit regarding peeking and sample completion?
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

research-analysis
research-reasoning-math
business-strategy-marketing-sales
cro
ab-testing
statistical-power