Platform · Statistics you can defend
Frequentist and Bayesian, side by side
Lift, confidence intervals, probability this variant is best and expected loss: one view, updating in real time.
Reading a result
What the numbers say, and what they do not
Looking early without cheating, the alarm that fires before you act, and revenue per variant in the account currency.
- Sequential testing that can legitimately call a winner early, with multiple-comparison correction
- Sample-ratio-mismatch alarms that flag untrustworthy results before you act on them
- Revenue and average-order-value per variant, multi-currency aware
- A detectable-effect floor, so an unanswerable test says so instead of running forever
- Plain-English explainers on every statistic: no PhD required
Sequential testing
Look early without cheating
A fixed-horizon test is only valid if you look once, at the end. Sequential testing lets you check every day and stop the moment the evidence crosses the boundary.
- Valid inference at every look, not just the last one
- Multiple-comparison correction when several variants run at once
- A recommendation in words, not just a number
- Holm-Bonferroni, Benjamini-Hochberg, Šidák, or none, and it says which
Trust
The alarm that fires before you act
A sample ratio mismatch means the split did not happen the way you configured it, and the result cannot be read. Pertento checks continuously and blocks automation when it trips.
- Continuous sample-ratio-mismatch checks per variant
- Automation refuses to act on flagged data
- The reason stated in plain words
- Three gates: a sample-ratio mismatch, a day without traffic, or an interaction with another running test
Money
Revenue per variant, in the account currency
Conversion rate is a proxy. Pertento reports revenue and average order value per variant so a win that sells cheaper products does not look like a win.
- Revenue and average order value per variant, in one chosen currency
- Conversions counted across every currency, because a conversion is a conversion
- Revenue read as a second goal for the implementation queue, so a revenue-only win still ships
- Significance and intervals on revenue as well as on conversions
The figures
What the results table is actually telling you
Six numbers do most of the work on this screen, and two of them are the ones people misread. The console explains each one in place; this is what they are for.
Two intervals, not one
A Wilson interval for each variant’s own rate, which stays inside nought and a hundred per cent even at small samples, and a lift interval for the difference against the control. The second is the one that settles an argument: if it clears zero the variant is genuinely ahead.
Probability a variant is best
The Bayesian half reports the chance each variant is the best of those tested. Unlike a p-value it answers the question you actually asked, which is why it is usually the number people read first.
Expected loss
What you would give up by shipping this variant if it turns out not to be the best. A small expected loss means the decision is cheap even when it is wrong, and that is often what settles it rather than significance.
The resolvable-effect floor
The smallest change this much traffic can reliably detect. A difference below it will not become significant by waiting at the current traffic level, however long you leave it running. This is the failure mode that looks like "no result" and is really "not enough traffic to ever tell".
Days remaining, honestly
Projected from the traffic rate over the window the test was actually live, and sized against the difference being measured rather than a fixed target. When the target is further away than a year, it says so instead of printing a four-digit day count.
Plain-English explainers
Every figure carries its own definition, written to say what it is telling you rather than to define the term. Where a number is easy to misread, the explanation says so outright.
Underneath
What the numbers are measured over
A result is only as good as what it was computed from: which event counts as the goal, which currency the money is in, and whether the same maths produced the alert and the screen.
Three named corrections
Holm-Bonferroni, Benjamini-Hochberg and Šidák, or none. A correction changes only the significant verdict, never the p-value, interval or z-score, and with a single variant all four reduce to the same threshold. The console says so rather than leaving you to test each one.
Primary and secondary goals
A website marks which of its events may be used as an objective; each experiment picks its primary from that pool and lists the rest as supporting metrics. An event demoted later keeps reporting on experiments that already chose it, so a finished result never changes retroactively.
Per-variant time series
Daily sessions, conversions and revenue per variant, as raw counts rather than pre-computed rates. Every other figure on the page is one cumulative number, and none of them can show whether a result is settling or still wandering.
Combination reporting
When several experiments run at once, the combination report asks whether two changes interact and whether order values differ between combinations. It is computed from conversions alone, which is exactly enough for that question and not enough for "which combination converts best".
Multi-currency, kept honest
Conversions are counted across every currency, because a conversion is a conversion whatever it was paid in. Revenue is not: adding SEK to EUR gives a meaningless total, so revenue needs one currency chosen and the console makes you choose it.
One implementation of the maths
The alarm that emails you and the screen you land on run the same sample-ratio check, and the stopping engine reads its verdict through the same code the dashboard renders. An alert that contradicts the screen it links to is worse than no alert.
Questions
Before you trust the numbers
Can we take these numbers to a finance director?
That is what the second half of this page is for. A result arrives with the size of the difference, the interval around it, and how likely it is to be chance, computed two independent ways and shown side by side. Revenue is measured per variant rather than inferred from conversion rate, so a variant that converts more often and sells cheaper does not read as a win. And the platform states its own uncertainty rather than hiding it, which is the part that survives scrutiny: a result that is not yet conclusive says so, in words, instead of being presented as one that is.
Do we need a data scientist to read it?
No, and the design assumes you do not have one. Every figure carries its own explanation in place, written to say what that number is telling you rather than to define the term, and several of them exist specifically to head off a misreading: the difference column states outright that it says nothing on its own about whether the gap is real. Alongside the figures there is a recommendation in plain words. What it will not do is simplify by hiding, so somebody who does want the p-value and the interval will find both.
How do we know a winner is real and not luck?
Three defences, and they are worth comparing against whatever you use now. Testing several variants at once raises the chance one looks like a winner by luck, so the bar is tightened to compensate, and the console states the threshold it is applying rather than leaving you to work it out. Looking at a result every day inflates the false-positive rate, so the test that is valid to read continuously is separate from the one that is not, and the platform will not stop an experiment early unless both agree. And before any of that, it checks that traffic actually split the way you configured it, because if it did not then nothing computed from it holds.
Our traffic is not enormous. Will this work for us?
Sometimes yes and sometimes genuinely no, and this is where the platform is most useful before you have spent three months finding out. Every experiment reports the smallest difference the traffic you have can reliably detect. If the effect you are chasing sits below that floor, no amount of patience will resolve it, and the console says so rather than leaving a test at "not significant" indefinitely. Knowing which of your pages can answer a question and which cannot is worth more on a modest site than on a large one.
Do we have to pick frequentist or Bayesian up front?
No. Both are computed for every experiment and shown together, so this is a reading preference rather than a configuration decision you can get wrong. The frequentist half reports how unlikely the result would be if the change did nothing. The Bayesian half reports the probability each variant is best, and what it would cost you to choose wrongly. Teams tend to find the second easier to act on and the first easier to defend, which is exactly why neither was dropped.
Everything in the box
The full feature set
Experimentation
- Visual multi-variant tests
- URL redirect tests
- Server-side tests
- No-code visual editor
- Chrome extension launcher
- Custom CSS and JS
- Replace, insert, append, before and after
- URL targeting on seven conditions
- Device targeting
- Cookie targeting
- Traffic weights per variant
- Automatic weight rebalancing
- Concurrent tests without splitting traffic
- Variant screenshots
- Duplicate an experiment
- Test runs before launch
- Sticky variant assignment
- Anti-flicker rendering
- One-click winner deployment
- Implementation hand-off
- Hypothesis tracking
- PXL prioritisation scoring
- Pipelines of staged experiments
Statistics
- Frequentist results
- Bayesian results
- Lift and confidence intervals
- Probability variant is best
- Expected loss
- Sequential testing
- Multiple-comparison correction
- Holm-Bonferroni, Benjamini-Hochberg and Šidák
- Sample-ratio-mismatch alarms
- Primary and secondary goals
- Revenue per variant
- Average order value per variant
- Multi-currency
- Power analysis
- Minimum detectable effect
- Days-remaining projection
- Combination reporting
- Per-variant time series
- Plain-English explainers
Monitoring
- Health monitor
- Attention queue across accounts
- Scheduled starts and stops
- Stop on significance
- Minimum runtime guard rails
- Trust gates on broken data
- Collision detection
- Interaction detection
- Overdue and no-data alarms
- Email alerts
- Slack alerts
- In-app alerts
- Per-event preferences
- Activity log
- Client roster view
- Saved console layouts
- GA4 and Matomo tracking
- Roles and permissions
Voice of customer
- On-site NPS
- CSAT
- CES
- Guided survey builder
- Score, open text and single choice
- Page-view and delay triggers
- Exit-intent triggers
- Scroll triggers
- Event triggers
- Four widget positions
- Frequency capping
- AI sentiment analysis
- Surveys inside experiments
- Answers tied to variant
- Free-text themes
- Response export
- Loaded only where a survey runs
Pertento is a conversion-rate-optimisation platform for websites and online stores, built for both in-house teams and CRO agencies running experimentation programmes across a client roster.
Integrations
Works with the stack you already run
One snippet drops into any site, or go fully server-side. Nothing to re-architect.
One-line snippet
Paste a single 0.9 KB tag in your head and you are live. No build step, no dependencies.
Google Tag Manager
Deploy and manage experiments straight through GTM. No developer time required.
Server-side API
Run tests beyond the browser: pricing, search and routing, flicker-free.
- Shopify
- BigCommerce
- Shopware
- Centra
- Geins
- Saleor
- WordPress
- Optimizely CMS
- Storyblok
- Next.js
- Vue
- Astro
- Matomo
- Amplitude
- RudderStack
- Slack
- WooCommerce
- Salesforce
- Wix
- Litium
- commercetools
- Medusa
- Drupal
- Contentful
- Webflow
- Nuxt
- Angular
- Remix
- Piwik PRO
- Mixpanel
- Tag Manager
- Webhooks
- Adobe Commerce
- PrestaShop
- Squarespace
- Norce
- Shopify Hydrogen
- Vendure
- Umbraco
- Sanity
- Framer
- React
- SvelteKit
- GA4
- Adobe Analytics
- Segment
- Klaviyo
Not on the list? If it renders HTML, Pertento can test it:read how each one connects.