On-Site A/B Testing and Experimentation Automation: A Winner Only Once the Math Agrees

Why "Variant B is winning" is not the same as "Variant B is the winner"
Early in a test, one variant almost always looks ahead by sheer chance — a handful of extra conversions on tiny traffic can produce a percentage gap that evaporates once real volume arrives. A testing tool that reports whichever variant currently has the higher raw conversion rate, with no sense of how much traffic actually backs that number up, ends up rewarding noise as often as it rewards a genuine difference. Centriu Flow treats "who is winning right now" and "who has actually won" as two different questions, and requires real statistical confidence before answering the second one.
How the underlying problem shows up before you fix it
- A test shows Variant B ahead by 8 points after the first day, and a team is tempted to end it early and pick a winner off a tiny sample.
- A percentage-only readout gives no sense of whether an 8-point gap is a real signal or ordinary noise at that traffic level.
- Setting up even a simple two-variant test on one page section requires a developer to hand-roll variant assignment and event tracking.
- A visitor sees Variant A on one visit and Variant B on the next, because there was never a consistent per-visitor assignment.
- Nobody can say with any precision how confident the team should be in a result before permanently turning off the losing variant.
Why a trustworthy test result takes more than a percentage comparison
A raw conversion-rate comparison between two variants is the easy, visible number — the harder, more defensible part is deciding how much that number should actually be trusted, given how little or how much traffic backs it. That requires real inferential statistics, not just arithmetic: treating each variant's conversion rate as a probability distribution — a Beta distribution informed by its own actual visitor and conversion counts — rather than a fixed number, then running a Monte Carlo simulation across thousands of random draws from those distributions to compute the actual probability that one variant truly outperforms the other.
How Centriu Flow runs the test and calls the result
A team configures a test against a specific content block or section — two versions of a call-to-action banner, or a signup form, for example — and Flow's public serving layer assigns each visitor to a variant using a hash of an identifier the snippet keeps in the local storage of that browser, so a returning visitor on the same browser lands on the same variant as before; if that storage is blocked or cleared, or the visitor switches device, the variant is drawn again. Every time a variant is shown, and every time the visitor completes the tracked conversion action, both events are recorded against that specific variant through a rate-limited serving endpoint.
Behind the results dashboard, each variant's conversion rate is modeled as a Beta posterior distribution built from its visitor count and the conversion clicks recorded for it — clicks are summed as events, so the same visitor can be counted more than once. A 10,000-iteration Monte Carlo simulation draws random samples from each variant's distribution and counts how often one variant's simulated conversion rate beats the other's — that frequency IS the probability that variant is the true winner, not an estimate rounded from a single point-in-time percentage. A winner is only ever declared once the Bayesian probability reaches 95% AND the test has accumulated at least 30 visitors; if either condition is not yet met, the test simply keeps running and reports "not yet conclusive" rather than forcing a premature call.
What is actually built today
- Hash-based variant assignment from an identifier stored in the browser — repeat visits from the same browser see the same variant while that storage is kept.
- Exposure recorded for every variant shown, and a conversion recorded when a visitor clicks the element marked with data-fluxo-convert.
- A 10,000-iteration Monte Carlo simulation over each variant's Beta posterior distribution, computing the real probability that a given variant is the actual winner.
- A hard rule against calling a winner early: 95% probability AND a minimum of 30 recorded visitors, both required.
- Rate limiting on the public variant-serving and event-tracking endpoints.
- Results available per test and rolled up into a dedicated reports view, with no export to a separate analytics tool required.
Two headlines, one honest answer (illustrative scenario, not a real client)
A team tests two versions of a pricing-page call-to-action: "Start your free trial" against "See a live demo." After the first 40 visitors, "See a live demo" is ahead by a wide-looking margin — but the simulation puts the actual probability it is the true winner at only 61%, well short of the 95% bar, and the dashboard reports the test as still running rather than declaring a winner. Three weeks and several hundred visitors later, the gap has narrowed in raw percentage terms, but the simulated probability has climbed to 96%, with the visitor count comfortably past 30 — only then does Flow mark "See a live demo" as the winner, with both the probability and the visitor count shown alongside the call, not just the label.
What changes operationally
A team stops eyeballing a percentage gap and guessing whether it is real. Because a winner is never declared on a lucky early streak, turning off the losing variant is based on an actual, quantified probability rather than a coin flip dressed up as data.
When this is not the right fit
A team that wants to test entire page redesigns rather than a specific block or section will find this built around block-level variants, not full-page A/B testing. A team that needs a result immediately, regardless of traffic volume, will find the 30-visitor minimum and 95% probability bar exist specifically to prevent an early, unreliable call — on a low-traffic page, reaching a conclusive result can take real time.
A live percentage readout vs. a probability with a bar to clear
A dashboard that only ever shows "Variant B: 24% vs. Variant A: 19%" invites a team to act the moment one number looks bigger, regardless of how little traffic produced it. Centriu Flow's A/B testing keeps that same simple conversion-rate view, but withholds an actual "winner" label until a real probability — computed from thousands of simulated draws against both variants' data — clears a fixed bar, so the label means something more than "ahead today."
Related systems
Main system: Centriu Flow.
What it does NOT do
- Does not test full page redesigns — testing is scoped to a specific content block or section, not the entire page at once.
- Does not declare a winner before both a 95% Bayesian probability and a minimum of 30 recorded visitors are reached — whichever is missing, the test stays open.
- Does not keep a visitor on the same variant across devices or after the browser storage is cleared — assignment hashes an identifier stored in that browser.
- Does not confirm the winner with a second statistical test — the call rests on the Bayesian probability and the visitor minimum alone.
- Does not build tests through a visual drag-and-drop canvas — Flow's journeys are configured as steps in sequence, not on a freeform canvas.
- Does not guarantee a conclusive result within any fixed time window — a low-traffic page can take considerably longer to reach the 30-visitor/95%-probability bar than a high-traffic one.
Security and governance
Variant assignment and event tracking run through a rate-limited public serving endpoint scoped to the organization that owns the test; test configuration and results are restricted to the organization's own authenticated workspace. Visitor identifiers used for deterministic assignment and any personal data collected through a tested block follow Brazil's LGPD (Law No. 13,709/2018). Full detail on access control lives at /governanca and /iso.
Pricing and contracting
Available by monthly subscription, with tiered plans. Investment and terms are defined with the team, based on the scope of the operation — talk to Centriu. No number is hard-coded on this page.
Frequently asked questions
What decides when a test has a winner?
Two conditions both have to be true: the simulated probability that one variant is the true winner reaches at least 95%, and the test has recorded at least 30 visitors.
Will a returning visitor ever see a different variant?
Not from the same browser while its local storage is kept — assignment hashes an identifier stored there. If that storage is blocked or cleared, or the visitor switches device, a new identifier is created and the variant is drawn again.
Is a whole page tested, or a specific section?
A specific content block or section, not an entire page redesign.
Is the winner decided by a single statistical method?
Yes — the call rests on the probability from the Bayesian Monte Carlo simulation plus the minimum-visitor rule; no second test confirms it.
Can a test be forced to declare a winner early, on low traffic?
No — below the 30-visitor/95%-probability bar, the test reports as still running, not conclusive.
What does Centriu Flow cost?
It is sold with tiered plans, starting at a published entry price — exact current values are on the central pricing page.
See how Centriu Flow runs and scores an A/B test
Reach our commercial team directly, or leave your details below — we'll follow up with guidance for your case.