Platform · Monitoring & automation

One screen for what is broken or waiting

The health monitor and attention queue span every account, so nothing sits unnoticed on a client site.

Keeping it running

One screen, and the rules behind it

Every account ranked by what needs a person, the automation that acts on it, and where you get told.

  • Scheduled starts and stops, plus stop-on-significance with guard rails: minimum runtimes and trust gates that refuse to act on broken data
  • Collision detection warns when concurrent experiments would interfere with each other
  • Alerts by email, Slack and in-app, across twelve event types, switchable per person
  • An activity log per experiment, and roles enforced once rather than route by route
Guard railsTrust gatesCollision detection
The health screen across an account: programme-health meters for tracking coverage, split accuracy, decisions and open collisions, a queue of eight items waiting on a person, and the automation rules currently armed.

The roster

Every client account on one screen

Agencies do not have one website, they have ninety. The roster view ranks accounts by what needs a person first, so the morning starts with the list rather than a search.

  • Accounts ordered by problems, then by decisions waiting
  • Per-account running counts and win rate
  • Scope the whole console to one client in two clicks
  • Broken, deciding, colliding, overdue, no data, each its own row
The client roster ordered by what needs attention first: two accounts with broken measurement, two with decisions waiting, one all clear.

Automation

Rules that stop, and guard rails that stop the rules

Schedule a start and a stop, or let an experiment end itself on significance. Guard rails keep automation honest: a minimum runtime, and a trust gate that refuses to act on data an alarm has flagged.

  • Scheduled starts and stops per experiment
  • Stop-on-significance with a minimum runtime
  • Trust gates that block automation on flagged data
  • Significance may only end a test early, because a stop date is always required
  • Minimum runtime never below seven days, fourteen by default
One experiment's automation: a scheduled window, stop-on-significance switched on behind a fourteen-day minimum runtime and a 40,000-visitor minimum sample, and the guard rails that make automation wait or pause instead of acting.

Alerts

Told once, in the place you already look

Every event can go to email, Slack or the console, with per-event preferences so a broken goal wakes someone and a reached-significance does not.

  • Email, Slack and in-app, per event
  • Per-user preferences, not one global switch
  • A full activity log for the account
  • Twelve event types, grouped by lifecycle, results, health and account
Alert preferences per event, grouped by health, results and lifecycle: a split mismatch and a dead experiment go to email and Slack, a significant result to both, a start to Slack only, and a deployment to the console.

What it notices

The signals, and why they are ranked the way they are

Each one is a thing that is still true and still unresolved, worked out from current state rather than from a feed of what happened. Clearing a badge does not clear the work.

Broken beats decide beats queue

Every signal is ranked into one of three severities, and a trust failure suppresses the result underneath it rather than sitting beside it. An experiment with a broken split may also be reporting a winner, and showing both would invite somebody to act on it.

A split that stopped matching

The observed traffic split is tested against the configured weights continuously. When it drifts further than chance explains, every result on that experiment is marked suspect until the cause is found.

An experiment that went quiet

Nothing recorded for a full day while the experiment is still running. Usually a targeting rule that stopped matching, or the snippet missing after a deploy, and both are invisible from inside the results screen.

Interference between two live tests

A redirect pulling traffic out of another experiment’s audience shows up as a split alarm in the other experiment, where nothing points back at the cause. Two variants editing the same element produce no alarm at all: the split stays perfect and the page is a combination nobody reviewed.

Past its end date, still splitting traffic

An experiment that was supposed to finish and did not is still costing you the traffic it takes. It is a decision waiting rather than a fault, and it is ranked that way.

A winner nobody built

Two separate signals, because they are different problems. One experiment won and was never rolled out. Another was rolled out months ago and is still being served by Pertento rather than living in your codebase.

Around the experiments

The account, not the test

Most of what goes wrong in a programme with several people in it is not statistical. It is two people editing the same thing, a change nobody can trace, or a number that never reached the analytics everyone else uses.

Roles that are enforced in one place

Members are read-only across the whole platform, admins and owners can write. The rule is applied once at the door rather than route by route, which is what stops a new screen from quietly being the exception.

An activity log per experiment

Every change that matters is recorded against the experiment with who made it and when: targeting added, weights changed, started, ended, deployed. Notifications say what happened; the log says who did it.

Saved console layouts

Arrange a screen the way you read it and it stays that way, per person and per screen. An agency lead and an analyst do not want the same columns in the same order, and neither should have to rebuild the view each morning.

GA4 and Matomo, or neither

Set the tracking method per website. Exposure events are pushed into the data layer alongside your existing analytics, so a variant is a dimension you can already segment on. Pertento native tracking is the third option when you would rather it stayed out of the way.

Alerts where you already look

Twelve event types across lifecycle, results, health and account, each switchable per channel and per person. Health and results are on by default because they earn an interruption; the lifecycle events are usually things you just did yourself.

One roster, many accounts

What an agency sees is its client roster; what a direct customer sees is their own account. The scope comes from the session rather than from an identifier in the address, so there is nothing in the URL to tamper with.

Questions

What happens when nobody is watching

What happens if a test breaks while nobody is looking?

You are told, rather than finding out from the numbers weeks later. The two failures that are invisible from inside a results screen are a split that stopped matching what you configured, and an experiment that quietly stopped recording anything, usually because a deploy took the snippet or a targeting rule stopped matching. Both raise an alarm to email and Slack by default, both mark every result on that experiment as untrustworthy, and both stop the platform acting on it. The work waiting for you is a ranked queue rather than a mess, and it is worked out from what is currently true, so nothing disappears because somebody cleared a notification.

How much is it allowed to do to our site without us?

Nothing, until you turn it on, and then less than you might expect. Automation and automatic rollout of a winner are separate switches and both start off, because auto-stopping the wrong experiment costs the traffic it already spent while auto-rolling-out a loser changes what every visitor sees. Before it acts it has to clear three trust gates and a minimum runtime. And with automation off it still evaluates everything and records what it would have done, using the same code that would have done it, so you can watch it be right for a month before you let it act.

Is it safe to give the whole team access?

Members are read-only across the entire platform: they can see every experiment and every result and change none of it. That rule is enforced once, centrally, rather than screen by screen, which matters because a permission model applied per screen is one where the next screen built is quietly the exception. Starting, stopping and rolling out stay with admins and owners, and every change that matters is recorded against the experiment with a name and a time on it.

We run several brands or client sites. Does this scale to that?

That is the shape the monitoring is built around. Everything unresolved across every account you can reach is rolled up in one view, grouped by client and by website, ordered so that anything untrustworthy comes before anything merely waiting on a decision. The scope comes from who you signed in as rather than from an identifier in the address, so there is no account id in the URL to check and none to tamper with. An agency sees its roster; a single-brand customer sees their own account in the same screen.

Will it fit the tools we already use?

Alerts go to email, to Slack, or to neither, set per event type and per person rather than once for the whole account, and Slack messages link back to the exact screen the event refers to. On the measurement side each website is set to GA4, Matomo or Pertento native tracking, which means the conversions we count can be the same events your analytics already counts rather than a second definition of a purchase that somebody has to reconcile.

Everything in the box

The full feature set

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.

Better experiments, better conversions

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