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
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
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
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
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
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.