Solutions · SaaS
Run your own programme, on your own site
Your team owns the roadmap and runs the tests. Pertento is the platform underneath: one script tag, a visual editor and results nobody has to take on faith.
Running it yourself
From the first afternoon onwards
Installing it, who you invite, and how a change ships when there is no engineering time to spend on it.
Getting started
Live on the first afternoon
One script tag in the head and the console starts reporting. Nothing to procure, no data pipeline to build, no engineering sprint to schedule.
- A 0.9 KB tracker, no cookies, no personal data
- The visual editor runs from a Chrome extension on your live site
- A new experiment is a draft until you start it and publish the website
The team
Invite everyone, pay for sessions
Pricing is per session on the website, not per seat, so the designer who writes the variant and the analyst who reads the result do not cost extra.
- Unlimited users on every plan
- Roles for who can start, stop and deploy
- An activity log of who changed what
Without engineering
Ship the change, hand over the winner
Most variants never need a developer. The ones worth keeping produce an implementation ticket with the selector and the exact change, so the hand-off is a paste rather than a meeting.
- No-code editing of text, styling, layout and position
- Implementation hand-off for winners worth hard-coding
- The experiment keeps serving until the code ships
In practice
What running it yourself looks like on a Tuesday
The hard part of an in-house programme is rarely the first test. It is keeping several of them moving when experimentation is nobody's whole job.
Your throughput is not capped by traffic
Every eligible visitor enters every eligible experiment, so a small team can have eight tests live on a mid-sized site without any of them taking longer to conclude. The usual advice to run one at a time is a limitation of other tools.
The backlog decides, not the loudest voice
Score each idea on potential, exposure and effort, and the list orders itself. When nothing is broken and nothing is waiting on a decision, the console tells you which draft to pick up.
Read-only is a real role
Members can see everything and change nothing, which is what makes it safe to give the whole team an account. Starting, stopping and deploying stay with admins and owners, and every change is recorded against the experiment with a name on it.
The second test is cheaper than the first
Duplicating an experiment copies its variants, its changes, its screenshots and all three kinds of targeting. Most of the cost of a programme is rebuilding setups, and most of the mistakes are in the part people rebuild by hand.
Nobody has to remember to stop it
Schedule the start and the end when you build it. Stopping on significance is available on top, with a minimum runtime and a required end date so an early stop can only ever be early rather than the only thing that ends a test.
It tells you when a test breaks
A split that stopped matching its configuration, or a day with no traffic at all, reaches you by email and Slack rather than waiting to be noticed. Both usually mean a deploy took the snippet or a targeting rule stopped matching.
Questions
Before you bring it in-house
How small can the team be?
One person who can edit the site and read a chart. The work that normally needs a specialist is the part that is built in: the editor removes the developer from most variants, the backlog ordering removes the argument about what to run next, and the queue of what needs a decision removes the daily check of whether anything broke. What it cannot do is decide what is worth testing, and no platform can. If nobody owns that question, buying software will not create an owner.
What will our engineers have to do?
Three things, and only the first is unavoidable. Put one script tag in the head, once, which is the only change to your site. Build server-side experiments, where your own backend decides what to serve, which is the one experiment type that is genuinely code. And hard-code winners when you want a change to live in your codebase rather than being served by us, which is handed over with the exact change attached and is a paste rather than a meeting. Everything in between is done by pointing at elements on your live site.
How does the cost behave as we grow?
It follows tested traffic rather than headcount, so the people who make a programme work do not each carry a price. The designer who writes the variant, the analyst who reads the result and the stakeholder who wants to watch can all have an account, and members are read-only across the platform, so handing those accounts out is safe. What grows with you is the traffic you put through tests, which is the part that correlates with what you get back.
We already have GA4. Does this replace it?
No, and it is better if you keep it. Set your website to GA4 and the runtime reads the events already flowing through your data layer, so the conversions we measure are the same ones your analytics counts. That removes the usual argument between two tools with two definitions of a purchase. Variant exposure is pushed back out as well, so a test becomes a dimension you can segment on inside the reporting your team already trusts.
What happens to the work if we stop?
Anything already hard-coded is in your own codebase and is unaffected, which is exactly why the implementation queue keeps nagging about winners we are still serving. Winners still served by the platform stop when it does, the same way any variant stops. The experiments, the hypotheses behind them and the record of every decision live in the account rather than in a consultant spreadsheet, so what you walk away with is a documented programme rather than a folder of screenshots.