Platform · Experimentation

Three experiment types, one editor with AI built in

Visual multi-variant tests, URL redirects and server-side tests, launched straight from a Chrome extension on your live site. Describe a change to the AI editor, or point at an element and change it yourself, then 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.

  • An AI editor that builds changes from plain words, no-code editing and ready-made components, plus custom CSS and JS
  • 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
Multi-variantURL redirectServer-side
The experiment library: five experiments across the three types, with their traffic split and targeting window, one running, one waiting on a decision and one already deployed.

AI editor

Describe the change, and watch it get built

Tell the editor what you want in plain words, or point at an element and ask. The AI reads the page, proposes the changes and previews them on your live site. Nothing is saved until you apply it.

The AI editor beside a cluttered landing page: a prompt asks for one clear headline, one main button and plans that are easy to compare, the AI proposes five changes and previews them as the page is redrawn clean, and the changes are applied and saved.
  • A word or a whole sectionFix one headline, or rework a whole hero, menu or pricing table from a single prompt. Each change is listed on its own, so you keep the ones you want.
  • JavaScript only when it is neededMost tests are copy, styling and markup, and that is what it writes. When a test needs behaviour, such as something that reacts to a click or a scroll, it writes the code too, and the code waits for its own approval.
  • It reads the page for youThe AI works from an outline of the page you are on: its structure and its copy. You describe the outcome, and it finds the elements to change. No selectors, no developer.
  • A preview before anything is savedProposed changes appear on your live page, each with its own checkbox. Apply them and they become ordinary changes in the variant, with undo, until you save.
  • Strong experiments without codeAnyone who can describe a better page can build the variant for it. The AI answers in the language you write in, and keeps the page's copy in the page's own language.
  • You see the cost firstEach request uses AI credits, and the panel shows an estimate before you send it. Form values and personal details on the page are masked before anything is sent.
Everything about the AI editor

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
An experiment's targeting rules: product pages on mobile, excluding the outlet section, for visitors whose loyalty cookie marks them as members, with sticky assignment, admitting 61% of traffic.

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
The deployment screen: variant B rolled out to all traffic with a named deployer, a timestamp and rollback available, beside the hand-off listing the selector, the copy and the colour to hard-code.

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
The hypothesis backlog ranked by PXL score, from a sticky add-to-cart at 9.4 down to a hero video at 3.2.

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
The implementation dashboard: five winners with their status, and the hand-off for one of them giving the selector, the change, whether Pertento is still serving it, and the ticket.

Pipelines

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
A four-stage pipeline board: the checkout stage complete, two product-page experiments running together in the current stage, and two later stages pending, with automation on and auto-deploy off.

Visual editor

Point at it, change it, or drop in a whole section

The editor opens from Chrome's side panel, on your live site. Style anything in the inspector, edit text where it sits, or drag in a ready-made component that takes on your site's own fonts and colours. Every change is saved against the variant: no deploy, no ticket, no staging copy of the page.

ComponentsDynamic contentData feedsHover and focus statesText in placeCustom CSS/JS
The visual editor on a product page: the Trust row block is dragged from the Add tab and dropped under the add-to-cart button, its rating line is bound to the page's own product rating and review count, and the variant is saved.
Everything the editor doesHow the extension opens it

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.

A component library that matches your site

Heroes, FAQs, trust rows, sticky bars, pop-ups, columns, video and sliders, dropped in by click or drag. Each one takes your site's fonts and colours from where it lands, so a test can add a section rather than only recolour a button.

Build once, every page fills in its own data

Put the visitor's campaign, a countdown, the page's own heading or, on a shop, the product's name and price into a change. One banner greets every campaign in its own words, and missing data hides it rather than showing a placeholder.

Data feeds from your own systems

Connect a JSON or Google Merchant feed the site already publishes, such as reviews, stock or campaign copy, and use its fields in any variant. Pertento's servers fetch it on a schedule, so visitors never wait on your server, and only the fields you tick are ever shown.

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 inspector 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 loader in your page is under 1 KB, and the heavier features, such as page data and data feeds, only load on websites whose tests use them. 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, hover and focus states included, and whole sections are added from a library of components that take on your site's own fonts and colours. A change can carry the page's own data, such as each product's price, or values from a feed you already publish, and a selector can apply it to every matching element. You can also describe the change in plain words and let the AI editor propose it, previewed on the page before anything is saved. Past that it stops honestly rather than badly: anything the inspector 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

Statistics

Monitoring

Voice of customer

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 one tag in your head and you are live: a 0.9 KB loader, 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.

Better experiments, better conversions

Test on all visitors with the world’s lightest script and make confident decisions powered by real-time reporting.

Start trialRequest a demo