ABOUT THIS DEMO
Why a conversion keeps
its original page
A visitor might sign up after you edit the page they saw. Variant Trace checks that the signup still links to that earlier version, even if its event arrives twice. A signup or purchase is called a conversion.
Open the test benchOne visitor, two page versions
The test bench uses a made-up mug and a few sample visitors. Here's the sequence you can try.
- 01
A visitor sees version 1
PAGE v1The app saves a page-view record called an exposure. It includes the visitor, variant and page version.
exposure E1 → page v1 - 02
You publish version 2
PAGE v2The next page view uses the edited version. Version 1 stays saved, along with the record of who saw it.
page v1 stays unchanged - 03
The conversion arrives twice
C1 acceptedC1 duplicateBoth deliveries carry the same event ID and content. The first counts against version 1. The retry stays in the log.
1 accepted conversion
What to try
Open the test bench and choose Run the scenario. It starts from the same sample data each time and runs the sequence above.
The delivery log shows one accepted conversion, one duplicate and one conversion with a missing exposure. Open a row to see its page version and event times.
You can also edit the page yourself, resend a conversion or deliver an exposure late. Reset brings you back to two original page versions and an empty log.
A and B are the two page variants. Starting a new revision gives the experiment a fresh set of visitor assignments. Editing the text alone doesn't start a new revision.
When a record is missing
If a conversion arrives without its exposure, the app marks it as unmatched. It doesn't guess which page the visitor saw.
If that exposure arrives later and the details match, the conversion can count. An unknown page version or a changed payload using an existing event ID gets its own explanation in the log.
The counts help inspect these cases. They don't tell you which A/B variant performs better.
A small engineering example
I built Variant Trace while learning about Funneled's split-testing product. I wanted to make one part of experimentation easy to inspect: the link between a page view and a later conversion.
This is an independent demo with fictional data. It doesn't connect to Funneled or describe how its systems work.
The app uses SvelteKit, TypeScript and a local SQLite database through Cloudflare D1. Tests cover the version links, retries and concurrent writes. The database stores each delivery, so you can reload the page and inspect the same records.
Start with the scenario, then change one thing and check the log.
Try the demo