How to A/B Test Enrollment Landing Pages: Sample Sizes, Goals and Tools

The short answer: As of October 1, 2026, the honest way to A/B test an enrollment landing page is to test one paid program page at a time, count submitted request-for-information (RFI) forms as the goal, and plan the sample size before launch. You need about 400 submitted inquiries per version to detect a 20% relative lift, whatever your conversion rate is. Most program pages cannot detect small changes, so test big ones first: the headline, the form, cost and aid information, or a whole new page version.

This guide is for admissions and enrollment marketing teams that run paid campaigns to program landing pages with an RFI form that redirects to a thank-you page. Here the conversion is a submitted inquiry or application, not a sale.

TL;DR

• Count the form submission on the tested page as the goal. A shared thank-you page cannot tell you which program page sent the lead.
• Inquiries needed per version: about 1,500 for a 10% lift, 400 for a 20% lift, 190 for a 30% lift.
• At 3,000 visitors a month and a 4% inquiry rate, a test that can detect a 20% lift takes about 30 weeks. Pool traffic or test bigger changes.
• Cost per inquiry is spend divided by submitted inquiries, per UTM-tagged campaign. The CRM owns everything after the inquiry.

How many inquiries you need to A/B test an enrollment page

The table below is the core planning tool. It shows how many visitors and submitted inquiries each version needs, and how long a two-version test takes at three traffic levels.

"Lift" is relative. A 20% lift on a 4% inquiry rate means 4% becomes 4.8%.

What the table shows:

• The inquiry count barely moves. Whether your page converts at 2% or 10%, a 20% lift needs roughly 380 to 420 inquiries per version. Your conversion rate only changes how many visitors it takes to collect them.
• Plan in inquiries per month, not visitors. If a page produces 60 inquiries a month, a test that needs 400 per version (800 in total) takes more than a year.
• Small lifts are out of reach for most program pages. A 10% lift needs about 1,500 inquiries per version.

For context, Optimizely reports that about 12% of experiments produce a significant win on the primary metric (across 127,000 experiments), and Analytics Toolkit found a median lift of 7.5% among tests that did win (1,001 tests, 2022). Big, confident lifts are uncommon. Plan for that.

Methodology. The numbers come from the same formula our sample size calculator and test duration calculator use: a two-sided, two-proportion test at 95% significance (z = 1.96) and 80% power (z = 0.84). Visitors per version = 2 × p̄ × (1 - p̄) × (1.96 + 0.84)² ÷ (p₂ - p₁)², rounded up, where p₁ is the current inquiry rate, p₂ is p₁ × (1 + lift), and p̄ is their average. Inquiries per version = visitors per version × p₁. Duration assumes two versions with traffic split evenly: daily visitors = monthly visitors × 12 ÷ 365, days = visitors per version ÷ (daily visitors ÷ 2), rounded up to whole weeks. "Over 2 years" means more than 104 weeks. The inquiry rates are inputs, not benchmarks for higher education. Put your own rate into the calculator. More on choosing a lift in our minimum detectable effect guide.

What to do if you don't have the volume

Most single-program pages fall short. That does not mean you can't test. It means you choose tests the traffic can answer.

1. Test bigger changes. A new headline, a shorter form or a whole new page version can plausibly move results by 20% or more. A button color will not. The realistic range for small changes is 5% to 10% (Convert; Analytics Toolkit reports a median planned lift of 6%), and that needs far more traffic than most program pages get.
2. Start with the highest-traffic program page. Your paid budget is usually concentrated on a few programs. Test there first.
3. Pool similar programs. If several program pages share one template, apply the same change to all of them and count inquiries across the group. Only pool pages whose audiences and offers are alike, or the result is hard to read.
4. Run longer, with a fixed end. Set the planned sample size in advance and stop when you reach it, not on the day the result looks good. Run for at least two full weeks so every weekday is counted twice (CXL; Optimizely and VWO set a one-week floor). Avoid running across a deadline change, such as an application deadline, without noting it.
5. Measure earlier steps carefully. Form starts or clicks on the form are more frequent than submissions, so they reach a result sooner. Use them as a guide, not as the decision. A version that gets more form starts and fewer submissions has lost.

What to test on an enrollment landing page

These are test ideas, not guaranteed wins. Each one is a single change, so you know what caused the result.

A few notes from setting up tests like these:

• Form length affects lead quality as well as volume. If you remove fields, agree with admissions which fields are needed for first contact. Check the downstream application rate in your CRM before you call a winner.
• Program-level pages usually match the ad better. If someone clicked an ad for a nursing program, a page that opens on nursing answers their question. Testing a program page against a generic page is one of the biggest changes you can make.
• A whole-page test is often the best first test for a low-traffic page. It bundles several changes into one larger difference. You learn that the new page is better, not which part made it better.

How to set the goal: form submission or thank-you page

The goal is what the test counts. On an enrollment page, you have two options.

• Form submission on the tested page. The test counts a conversion when someone submits the RFI form on the page they were shown. This counts the inquiry where it happened.
• Thank-you page visit. The test counts a conversion when someone reaches the thank-you page after submitting.

Prefer the form submission goal when several program forms share one thank-you page. Often, every RFI form on a school site sends people to the same thank-you URL. A visit to that page tells you an inquiry happened, but not which program page it came from. Counting the submission on the tested page avoids that problem.

A thank-you page goal works well when the tested page has its own thank-you URL, or when the form is embedded in a way the testing tool can't see, such as some third-party iframes.

Whichever you pick, run a test submission on each version before launch and confirm it was counted once.

How to measure cost per inquiry for paid campaigns

Cost per inquiry = ad spend ÷ submitted inquiries, for the same campaign and the same date range.

To get both numbers per campaign:

1. Tag every ad link with UTM parameters. Use utm_source, utm_medium and utm_campaign at a minimum, with one consistent naming scheme across Google, Meta and any other channel.
2. Count submitted inquiries by UTM campaign on the landing page.
3. Take spend from each ad platform for the same dates.
4. Pass UTM values into hidden form fields if your form and CRM support it, so the inquiry record keeps its source.

Here is a hypothetical example of the calculation:

Keep the split of ownership clear. The landing page owns the inquiry. The CRM owns everything after it. Systems such as Slate or Element451 track whether an inquiry becomes an applicant, an admit and an enrolled student. A campaign with a low cost per inquiry can still lose on cost per application, so review both before moving budget.

Install only on campaign landing pages, and check page speed

A testing script does not need to run on your whole university website. Add it only to the paid campaign landing pages you plan to test. This keeps the change small, makes approval easier for your web team and leaves the rest of the site untouched.

Check speed yourself. Run Lighthouse in Chrome DevTools on the landing page before you add the script and again after. Compare the same page on the same device setting. If the score drops noticeably, ask the vendor how the script loads and whether the whole page waits for it.

A/B testing tools admissions teams use

Each tool below can run landing page tests. The right choice depends on where your pages are built, your traffic and how you buy software.

Google Optimize, a free option some teams used, is no longer available as of September 30, 2023.

Switching tools: VWO and AB Tasty now operate as one company, Wingify. If your renewal is coming up, see what the VWO and AB Tasty merger means for your renewal, and compare VWO and AB Tasty alternatives for higher education.

How Humblytics fits

Humblytics is built for testing campaign landing pages without code.

• Published monthly pricing. Business is $79 a month. Scale is $279 a month and includes five team members. You can pay monthly and cancel anytime. See pricing.
• A light script. About 16 KB compressed, loaded in the background. Only the element being tested waits for its version, not the whole page.
• No-code visual editor for headline, button, image and form changes, plus page (split URL) tests for whole new versions. See A/B testing.
• Form submissions tracked without custom code, and thank-you page goals when you need them.
• Heatmaps to see where visitors stop on the page before you decide what to test.
• An onboarding call is included to set up your first test with you.

Humblytics does not replace your CRM. It measures the landing page and the inquiry; Slate, Element451 or your CRM of choice measures what happens next. Read more on Humblytics for higher education, or start a 14-day trial (card required, cancel anytime) and add the script to one campaign page first.

Sources and freshness

• Humblytics, src/lib/ab-test-math.ts, the formula behind the sample size calculator and test duration calculator. Supports every number in the sample size table. Benchmarks quoted from the same file with their stated sources: Optimizely, 127,000 experiments (12% win rate); Analytics Toolkit, 1,001 tests, 2022 (7.5% median winning lift); CXL, Optimizely and VWO (minimum duration); Convert and Analytics Toolkit (realistic lift range, 6% median planned).
• Wingify, VWO and AB Tasty Combine to Create a Global Digital Experience Optimization Leader, last updated September 14, 2026; retrieved October 1, 2026. Supports the combination of VWO and AB Tasty.
• Wingify, Inside Wingify, retrieved October 1, 2026. Supports the move to one Wingify platform at app.wingify.com.
• Wingify, Pricing, retrieved October 1, 2026. Supports custom pricing based on traffic and products.
• Optimizely, Plans and pricing, retrieved October 1, 2026. Supports customized pricing.
• Convert, Pricing, retrieved October 1, 2026. Supports published prices.
• Unbounce, Pricing, retrieved October 1, 2026. Supports A/B testing on the Experiment plan and above.
• HubSpot Knowledge Base, Run an A/B test on a page, last updated April 9, 2026; retrieved October 1, 2026. Supports the Content Hub Professional or Enterprise requirement.
• Google Analytics Help, Sunset September 2023: Google Optimize, retrieved October 1, 2026. Supports the end date of Google Optimize.
• Chrome for Developers, Introduction to Lighthouse, retrieved October 1, 2026. Supports running Lighthouse in Chrome DevTools.

The inquiry rates in the tables are inputs for planning, not measured higher education benchmarks. The cost per inquiry example is hypothetical. Vendor plans and prices can change; check each vendor's page before you buy.