Documenting A/B Test Variants with Before/After Screenshots

A quarter after an experiment ends, someone always asks "what did variant B actually look like?" The experimentation platform has the conversion numbers, but rarely a visual record — and by then the variant code has been cleaned up, the feature flag removed, and nobody can pull it back up to check.

Capturing both variants visually the moment an experiment launches solves that gap, and it doubles as a much clearer artifact for a growth review than a table of percentages next to a vague variant name.

Capturing Both Variants at Launch

Most experimentation platforms let you force a specific variant via a query parameter or cookie for QA purposes. Use that to capture each variant on its own:

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v1/screenshot \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "url": "https://example.com/pricing?variant=control",
    "format": "png",
    "width": 1440,
    "fullSize": true,
    "hideCookie": true
  }'

Repeat with ?variant=treatment (or whatever your platform's forced-variant parameter is called) for the second capture. Two clean, dated screenshots, one per variant, taken the moment the experiment goes live.

Generating a Visual Diff Between Variants

Beyond two side-by-side images, a v3/compare call between the two variant URLs produces a diff image and a mismatch percentage — useful context when a small copy change turned out to move a metric more than expected, or when a "minor" variant was actually a bigger visual change than the experiment brief described:

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v3/compare \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "before": {"url": "https://example.com/pricing?variant=control", "width": 1440, "fullSize": true, "hideCookie": true},
    "after": {"url": "https://example.com/pricing?variant=treatment", "width": 1440, "fullSize": true, "hideCookie": true},
    "threshold": 0.1
  }'

The diff image is a fast way to communicate "this is exactly what changed" in a results review, instead of reviewers having to read a description and imagine it.

Building It Into the Experiment Launch Checklist

The natural trigger point is whenever an experiment goes live: as part of that launch step (a feature-flag toggle, a platform API call, or a CI deploy), fire the two capture calls above and attach the resulting image URLs directly to the experiment's ticket or documentation page. Six months later, the visual record is sitting right next to the results, instead of living only in a designer's local files or a since-cleaned-up branch.

Why This Is Worth Automating, Not Just Doing Once in a While

Teams that run experimentation at any real volume — a handful of tests a month, easily more at a larger company — accumulate a lot of "what did that look like again" questions over time. A manual screenshot habit works for the first few experiments and then quietly stops happening once things get busy. Wiring the capture into the launch step itself means it happens every time, without depending on anyone remembering.

For growth teams already moving fast on experiments, Snapshot Site is a small, one-time integration that pays off every time someone asks what a variant used to look like.