Platform · Experimentation
Three experiment types, one visual editor
Visual multi-variant tests, URL redirects and server-side tests, launched straight from a Chrome extension on your live site. Point at an element, change it, save the variant.
How a test runs
From a hypothesis to a shipped change
Who sees it, what to run next, and what engineering gets handed when you are done.
- No-code editing of text, styling, layout and position, plus custom CSS and JS for power users
- Targeting by URL, device and cookie, with sticky assignment so returning visitors see a consistent experience
- Anti-flicker rendering with four independent fail-safes, so visitors never see the original page flash into the test
- Every eligible visitor enters every eligible experiment, so running ten tests at once costs no sample size
- One-click winner deployment to 100% of traffic, and an implementation hand-off for hard-coding winners
- Hypothesis tracking with PXL prioritisation scoring to rank your backlog
Targeting
Show it to exactly who you meant to
Three dimensions, combined per experiment: the address, the device, and a cookie your own site already sets. Assignment is sticky, so a returning visitor keeps the variant they were given.
- URL rules on seven conditions, including regex and two negative ones
- Desktop, mobile or tablet, detected before the visitor is entered
- Cookie targeting for logged-in or segmented traffic, matched against a list of values
- Sticky assignment, held in browser storage rather than a cookie
- Force any variant by URL to review it, without a test account
Shipping the winner
One click to 100%, or a hand-off to engineering
Deploy the winning variant to all traffic from the result page. When it should live in the codebase instead, Pertento writes the hand-off with the exact change.
- One-click deployment with a record of who deployed it
- Implementation hand-off with the selector and the change
- Roll back to the original at any time
Prioritisation
A backlog ordered by PXL score, not by opinion
Log every hypothesis, score it on the PXL model, and let the ranking decide what runs next. The three scores resolve into one number, because a backlog needs to be orderable and three numbers is a discussion.
- Potential, exposure and level of effort, scored one to five each
- Resolved into a single importance from nought to ten, which the list sorts on
- Hypotheses linked to the experiment that tested them
- The highest-scoring draft surfaced when nothing else needs you
Implementation
Hand the winner to engineering, with the change
A winner can stay served by Pertento indefinitely, but most teams eventually want it in the codebase. The implementation dashboard tracks which winners are still running on the platform and which have been hard-coded.
- The selector and the exact change, ready to paste
- Status per winner: awaiting, in progress, hard-coded
- The experiment keeps serving until the code ships
Pipelines · beta
Decide the order, then stop scheduling by hand
A pipeline is an ordered run of stages, and a stage is a set of experiments that run together. Experiments that would collide go into different stages and each stage runs at full traffic in turn, which is the opposite of making them mutually exclusive and splitting the audience.
- Stages arm themselves in order, so nothing waits on somebody remembering
- Advance when every experiment concludes, on the first significant result, or on a person
- A stage arms all or nothing, so a partly-started stage is never left running
- Automation and auto-deploy are separate switches, both off until you turn them on
- With automation off the engine still logs what it would have done, using the same code
Visual editor
Point at it, change it, save the variant
The editor opens on your live site from a Chrome extension. Select an element, edit its content and styling in the properties panel, and the change is saved against the variant. No deploy, no ticket, no staging copy of the page.
A hierarchy tree and a selector fieldfor the times pointing is not precise enough, with a breadcrumb showing exactly which node is selected.
An interactivity toggleswitches between selecting elements and using the page, so you can open a menu or a modal and then edit what is inside it.
A device selectorreframes the canvas at the widths your traffic uses. A variant that only works at desktop width is not finished.
A changes listis the variant: an ordered record of everything it does, each entry removable on its own, and the same list the hand-off later reads.
Building the test
The parts that make a second experiment cheaper than the first
Most of what a programme spends its time on is not the first test. It is rebuilding a setup, checking a variant before it goes out, and keeping a record somebody can read next year.
Five HTML placements
Replace an element, insert inside it at either end, or place markup before or after it. Structural changes stay describable in one line, which is what makes them reviewable later.
Custom CSS and JavaScript
Per variant, for anything the properties panel cannot express. It ships inside the bundle built for your website and runs before the page is revealed, so a scripted change never reads as a jump.
Variant screenshots
Capture and crop what the variant looked like from inside the editor. A result read six months later is a list of selectors without one.
Duplicate an experiment
Copies the variants, every change on them, the screenshots and all three kinds of targeting. Rebuilding a setup by hand is where the wrong targeting rule gets shipped.
Test runs before launch
Rehearse the whole chain against the real runtime as a marked test, then delete it. Nothing a rehearsal collected ever has to be explained away in a report.
Force a variant by URL
Add a parameter to any address to pin yourself to a specific variant, or to see one variant with everything else held at its original. Reviewing by eye needs no test account.
While it runs
What the runtime is doing on your visitors' pages
Everything below is decided in the browser, from a file compiled for your website alone. There is no call to Pertento before the page renders and nothing waiting on a response to decide what a visitor sees.
Concurrency costs you nothing
Every eligible visitor enters every eligible experiment, so ten live tests each get the full audience rather than a tenth of it. The reason most programmes run one test at a time does not apply here.
Weights that always add up
Splits are stored as basis points out of ten thousand and validated to sum exactly, so a three-way test is genuinely three equal thirds rather than three roundings and a gap.
Automatic rebalancing
The split each variant actually received is measured and corrected on a schedule, so the cumulative allocation converges on the one you configured instead of drifting away from it.
Sticky assignment, no cookies
A visitor keeps the variant they were given, held in browser storage rather than a cookie. Consistency is a correctness requirement before it is a courtesy.
Anti-flicker with four fail-safes
The page is hidden while changes apply and revealed from four independent code paths. The failure being designed against is a customer site left blank for their own visitors.
No round trip before render
Each website configuration is compiled into its own static file, so the runtime already knows what to run when it loads. Nothing waits on an API call to decide what the visitor sees.
Questions
What teams ask before they switch
How long before we could have a test running?
One script tag in the head is the whole installation, and it is the only change to your site. From there a variant is built by pointing at elements on your live pages, so the first experiment is limited by how long it takes you to decide what to test rather than by anything that has to be procured, built or scheduled. Nothing goes live by accident while you are learning: a new experiment is a draft until you start it.
Will it slow the site down or hurt our Core Web Vitals?
Each website gets its own compiled file with its experiments baked into it, so the runtime already knows what to run when it loads and nothing waits on a call to us before the page renders. The page is briefly held back while changes are applied, which is what stops visitors seeing the original flash into the test, and it is revealed from four independent code paths so a failure shows the unmodified page rather than a blank one. Tracking loads last, after the page is visible, so measurement never delays rendering.
What can the editor actually change, and where does it stop?
Text, styling, layout and position are edited by pointing, and structural changes are covered by five HTML placements against an element you select. Past that it stops honestly rather than badly: anything the panel cannot express you write as custom CSS or JavaScript on the variant, which means a test is never blocked on the tool. The genuine limit is a change that happens before the page exists, ranking, pricing logic, a recommendation model. Those are server-side experiments, and they need your engineers.
How many experiments can we run at once?
As many as you have ideas for, and this is the answer worth checking against whatever you use today. Each experiment randomises independently, so an eligible visitor enters every experiment they qualify for and each one measures against the full eligible audience. Concurrency does not divide your sample here, which is why the platform checks whether two tests would interfere rather than rationing how many may run. Throughput is usually the difference between a programme that pays for itself and one that does not.
What happens to the work if we stop using Pertento?
Winners you have hard-coded are already in your own codebase and are unaffected, which is what the implementation queue exists to push you towards: it lists every winner still being served by us and keeps flagging it until your engineers have room. Winners still served by the platform stop when it does, the same way any variant stops. The experiments, the hypotheses and the written history stay in the account rather than in tooling of ours.
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.