The good news: GhostSnip works with Webflow without any code exports, API integrations, or changes to your Webflow project structure. One snippet in Project Settings is all you need.

Why Testing Webflow Sites Is Tricky​

Most A/B testing tools work by modifying the DOM with JavaScript. On Webflow, this creates two challenges:

1. Class naming: Webflow generates CSS classes from your custom class names. They're readable (.hero-button, .pricing-card) but you need to know where to look for them.

2. CMS-generated content: Dynamic content from Webflow Collections has dynamically-generated IDs. Use class-based selectors, not IDs.

GhostSnip's visual editor solves both by letting you point-and-click on elements in your live Webflow site — it finds the right class automatically.

Step 1 — Install the Snippet​

1. Open your Webflow project → Project Settings → Custom Code
2. Paste in the Head code section:

<style id="_gs_af">html{visibility:hidden;pointer-events:none}</style>
<noscript><style>#_gs_af{visibility:visible!important}</style></noscript>
<script>setTimeout(function(){var e=document.getElementById('_gs_af');if(e)e.remove()},3000)</script>
<script>
(function(w,d,k){
  w._sf = { siteId: k, ingestUrl: 'https://api.datsnip.com' };
  var s = d.createElement('script'); s.async = 1;
  s.src = 'https://api.datsnip.com/sdk/tracker.js';
  d.head.appendChild(s);
})(window, document, 'YOUR_SITE_ID');
</script>

3. Save + Publish your Webflow site

Your Site ID is in GhostSnip Dashboard → Settings → Snippet.

Step 2 — Create an Experiment​

1. In the GhostSnip dashboard, go to Experiments → New experiment
2. Enter a name and your Webflow URL (e.g., https://yoursite.webflow.io/pricing)
3. Click Open visual editor

The visual editor loads your live Webflow site. Click any element to select it.

The 5 Best Tests to Run on Webflow Sites​

1. Hero CTA — Text and Color​

The single most impactful test on any Webflow marketing site.

How to set it up:

• Open visual editor → click your CTA button
• The selector will be something like .hero-button or .w-button.primary-cta
• Test: "Start free trial" vs "Try for free" vs "Get started free"
• Also test: button background color

Expected lift: 8–20% in click rate

2. Headline Messaging​

Test different value proposition framing.

Example variants:

• Feature-focused: "The A/B testing platform that ships with anti-flicker and Bayesian stats built in"
• Benefit-focused: "Run better A/B experiments. Ship changes that move the needle."
• Social proof: "Join 2,400 teams already running smarter A/B tests"

Expected lift: 10–25% in scroll depth / engagement

3. Pricing Page — Plan Highlighting​

If you have a Webflow pricing page with multiple plan cards:

• Test which plan is visually highlighted ("Most Popular" badge)
• Test the CTA text on each plan card
• Test showing annual vs monthly by default

Expected lift: 10–30% in trial start rate

4. Navigation CTA​

Your navbar's CTA is shown on every page — it's the highest-volume A/B test opportunity you have.

Test:

• "Get started" vs "Start free trial" vs "Try for free"
• Button vs link styling in the nav
• Adding or removing the nav CTA entirely (if you have a prominent hero CTA)

Expected lift: 5–15% in trial starts from nav clicks

5. Entire Page Redesign (Redirect Test)​

For major redesigns — new layout, new Webflow template, new sections:

1. Build the new design as a separate Webflow page (e.g., /pricing-v2)
2. Publish it
3. In GhostSnip's visual editor, use the Redirect tab
4. Redirect 50% of /pricing visitors to /pricing-v2

This lets you test completely different Webflow designs without merging or deploying.

Split URL testing guide →

Tracking Webflow Form Submissions​

Add this to your form's page in Page Settings → Before </body> tag:

<script>
  var form = document.querySelector('.w-form form')
  if (form) {
    form.addEventListener('submit', function() {
      if (window.ghostsnip) {
        window.ghostsnip.track('form_submitted')
      }
    })
  }
</script>

Use form_submitted as your experiment goal type (Custom event).

Common Webflow CSS Selectors Reference​

When using the visual editor, you don't need to know these — just click the element and GhostSnip finds the selector. These are useful if you're writing manual experiments via the API.

Does GhostSnip Work With Webflow CMS?​

Yes. Experiments target URL patterns. Use /blog/* to run an experiment on all Collection page templates. The same visual editor changes apply to every CMS item matching that URL pattern.

Note: If your CMS collection generates different DOM structures for different items (e.g., items with vs without featured images), test selectors that exist on every item.

Start your first Webflow experiment →

A/B testing your pricing page is different from testing product pages or checkout flows. The purchase intent is mixed (some visitors are early-stage browsers, some are ready to buy), the decision is high-stakes, and the social dynamics are complex (pricing anchoring, plan comparison, annual vs monthly framing).

Here are the 8 tests that have the highest lift in SaaS pricing page data.

1. Annual vs Monthly — Which Default?​

The test: Show annual pricing as the default vs monthly pricing as the default

What most tools do: Default to monthly (lower sticker price), offer annual as a discount

The counter-intuitive winner: Annual default (in most tests) — because:

1. It surfaces the annual discount prominently
2. Anchors the perceived value at the full price, making the discount feel larger
3. Annual plans have dramatically lower churn — a self-selecting signal

Expected lift: 15–40% increase in annual plan selection rate when defaulting to annual

Implementation in GhostSnip: Toggle the checked state on the annual/monthly toggle, update displayed prices with JavaScript.

2. Number of Plans: 2 vs 3 vs 4​

The test: How many plan tiers to display

The data: 3 plans is the most-studied configuration and has the strongest body of evidence:

• 2 plans: Forces a binary choice, removes the "safe" middle option
• 3 plans: Creates a "compromise effect" — the middle option gets disproportionate share
• 4 plans: Introduces choice paralysis; Pro/Business distinction often unclear

Recommendation: If you're on 4 plans, test removing the lowest-value tier. If you're on 2 plans, test adding a middle tier.

Expected lift: 10–25% in plan conversion rate

3. Price Anchoring — Highlighted Plan​

The test: Which plan is visually highlighted (larger card, "Most popular" badge)

Common default: Highlight the middle plan
Variant: Highlight the plan one tier above your most common signup

Why this works: The highlighted plan serves as an anchor. People use it as the "safe" choice. If you highlight a higher plan, you shift the average plan upward.

Expected lift: 8–20% increase in average revenue per new signup

Implementation: Change which plan has the highlighted CSS class and "Most Popular" badge.

4. Free Trial vs Free Tier​

The test: "Start free trial" (time-limited, full features) vs "Start free" (permanent, limited features)

This depends heavily on your product:

• Freemium-first products (Notion, Figma): Free tier drives long-term acquisition
• High-touch sales products: Time-limited trial creates urgency and a clear conversion point

What to test: If you currently have a free trial, test a "free forever" plan with limited seats/usage. If you have freemium, test a time-limited full-access trial.

Signal to watch: Not just trial-to-paid conversion, but total revenue per visitor (a lower trial rate can be offset by higher activation quality).

5. CTA Button — Text and Color​

The test: Button text, color, and size

High-performing variants:

• "Get started free" vs "Start my trial" vs "Start 14-day trial"
• Primary brand color vs high-contrast (e.g., orange on a blue page)
• Larger button with more padding

Expected lift: 5–15% in CTA click rate

Pattern from data: Including "free" in the CTA text increases clicks. Including a time period ("14-day") increases perceived commitment but reduces anxiety about the billing moment.

6. Social Proof Format​

The test: Customer logos vs review scores vs testimonial quotes

Control: Company logos ("Trusted by...")
Variants:

• G2: 4.8/5 from 420 reviews
• 3 short customer quotes with photos and company name
• "Join 2,400 teams" with small avatar stack

Expected lift: 10–20% in trial start rate

Pattern: Review scores from recognized platforms (G2, Capterra) outperform unattributed testimonials. Avatar stacks with "Join X teams" perform well for product-led growth products.

7. FAQ Positioning and Content​

The test: FAQ section placement and specific objection-handling

Control: FAQ at the very bottom of the page (most visitors don't reach it)
Variant: FAQ accordion below the pricing table (before the footer)

Top objections to address (based on conversion research):

• "Can I cancel anytime?" — Reduces churn anxiety
• "What happens when my trial ends?" — Addresses billing surprise fear
• "Do you offer discounts for startups/nonprofits?" — Captures price-sensitive segments
• "Is there a setup fee?" — Common fear for SMBs

Expected lift: 8–18% in trial start rate when FAQ addresses the right objections

8. Annual Discount — Percentage vs Dollar Amount​

The test: "Save 20%" vs "Save $120/year" vs "2 months free"

The psychology:

• High-priced plans: Dollar amounts feel more concrete (Save $240/year vs Save 20%)
• Low-priced plans: Months free feels most tangible (2 months free vs Save $16)
• Startup/SMB target: Percentage discount can signal generosity

Expected lift: 5–15% in annual plan selection rate

Setting Up Pricing Page Experiments in GhostSnip​

The pricing page has the highest revenue impact per visitor of any page on your site. Track it accordingly:

Goal type for pricing tests: Combination of:

1. Page visit goal: /onboarding or /dashboard (trial activation)
2. Custom event goal: subscription_started with revenue amount

// In your trial activation or payment success flow
window.ghostsnip.track('subscription_started', {
  revenue: selectedPlan.monthlyPrice,
  plan: selectedPlan.name,
  billingCycle: 'monthly' // or 'annual'
})

With revenue tracking, you'll see not just conversion rate but average revenue per visitor — critical for pricing tests where a lift in lower-tier signups can actually hurt revenue per visitor.

Get started with GhostSnip →

Here are the 10 highest-ROI tests to run first, ordered by expected impact.

1. Product Page — Above-the-Fold CTA​

What to test: "Add to Cart" button — size, color, position, text

Control: Standard "Add to Cart" button, medium size, below product title
Variants:

• Larger button (40% more height), higher contrast color
• Sticky "Add to Cart" that follows the user as they scroll
• Text variation: "Add to Bag" / "Buy Now" / "Get Yours"

Expected lift: 5–25% in add-to-cart rate

Why it works: The CTA is the primary conversion action. Size and contrast directly affect click-through. "Add to Bag" outperforms "Add to Cart" on fashion sites in most tests; "Buy Now" outperforms for impulse purchases under $50.

2. Checkout — Number of Steps​

What to test: Single-page checkout vs multi-step checkout

Control: 3-step checkout (cart → shipping → payment)
Variant: Single-page checkout with all fields visible

Expected lift: 15–35% in checkout completion

Why it works: Every additional page in checkout adds friction and dropout. Single-page checkout eliminates the "loading between steps" UX and shows the full scope of what's required — reducing surprise at the final step.

Caveat: This requires more engineering work than most tests. But the payoff (15–35% lift) makes it the highest-ROI test on this list.

3. Cart Page — Trust Signals​

What to test: Security badges, guarantee text, and social proof near the checkout button

Variants:

• "🔒 Secure checkout" badge + SSL seal
• "30-day return guarantee" text
• "⭐⭐⭐⭐⭐ 4.9/5 from 8,400 customers" near checkout button

Expected lift: 5–15% in cart-to-checkout rate

Why it works: Cart abandonment often comes from anxiety, not decision fatigue. Trust signals at the last decision point address the most common hesitations.

4. Product Page — Image Gallery​

What to test: Number of images, types of images, gallery layout

Variants:

• Lifestyle images (product in use) vs product-on-white
• Video demo as first gallery item
• Zoom functionality on hover

Expected lift: 10–20% in add-to-cart rate

Why it works: Online shoppers can't touch the product. Images are the primary trust-building mechanism. Lifestyle images (showing the product being used in context) consistently outperform studio shots on fashion and home goods.

5. Product Page — Social Proof​

What to test: Reviews quantity, rating display, and review content selection

Variants:

• Show "4,283 reviews" vs just the star rating
• Pin the most helpful 1-star review at the top (counterintuitive, but increases trust)
• Show review count near the CTA button

Expected lift: 8–18% in add-to-cart rate

Why it works: The number of reviews is often more persuasive than the average rating. 500 reviews at 4.6 stars typically outperforms 20 reviews at 5.0 stars.

6. Cart Page — Upsell/Cross-sell Placement​

What to test: "Frequently bought together" position and format

Variants:

• Inline in cart vs popup modal
• Before vs after the cart summary
• "Complete the look" (apparel) vs "Add accessories" (electronics)

Expected lift: 5–12% in average order value

Why it works: Cart page visitors have demonstrated intent to buy. Cross-sell to them at peak buying intent, not on the product page where purchase is uncertain.

7. Shipping Threshold — Display and Messaging​

What to test: How prominently you show the free shipping threshold

Control: "Free shipping on orders over $75" in footer
Variants:

• Progress bar in cart: "Add $12 more for free shipping" with visual fill
• Persistent banner on product pages
• Threshold amount change ($50 vs $75 vs $100)

Expected lift: 8–20% in average order value

Why it works: Free shipping threshold messaging is the single most underoptimized conversion lever in e-commerce. Most stores mention it once in the footer. A prominent progress bar creates a goal-completion motivation that dramatically increases basket size.

8. Email Capture — Incentive Type​

What to test: What you offer in exchange for email signup

Variants:

• 10% off first order
• Free shipping on first order
• Access to a sale (exclusive early access)
• No incentive, just "Stay updated"

Expected lift: 20–40% in email capture rate

Why it works: "10% off" is the default choice for 90% of stores. Because of this saturation, "free shipping" often outperforms it — it feels more tangible. "Early sale access" outperforms all on fashion/luxury.

9. Search → Product — Filter Experience​

What to test: Search results page filtering UI

Variants:

• Faceted filters in sidebar vs chips at top
• "Most Popular" vs "Best Match" default sort
• Price range slider vs checkbox ranges

Expected lift: 10–25% in search-to-purchase rate

Why it works: Poor filter UX is the top reason search users don't find what they're looking for. If 30% of your traffic enters through site search, filter UX improvements have an outsized impact.

10. Post-Purchase — Re-engagement​

What to test: What you show on the order confirmation page

Control: Basic order summary
Variants:

• Product recommendation widget (complementary items)
• Referral offer ("Give a friend 15% off, get 15% off your next order")
• Account creation CTA with benefit framing ("Save your details for faster checkout next time")

Expected lift: 5–15% increase in second purchase rate (measured 30 days later)

Why it works: Immediately post-purchase is peak brand affinity. Customers are happy and engaged. Most stores show a receipt — a missed opportunity to drive the next action.

Setting Up Revenue Tracking for E-Commerce Tests​

To measure impact on actual revenue (not just CVR), add revenue tracking to your checkout:

// On order confirmation page
window.ghostsnip.track('purchase', {
  revenue: 89.99,
  currency: 'USD',
  orderId: 'ord_123'
})

GhostSnip will automatically show revenue per visitor for each variant in your results — so you can see if a CVR lift comes with a basket size trade-off.

Revenue tracking setup guide →

For those cases, DOM patches won't cut it. You need split URL testing (also called redirect testing).

What Is Split URL Testing?​

Split URL testing routes different visitors to completely different URLs. Instead of modifying the current page with JavaScript, you:

• Control group: Sees /pricing (current page)
• Variant group: Gets redirected to /pricing-v2 (new design)

Both pages are fully separate — different layouts, different copy, different frameworks if needed. The A/B testing tool handles the routing and tracks which variant each visitor saw.

DOM Changes vs Split URL Testing​

Use DOM changes for: headlines, CTAs, button colors, element visibility, copy variations.

Use split URLs for: completely different page layouts, testing a Webflow build vs your coded page, checkout flow redesigns, pricing model changes.

The Infinite Loop Problem (and How to Solve It)​

The most common technical mistake with split URL testing is creating an infinite redirect loop.

Here's what happens:

1. Visitor lands on /pricing → assigned to Variant A → redirected to /pricing-v2
2. /pricing-v2 loads → SDK runs → experiment evaluates /pricing-v2 URL
3. If /pricing-v2 matches the experiment URL and Variant A still fires → redirected to /pricing-v2 again
4. Infinite loop

The fix: Session storage guard

const guardKey = `_redir_${experimentId}_${variantId}`
if (sessionStorage.getItem(guardKey)) {
  // Already redirected — we're on the destination page
  return
}
sessionStorage.setItem(guardKey, '1')
location.replace(redirectUrl) // Use replace(), not assign()

The guard key includes both experimentId and variantId so multiple simultaneous redirect experiments don't interfere with each other.

Using location.replace() instead of location.assign() prevents a new browser history entry, so the back button works normally.

GhostSnip implements this guard automatically.

Setting Up SEO Correctly​

When both URLs are publicly accessible, search engines will index both. To avoid duplicate content issues:

Option 1: Noindex on the variant URL (simplest)

<!-- On /pricing-v2 while testing -->
<meta name="robots" content="noindex, nofollow">

Remove this meta tag if/when you make the variant the permanent page.

Option 2: Canonical tag

<!-- On /pricing-v2 -->
<link rel="canonical" href="https://yoursite.com/pricing">

This tells search engines the original URL is the canonical version.

Option 3: Password-protect the variant URL

If your platform supports it, require authentication to access the variant URL during testing. This keeps it out of search indexes entirely.

Analytics Considerations​

With split URL testing, both pages appear as separate URLs in your analytics:

• /pricing: Control group traffic
• /pricing-v2: Variant group traffic

Metrics per page will look odd (each page only gets ~50% of what you'd expect). This is correct — don't try to fix it.

For goal tracking: GhostSnip uses sessionStorage to track which experiment variant the visitor was assigned to, so conversion events on /pricing-v2 are correctly attributed to your variant regardless of which URL they occur on.

Step-by-Step: Running a Split URL Test in GhostSnip​

1. Build your variant page and publish it at the target URL
2. Create an experiment in GhostSnip targeting your original URL (e.g., /pricing)
3. In the visual editor, open the Redirect tab
4. Enter the variant URL (e.g., /pricing-v2)
5. Set your goal — typically a page visit to your thank-you/confirmation page, or a custom purchase event
6. Add SEO protection to the variant URL (noindex or canonical)
7. Launch the experiment

Within hours, you'll have live traffic split between both pages.

When the Test Concludes​

Once you have a winner:

1. If control wins: Archive the experiment, redirect the variant URL back to the original (or 301 it), remove noindex tags from the variant
2. If variant wins: Make the variant your permanent page (update your CMS/code), 301-redirect the old URL to the new one, run the variant URL without the noindex

Don't just leave both pages live with no redirects — that's how you end up with duplicate content penalties.

Full redirect testing documentation →

It's the most common technical problem in client-side A/B testing, and most tools either ignore it or implement a solution that creates a different problem (CLS, layout shift).

This is the complete guide to fixing it correctly.

Why Flicker Happens​

Client-side A/B testing works like this:

1. Browser parses HTML and starts rendering
2. DOM becomes available
3. JavaScript SDK loads (async, so this happens after initial render)
4. SDK makes an API call to fetch experiment config
5. API response arrives
6. SDK applies variant changes to the DOM

Steps 1–3 take 0–100ms. Steps 4–6 take 100–500ms. During that window, the visitor sees the original (control) content. When the variant loads, the page visibly changes — a flash.

The Wrong Fix: body { display: none }​

Most A/B testing tools (including VWO's older implementation and some versions of Google Optimize) solved flicker with:

<style>body { display: none }</style>

This hides the body until the SDK removes the style. Problem solved, right? No — three problems:

Problem 1: Cumulative Layout Shift​

When display: none is removed, the browser recalculates layout from scratch. Depending on your page, this can cause elements to jump around — exactly the behavior that Google's CLS (Cumulative Layout Shift) Core Web Vitals metric penalizes.

Problem 2: Scroll position reset​

On some browsers, switching from display: none to display: block resets scroll position to the top of the page.

Problem 3: FOUC in some scenarios​

display: none can cause its own flash — from hidden state to fully rendered — that looks worse than the original flicker.

The Correct Fix: visibility: hidden​

<style id="_gs_af">html { visibility: hidden; pointer-events: none }</style>

visibility: hidden preserves the layout. Elements still occupy their space in the document flow — they're just invisible. When the style is removed, there's no layout recalculation and no CLS.

The pointer-events: none prevents any accidental clicks during the hidden period.

The Full Anti-Flicker Snippet​

<!-- Line 1: Hide the page immediately -->
<style id="_gs_af">html{visibility:hidden;pointer-events:none}</style>

<!-- Line 2: Safety for no-JavaScript browsers -->
<noscript><style>#_gs_af{visibility:visible!important}</style></noscript>

<!-- Line 3: Safety timeout — show page in 3s even if SDK fails -->
<script>setTimeout(function(){var e=document.getElementById('_gs_af');if(e)e.remove()},3000)</script>

Then your SDK script:

<script>
(function(w,d,k){
  w._sf = { siteId: k, ingestUrl: 'https://api.datsnip.com' };
  var s = d.createElement('script'); s.async = 1;
  s.src = 'https://api.datsnip.com/sdk/tracker.js';
  d.head.appendChild(s);
})(window, document, 'YOUR_SITE_ID');
</script>

The SDK itself removes the _gs_af style element after applying all variant changes — so the page becomes visible exactly when the correct variant is in place.

The Three Safety Mechanisms​

The snippet has three layers of protection:

The 3-second timeout is a deliberate balance: long enough that 99.9% of SDK loads complete before it fires, short enough that a failed SDK load doesn't permanently break the page.

Placement in <head>​

The snippet must be the first thing in <head> — before any other scripts, stylesheets, or tags that could trigger rendering:

<!DOCTYPE html>
<html>
<head>
  <!-- ✅ Anti-flicker FIRST -->
  <style id="_gs_af">html{visibility:hidden;pointer-events:none}</style>
  <noscript><style>#_gs_af{visibility:visible!important}</style></noscript>
  <script>setTimeout(function(){var e=document.getElementById('_gs_af');if(e)e.remove()},3000)</script>
  <script>
  (function(w,d,k){
    w._sf = { siteId: k, ingestUrl: 'https://api.datsnip.com' };
    var s = d.createElement('script'); s.async = 1;
    s.src = 'https://api.datsnip.com/sdk/tracker.js';
    d.head.appendChild(s);
  })(window, document, 'YOUR_SITE_ID');
  </script>

  <!-- Everything else after -->
  <meta charset="UTF-8">
  <title>...</title>
</head>

If you put other scripts first, the browser may start rendering before the anti-flicker style is applied.

Does Anti-Flicker Hurt Performance?​

The anti-flicker style is ~60 bytes inline — it adds nothing meaningful to page weight.

The actual performance cost is the time the page stays hidden: from the visibility:hidden style being applied to the SDK removing it. Typically 50–150ms on fast connections, up to 500ms on slow 3G.

This is a real trade-off. GhostSnip minimizes it by:

1. Serving the SDK from a CDN with global edge nodes
2. Caching experiment configs aggressively (30-second backend TTL)
3. The SDK removing the anti-flicker style as early as possible — before DOMContentLoaded, immediately after variant changes are applied

Does It Affect SEO?​

No. Googlebot and other crawlers:

1. Parse your HTML directly — they see the source, not the rendered state
2. Don't execute JavaScript in the same pass as initial indexing
3. Have separate rendering crawlers that execute JavaScript later

The visibility:hidden CSS is applied and removed by JavaScript. Crawlers reading your HTML won't see it at all. Your baseline content is indexed normally.

Anti-Flicker in GhostSnip​

GhostSnip's dashboard generates the complete anti-flicker snippet with your Site ID pre-filled. Go to Settings → Snippet and copy the "With Anti-Flicker" version.

Full anti-flicker documentation →

Optimizely built their original tool on frequentist statistics. Then switched to "Stats Accelerator" (Bayesian). VWO calls their approach "SmartStats" (also Bayesian). Statsig uses frequentist for feature flags, Bayesian for experiments. The research teams at Microsoft and Netflix have published papers on both.

Here's the practical guide to what actually matters for your team.

The Core Difference​

Frequentist (p-values, confidence intervals):

"Assuming the null hypothesis is true, the probability of seeing data at least this extreme is 3.2%."

Bayesian (probability of winning):

"There is an 87% probability that Variant A is better than Control."

The Bayesian statement answers the question you actually want to ask. The frequentist statement answers a hypothetical about a world you're trying to disprove.

Why P-values Are Misunderstood​

A study by Hoekstra et al. surveyed 442 psychology researchers who used frequentist statistics daily. They found that 97% of them — including experienced statisticians — misinterpreted the 95% confidence interval.

The common misinterpretation: "There's a 95% probability the true effect is in this range."

The actual meaning: "If we ran this experiment 100 times with fresh samples each time, 95 of those confidence intervals would contain the true effect."

This is a subtle but critical difference. The frequentist CI says nothing about the probability for any given experiment run — it's a property of the procedure over many runs.

For A/B testing, you're running one experiment, not 100. You want to know the probability for this experiment.

The Peeking Problem​

The most common frequentist A/B testing mistake: checking results every day and stopping when p < 0.05.

This is called "peeking" and it dramatically inflates your false positive rate:

With Bayesian testing, this problem is less severe. P(win) at any point in time is a valid probability statement about current data. Checking in early doesn't mathematically inflate your error rate in the same way.

However, Bayesian P(win) is still noisy with small samples. We still recommend running to your pre-calculated sample size before making decisions.

The Expected Loss Metric​

The most useful metric that Bayesian testing gives you that frequentist doesn't: Expected Loss.

Expected Loss is the average conversion rate you'd sacrifice if you made the wrong decision.

Example:

• Variant A has P(win) = 0.93
• Expected Loss = 0.0002 (you'd sacrifice 0.02% CVR if wrong)

vs:

• Variant B has P(win) = 0.94
• Expected Loss = 0.008 (you'd sacrifice 0.8% CVR if wrong)

Variant B has higher P(win) but dramatically higher Expected Loss. The smart decision is to ship Variant A.

GhostSnip requires P(win) ≥ 0.95 and Expected Loss < 0.001 before marking a result as significant. This combination eliminates variants that technically win but have tiny absolute effects.

How GhostSnip's Bayesian Engine Works​

GhostSnip uses a Beta-Binomial conjugate model:

1. Prior: Beta(1, 1) — uniform, no prior belief about conversion rates
2. Posterior update: After observing n conversions and m non-conversions: Beta(1 + n, 1 + m)
3. P(win): Monte Carlo simulation — draw 10,000 pairs of samples from each posterior, count how often the variant's sample exceeds the control's

The Beta-Binomial is the correct model for conversion rate data (binary outcomes: converted or didn't convert). It's the same model used by VWO's SmartStats and Google's internal experimentation platform.

When Frequentist Is Still Right​

Bayesian is better for most business teams, but frequentist has its place:

1. Regulatory requirements: Some industries require p-values for compliance documentation
2. Multi-armed bandit algorithms: UCB and Thompson sampling are frequentist algorithms that work well for continuous optimization (exploration vs exploitation)
3. When you need to exactly replicate another tool's results: If you're comparing to a published paper or another tool's report, use the same statistical model

Practical Recommendations​

For most product and growth teams running conversion experiments:

• ✅ Use Bayesian P(win) as your primary metric
• ✅ Use Expected Loss as your decision threshold (< 0.001)
• ✅ Pre-calculate sample size and run to completion
• ✅ Report "87% probability Variant A wins" to stakeholders — they'll understand it
• ❌ Don't peek and stop when p < 0.05
• ❌ Don't confuse "statistically significant" with "practically significant"

GhostSnip implements all of this by default. See how results are calculated →

Without calculating the required sample size before you start, you're likely to call a winner based on random noise and ship a change that has no real effect, or worse, a negative one.

This guide walks through the exact formula, a real worked example, and what to do when your traffic is too low.

The Formula​

A/B test sample size is calculated using the two-proportion z-test:

n = (z_α + z_β)² × (p₁(1-p₁) + p₂(1-p₂)) / (p₂ - p₁)²

Where:

• n = required visitors per variant
• z_α = 1.96 — critical value for 95% confidence (two-sided)
• z_β = 0.84 — critical value for 80% statistical power
• p₁ = your current (baseline) conversion rate
• p₂ = the conversion rate you want to be able to detect (baseline × MDE)

This is the same formula used by Optimizely's sample size calculator, Statsig's sample size planner, and Evan Miller's A/B testing calculator.

What is MDE?​

Minimum Detectable Effect (MDE) is the smallest relative improvement you'd care about. If your baseline CVR is 2%:

• MDE = 10% → you want to detect ≥ 2.2% CVR (absolute +0.2pp)
• MDE = 20% → you want to detect ≥ 2.4% CVR (absolute +0.4pp)
• MDE = 50% → you want to detect ≥ 3.0% CVR (absolute +1.0pp)

Smaller MDEs require proportionally more data. This is the most important input to get right.

Worked Example​

You're testing a new CTA button on your pricing page.

Inputs:

• Baseline CVR: 3% (0.03)
• MDE: 20% (want to detect ≥ 3.6% CVR)
• Confidence: 95%, Power: 80%

Calculation:

p₁ = 0.030
p₂ = 0.030 × 1.20 = 0.036
z_α + z_β = 1.96 + 0.84 = 2.80

numerator:   (2.80)² × (0.030 × 0.970 + 0.036 × 0.964)
           = 7.84 × (0.0291 + 0.03470)
           = 7.84 × 0.06380
           = 0.500

denominator: (0.036 - 0.030)² = (0.006)² = 0.000036

n = 0.500 / 0.000036 = 13,889 visitors per variant

Total visitors needed: 27,778
If you get 1,000 visitors/day: ~28 days

The Effect of MDE on Sample Size​

If you're a low-traffic site, you can only reliably detect larger effects. That's not a bug — it's the statistics. Set your MDE to match the minimum effect you'd actually act on, not the minimum you'd like to be able to detect.

Common Mistakes​

Stopping when P(win) looks good​

Even Bayesian P(win) can hit 95% by chance after 200 visitors with a 3% CVR (that's 6 conversions). Early spikes in P(win) are noise. Run to your pre-calculated sample size, then evaluate.

Using the same experiment for multiple goals​

If you calculated sample size for a "click on pricing" goal but you're also watching "signups", you've run multiple comparisons and inflated your false positive rate. Decide on your primary goal before you start.

Forgetting novelty effect​

The first week of any experiment captures users' reactions to something new. If possible, let the experiment run 2+ weeks to let novelty settle.

Calculating days wrong​

Sample size calculators give you visitors per variant. If you're splitting 50/50, you need 2 × n total visitors. If you're running 3 variants (Control + A + B), you need 3 × n total visitors — and your experiment takes 3× as long.

What to Do With Low Traffic​

If your calculated experiment duration is more than 60–90 days, you have options:

1. Increase MDE — only test changes you expect to move the needle by 25%+
2. Target a higher-traffic page — a homepage test with 5k visitors/day vs a checkout page with 200 visitors/day
3. Run an 80/20 split — 80% control, 20% variant — lets you observe effect size with less risk
4. Use GhostSnip's sample size endpoint — automatically estimates your daily visitors and tells you estimated days before you launch

Use GhostSnip's Built-in Calculator​

GhostSnip calculates the required sample size automatically when you create an experiment. Enter your baseline CVR and MDE, and it shows:

• Visitors per variant
• Total visitors needed
• Your estimated daily visitors (from the last 30 days of traffic)
• Estimated days to completion

The results page shows a progress bar tracking your current visitors against the required amount.

Learn more about understanding results →

This guide compares the real alternatives — including what we built at GhostSnip after experiencing the same gap firsthand.

Why Google Optimize Got Discontinued​

Google officially stated that Optimize would be deprecated to focus on integrations with Google Analytics 4. The real story: the product was aging (based on a 2012 architecture), had known flicker problems, and was being underinvested relative to the opportunity.

The gap it left: a reliable, lightweight A/B testing tool for teams that don't need enterprise pricing or enterprise complexity.

What to Look for in a Google Optimize Replacement​

Before comparing tools, here's what actually matters:

1. Anti-flicker that works​

The single most common complaint about Google Optimize was the flash of original content — visitors saw the original page for 200–400ms before the variant loaded. A good replacement ships a proper anti-flicker snippet.

Look for: visibility:hidden (not display:none) — this preserves layout and avoids Core Web Vitals penalties.

2. Bayesian statistics, not just p-values​

"95% confidence" is consistently misinterpreted by business stakeholders. The correct metric is P(win): the probability that the variant is actually better. Tools that report this directly are easier to act on.

3. Visual editor that's reliable on modern sites​

React, Vue, Next.js, Webflow — most tools' visual editors break on SPAs. Check whether the tool re-applies changes after client-side navigation.

4. Lightweight SDK​

Google Optimize's async snippet was notorious for layout shift. The replacement SDK should be:

• Under 30KB minified
• Async (non-blocking)
• No external dependencies

5. Revenue/e-commerce tracking​

If you're running any e-commerce or SaaS, you need to track revenue per variant — not just conversion rate. A 2% lift in CVR that reduces average order value by 10% is a net negative.

The Main Alternatives​

VWO (Visual Website Optimizer)​

Pros: Mature product, good visual editor, session recordings
Cons: Pricing starts at ~$200/month for basic; heavy SDK (~80KB); enterprise contracts for full features
Best for: Teams that need recordings + heatmaps + experiments in one tool

Optimizely Web Experimentation​

Pros: Industry standard, used by most Fortune 500 companies
Cons: Pricing is enterprise-only (~$40k+/year); not suitable for SMBs
Best for: Large teams with dedicated CRO programs

AB Tasty​

Pros: Good UX, widget library
Cons: No public pricing (quote-based); acquisition by Marigold changed direction
Best for: Mid-market teams

Statsig​

Pros: Excellent statistics engine; good for engineering-led teams
Cons: Primarily a feature flag / experimentation platform; visual editor is secondary
Best for: Product engineering teams with existing analytics infrastructure

GhostSnip​

Built after: Experiencing the same gap post-Optimize shutdown

What it does differently:

• Bayesian P(win) as the primary metric (not p-values)
• Anti-flicker with visibility:hidden (no CLS penalty)
• Visual editor that works on SPAs
• Revenue tracking built-in (window.ghostsnip.track('purchase', { revenue: 49 }))
• Lightweight: ~25KB minified

Best for: Teams that want professional-grade statistics without enterprise pricing

Get started with GhostSnip →

The Migration Checklist​

If you're moving from Google Optimize:

1. ✅ Remove the Google Optimize snippet from your <head>
2. ✅ Remove any Optimize data-layers and experiment IDs from your HTML
3. ✅ Export any historical experiment data you need (Optimize exports to GA4)
4. ✅ Identify which experiments were still running and need to be recreated
5. ✅ Install your new tool's snippet
6. ✅ Recreate your most important experiments
7. ✅ Set up revenue tracking if you're in e-commerce

Bottom Line​

The right Google Optimize alternative depends on your team size and budget:

• If you need enterprise features + recordings: VWO
• If you're an engineering team: Statsig
• If you want a lightweight, statistics-first tool: GhostSnip

The most important thing is to start running experiments again. The gap since Optimize shutdown has likely cost most teams 5–10% in conversion improvement they're leaving on the table.