A/B Testing Features Built for Speed and Accuracy
Split testing, decision-ready reporting, revenue tracking, Google Analytics goals, and zero-flicker rendering. From hypothesis to confident decisions, in one platform.
A/B Split Testing
Test any element on your page
Create unlimited variants with different headlines, images, CTAs, or entire layouts. Split traffic with precision. Our deterministic assignment algorithm ensures consistent experiences.
Statistical Engine
Know when results are real
Frequentist and Bayesian analysis with configurable thresholds, automatic multivariate adjustment, and real-time calculations.
Revenue Tracking
Measure the bottom line
Track purchases and revenue per variant. Welch's t-test for revenue comparisons. Know exactly how much each variant is worth.
Google Analytics Integration
Use your GA4 events as A/B test goals
Connect your Google Analytics 4 property and use any existing event as a conversion goal — no extra tracking code, no duplicate instrumentation. Most A/B testing tools force you to re-implement conversion tracking in their SDK. Otter lets you keep the events you already trust and measure experiments against them directly.
- Connect GA4 with one click via OAuth
- Browse and select events from your property — no manual configuration
- Combine GA4 goals with SDK-tracked goals in the same experiment
Zero-Flicker
No flash. No jank.
Cache-first rendering applies changes before the page is visible. 3-second failsafe. Anti-flicker snippet ensures zero visible layout shift.
Platform Support
Works with the stacks teams already run
Otter ships as one lightweight runtime, but setup guides are tailored for the platforms and deployment workflows teams actually use.
Tiny SDK
< 9KB. Zero dependencies.
Async loading. No performance impact. Built from scratch — no bloated framework underneath.
Developer First
Built for engineers
REST API for server-side integrations. SDK methods for custom event tracking, user identification, and consent management. Full control over the testing lifecycle.
Features in depth
What each capability actually means
Most A/B testing tools share the same feature checklist. The differences are in how each feature is implemented, what tradeoffs it makes, and whether it actually helps you ship the right decision. Here is what each Otter feature does and why we built it that way.
Zero-flicker variant rendering
The classic A/B testing failure mode is "flash of original content" — the visitor briefly sees the control variant before the variant overrides it. It looks broken, and on mobile connections it can show the original page for hundreds of milliseconds.
Otter hides the body with a CSS rule injected synchronously in the <head>, then removes that rule once the SDK has resolved which variant to show. The window is typically under 300ms and capped at 3 seconds by a hard failsafe — if the SDK fails to load, the page shows the control variant rather than staying invisible. Competitor tools that ship anti-flicker as a "manual snippet you can optionally add" leave this off by default; we made it the default.
Frequentist and Bayesian analysis, both done correctly
Most platforms ship one statistical model — usually frequentist with a hardcoded 95% confidence threshold — and call it a day. That is the wrong default for small-traffic tests where you need a directional decision faster than textbook significance allows, and it is the wrong default for multivariate tests where you need adjusted thresholds to avoid false positives.
Otter lets you pick the model per test. The frequentist mode reports p-values, confidence intervals, and a configurable threshold (default 95%, settable to 90% for low-risk tests). For multivariate tests, the threshold tightens automatically using a Bonferroni correction so you do not "win" by running enough variants. The Bayesian mode reports the posterior probability that each variant beats control plus the expected lift distribution — useful when the question is "given the data, what is the chance this variant is better?" instead of "is the p-value below 0.05?"
Revenue tracking that surfaces the right conflict
A conversion-rate winner can lose on revenue. If a variant moves customers toward a cheaper SKU or a smaller cart, the conversion bar can move up while revenue per visitor moves down — and shipping the "winner" actively costs you money.
Otter attaches monetary values to conversion events and reports conversion rate, average order value, and revenue per visitor side by side. When they disagree, the results page surfaces the conflict instead of hiding it — you decide what matters more rather than relying on the tool to pick for you.
Targeting that runs on the visitor side
URL matching supports exact, prefix, wildcard, and regex. Visitor targeting supports country, device class, traffic source (UTM), referrer, and custom attributes passed through the SDK. All targeting is evaluated client-side at variant assignment time, so a "logged-in users only" test never assigns logged-out visitors at all — the noise that would otherwise creep into your data never gets a chance to.
Exclusion lists support office IPs, internal QA traffic, and known bot user-agent patterns out of the box. The CrawlerDetect library handles modern Chrome client-hint headers correctly, which means your data is not contaminated by Sec-CH-UA false positives that older bot filters can fall for.
GA4 integration without re-instrumentation
Most teams already have GA4 conversion events configured for purchase, signup, lead, and key page views. Otter can read those events directly through the GA4 API and use them as test goals — no JavaScript changes, no re-instrumentation, no duplicate event tracking.
The trade-off is GA4's sampling and processing delay, which means decision data lags real-time by up to 24 hours. For tests where freshness matters, use a native Otter goal; for tests where attribution accuracy matters more, use the GA4 source.
A 9KB SDK that does not slow your site
The SDK is hand-written plain JavaScript with no virtual DOM, no framework runtime, and no dependencies. It compiles to under 9KB gzipped, loads with the async attribute, and lives in the browser cache after first load. Page speed audits should not even register it after the initial visit.
For comparison, the typical enterprise A/B testing SDK is 80–200KB and ships a virtual DOM layer for "easier integration" — which usually means more code running on every page even when no test is active. Otter's SDK runs zero code on pages where no test is targeted.
SPA support without manual wiring
Single-page apps that use the History API — which is essentially every React, Vue, Svelte, and Next.js app — work out of the box. The SDK watches pushState and popState events and re-evaluates active tests on every URL change. You do not need to call anything manually on route change.
For apps that do client-side routing without the History API (rare, but it happens), there is a manual optimo('reevaluate') hook that re-runs targeting. The same hook is useful in unit tests and Storybook previews.