The Implementation Queue

A winning variant served by Pertento works, but it is not part of your site. At some point the change belongs in your codebase, and the Implementation page is the list of changes waiting for that to happen. It is written for whoever has to write the code.

Three sections

Needs implementation — this is the queue. A winning variant exists, nothing is live, and nobody has marked it done. It includes experiments whose rollout has since been turned off, which are easy to lose track of otherwise.

Deployed — a variant is live on the site right now. Nothing to build; these are listed so the code and screenshots stay findable.

Marked as implemented — explicitly marked done. Kept separate so the queue above stays a queue.

The queue appears first. What needs doing is not buried under what does not.

How an experiment is classified

The order the checks run in matters:

1. 1Marked implemented wins over everything. It is an explicit human statement and is never overridden by what the platform infers.
2. 2Then deployment. A live variant is a fact rather than an inference.
3. 3Everything else is the queue.

Deployment state is read from both the variant and the experiment’s status, because a variant that was rolled out and later rolled back keeps its deployment timestamp. Status is what says whether it is live *now*.

Marking work as done

Mark an experiment implemented once the change is permanently in your codebase. This is a deliberate human action, not something Pertento can detect — from the outside a hard-coded change and a Pertento-served one look identical.

Marking it done also removes it from the queue and from your attention list, and notifies the account. Do not mark it early: an unmarked item is a visible reminder, and a wrongly marked one disappears silently.

Searching

The search box filters all three sections at once, by experiment name or ID. Matching ignores accents. ID is searchable because it is what URLs and support conversations refer to.

Why this exists

Two failure modes it is designed to catch:

• A winner that was never built. The test proved the change works, the experiment ended, and nothing happened. All of the cost and none of the benefit.
• A rollout left running indefinitely. It works, so nobody revisits it, and the site quietly depends on Pertento to serve a change that should be native.

Notes

• Deployment and implementation are different things. Deploying serves the winner to everyone; implementing puts it in your code.
• Both unbuilt winners and long-running rollouts appear on your attention list.
• Screenshots and variant changes stay available after an experiment ends, which is what makes the queue actionable later.