Overview

Splitcraft shows different visitors different versions of a page on your website and measures which version gets more of what you care about, such as clicks on a hero button or demo requests. Your site runs one small script; the editor, the results and the team live here.

How it works, in short

1. The snippet at the top of every page picks a version for each visitor who's in a test and keeps them on it for every visit.
2. For a changed version, the edits are applied as the page loads, before it's drawn, so visitors don't see the original flash.
3. Splitcraft records when a visitor sees the test and whether they then reach a goal.
4. The dashboard turns those counts into Confidence to call and a plain-language verdict.

Your pages are cached the same way for everyone; the choice of version happens in the visitor's browser, and the snippet is served from a CDN, so tests don't slow pages down.

Quick start

1. Add a site. Enter its domain, then paste the snippet as the first thing in <head> on every page. The site shows Installed after its first visit.
2. New test. On the site's dashboard, click New test. Enter the page (a full URL on the site or a path like /pricing/) and a name.
3. Make a change. In the editor, with Version B selected, click an element on the page and change it in the panel.
4. Add a goal. On the Goals tab, add what counts as success, e.g. Click on an element and pick the hero button.
5. Check Setup. Look over the split and sizing. The side-by-side view shows the original and your version together.
6. Preview. Open the preview links on the dashboard to check each version on desktop, tablet and phone.
7. Start. Click Start test… under the panel, read the review, and confirm.
8. Wait for 100%. Don't end the test early because it's “leaning” one way.
9. End it. When Confidence to call reaches 100%, click End test and choose which version everyone sees from then on.

Sites and the snippet

A site is a website you test on. Add as many as you like from Add a site in the sidebar.

• Domains: the hostnames the snippet runs on, e.g. www.example.com. *.example.com covers every subdomain. Tests, goals and split pages must be on one of them; the snippet does nothing anywhere else.
• The snippet: one <script> tag. Put it as the very first thing inside <head>, before stylesheets and tag managers, and don't add async or defer: it has to run before the page draws to prevent flicker. It's small (about 6 KB compressed) and cached.
• Tag managers load too late to avoid flicker. Use them only for split URL tests, or accept a brief flash of the original.
• Installed: the snippet reports in at most once a day per visitor. A site shows Installed once it has reported in within the last week.
• Changes go live within a minute of starting, pausing or ending a test, as the snippet's cached copy refreshes.

Workspaces and team

Every account starts with its own workspace. Sites, tests and API tokens belong to a workspace; everyone in it can see and change them.

• Invite teammates from Workspace. Each invitation has a link you can copy and send yourself; it works for 7 days.
• Roles: owners and admins manage members and the workspace name; members work on sites and tests.
• Several workspaces, e.g. one per client: switch between them at the top of the sidebar, or create a new one there.
• Removing someone also stops their API tokens working in that workspace.

The dashboard

Each site has one screen for every test on it. It refreshes quietly every minute while it's open; changed numbers briefly highlight.

Light or dark: the sun/moon button switches every screen at once. Until you choose, it follows your computer's setting.

Summary cards

Running, Ready to call, Needs attention and Finished, each with its count and a bar showing its share of all tests. Click a card to show only those tests; click it again to show all.

Filters

All, Running, Ready to call, Needs attention, Drafts and Finished, with counts. Archived, at the end of the row, shows archived tests; they're left out of All and the summary cards (see Archiving).

Each test

• Ring: Confidence to call. “baseline” under the number means the original is still being measured (see Measuring baseline).
• Page: opens the test's page in a new tab; the copy button beside it copies the full link.
• Status: Draft, Running, Measuring baseline, Ready to call, Data problem, Can't finish in time, Paused or Finished.
• Verdict: what the numbers say, in plain language (see Verdicts).
• Right side: days left and visitors so far, and the main action (Start, Pause, Resume or End test).

Opening a test

• Alerts for problems, warnings and which fallback method is in use.
• Key facts: start date, days running, visitors, visitors needed per version, baseline and primary goal.
• Results: visitors, conversions, rate and change for each version, with a bar showing the likely range of the true change (95%). If the bar is clear of the centre line, the difference is real.
• Conversion rate over time: cumulative, per version. Hover for daily values. Lines usually wobble early and settle.
• By device: conversion rate on desktop, tablet and phone.
• Secondary goals: other goals, for context only. They never decide the winner.
• Preview: open each version on the live page (never counted).
• Change log: who created, edited, started, paused or ended the test, and when, including changes made through the API or an AI agent.
• Actions: open in editor, end test, export CSV (daily totals only, no visitor data), export JSON, duplicate, archive, delete.

Confidence to call

One number from 0 to 100%. At 100%, the result is solid enough to end the test and read it, whether that's a win, a loss or no clear difference.

How it rises

• It tracks how much of the planned evidence has been collected: visitors so far in the version with the fewest, out of the visitors needed per version.
• It never passes 99% before the minimum run (14 days by default, set per site), so weekday/weekend swings and the first-days novelty effect can't decide a test.
• It can jump to 100% early when the difference is large. The data is checked at 20%, 40%, 60% and 80% of the plan against strict thresholds (O'Brien–Fleming), which makes stopping early safe. It still waits for the minimum run.

“Measuring baseline”

The baseline is how often visitors reach the primary goal on the original page today, e.g. “5% of visitors click the hero button”. Splitcraft needs it to work out how many visitors the test needs.

• Why it happens: the Current conversion rate on the Setup tab was left empty. That's the right choice when nobody knows the rate yet.
• What's going on: the test is already running normally. Visitors are split and counted as usual; Splitcraft is learning the original's rate from those same visitors.
• What you see: the status says Measuring baseline, the ring shows a small number (up to 10%) with “baseline” under it, and there's no “days left” yet.
• How long: until the original has at least 7 days, 200 visitors and 20 conversions, whichever comes last.
• Next: the rate is fixed, the test is sized automatically and Confidence to call rises normally. The days already run count; nothing restarts.

Days left

Estimated from the last 7 days of traffic and the visitors still needed, and never less than the days remaining in the minimum run.

Verdicts

Fallbacks and warnings

Before every update Splitcraft checks the data. When the usual method isn't reliable, it switches automatically and says so on the test.

The visual editor

Your page is shown at its real width (scaled to fit) with a panel on the right. It loads the live page with the snippet in editing mode, so the snippet must be installed first.

Top bar

• Back arrow: to the dashboard.
• Name: click to rename. Required.
• Status: Draft, Running, Paused or Finished.
• Versions: Original, Version B and any others. The number is how many changes each has.
• Device: desktop (1440px), tablet (820px) or phone (390px).
• Highlight changes (H): numbered tags on every changed element, matching the Changes list.
• Outlines (O): faint outlines on every element to show what's nested in what.
• Save: ⌘/Ctrl + S also saves. Leaving with unsaved changes asks first.

Modes

• Select: click any element to change it. Links and buttons don't work, so clicking selects.
• Browse: use the page normally to open menus, tabs and accordions, then switch back to Select to change what was hidden. Links to other pages are turned off.
• While moving an element or picking a goal, the bar says what to click and offers Cancel (or press Esc).
• Side by side: on the Setup tab the original and the version show together, scrolling in lockstep.

Readiness

• Tab badges: a tick when a tab's step is done, a coral dot when something's needed.
• Before you start: the checklist under the panel (each version has a change or page, a primary goal, a name and a 100% split; sizing is optional).

Making changes

Pick a version in the top bar (not the Original), then click an element in Select mode. The panel shows the element's type, its selector and its text.

Selecting precisely

• Breadcrumb: lists the element and everything containing it. Click a crumb to select that level.
• Outlines (O) reveal nesting; Browse mode opens hidden content.

Types of change

The Changes list

Every change is numbered and shows before → after. Click a change to select its element; × removes it. A red number means the element can't be found on the page any more.

Limits: 40 changes per version, 4 versions including the original.

Goals

A goal is what counts as success. One goal is primary and decides the winner; the rest are secondary and shown for context only.

Each visitor counts once per goal, and only after they've seen the test. Up to 8 goals per test.

Setup

• Page: the page being tested. Fixed once the test is saved.
• Type: Visual changes (edits on this page) or Split URL (each version is a different page).
• Versions and split: rename versions, add up to 3 beyond the original, and set each one's share of visitors. The split must add up to 100%. An even split finishes fastest.
• Current conversion rate (optional): how often visitors reach the primary goal today. Leave it empty and the first week measures it.
• Smallest improvement worth detecting: +5% to +50%. Smaller values need many more visitors; the estimate updates as you drag.
• End date: defaults to the site's default test length. If the test can't reach 100% by then, it switches to a directional read.
• Notes: the hypothesis, links, anything the team should know.

Split URL tests

Visitors in each version are sent from the test page to another page on the site. Build that page first (with the snippet on it), then enter it for each version on the Setup tab. It can't be the test page itself.

• Visitors are sent only once they're counted under the site's consent rules; everyone else stays on the original page.
• Query strings and #anchors carry over to the other page.
• Use goals that work on either page, such as a form or reaching a page.
• Set the other page to noindex, with its canonical pointing at the original, so search engines don't see a duplicate.

Comparing two HubSpot forms

Put the other form on a copy of the page, make a split URL test, and list both form IDs in the goal's Form IDs. With only one ID, the other page's submissions never count and that version always looks like it's losing. Give the new form the same workflows and routing as the original.

Starting a test

Click Start test… under the editor panel (it saves first) or Start on the dashboard. The review shows the page, each version with its split and number of changes, the deciding goal, how long it should take, who will see it, and the end date.

Pausing and ending

• Pause: everyone sees the original and nothing is counted. Resume carries on where it left off. Days paused still count toward the minimum run, so avoid long pauses.
• End test: choose what everyone sees from now on, the original or a version (the result's recommendation is preselected). A kept version keeps being applied for everyone without being counted; to make it permanent, build it into the page and then delete or archive the test.
• Duplicate: a new draft with the same versions and goals.
• Delete: removes the test and all its data for good.

Archiving

Archive a test when it's no longer relevant, to keep the dashboard focused on current work. Nothing is archived automatically.

• Drafts and finished tests move to Archived straight away.
• Running or paused tests are ended first: choose what everyone sees from now on, then End & archive. Keeping the original is the safe choice.
• Restore brings a test back exactly as it was.
• Read-only: an archived test can't be edited or started until it's restored. Its results, exports, duplicate and delete still work.
• Kept versions still apply after archiving; the test says so.
• Data: archiving deletes nothing. Per-visitor rows are removed after the site's retention period, as for any finished test.

Previews

Add ?sc=ID:b to a page's URL to force a version (?sc=12:b,13:a for several). Previews are never counted. The dashboard's Preview buttons build these links for you.

Links for drafts and paused tests also carry a signed sc_t token, since those tests aren't public. Anyone with the link can see that preview for 14 days; nothing else about the test is exposed.

Team opt-out

Your team visits the site far more than anyone else and would skew results. Open ?sc_optout=1 on the site once in each browser you use (the link is in the site's settings): that browser always sees the original and is never counted. ?sc_optout=0 undoes it.

For staff who are logged in to the site, add the login cookie's name prefix under Excluded cookie prefixes instead.

Who is counted

Consent

Each site chooses its cookie banner: CookieYes, OneTrust, Cookiebot, a custom one, or none. With a custom banner, call splitcraft('consent', true) when the visitor accepts analytics and splitcraft('consent', false) when they decline.

• Strict (default): only visitors who've accepted analytics cookies are in a test. Everyone else sees the original.
• Show, count on consent: visitors who haven't chosen yet also see a version, but nothing is stored unless they accept; if they do, that view counts. Reaches far more first-time visitors. Check with legal before switching it on.
• Visitors who decline always see the original and are never counted; anything stored is cleared.

Never counted

Opted-out browsers, browsers with an excluded cookie, excluded IP addresses, previews, the editor, bots and automated browsers, and prerendered pages.

Privacy and data

• Stored per visitor per test: a scrambled form of a random ID kept in their browser, which version they saw, when, device type (phone, tablet or desktop) and a broad traffic source (direct, search, social, email, paid, referral).
• Never stored: IP address, browser details, name, email, anything typed into forms, or the referring address. IP addresses are checked against exclusions and rate limits, then discarded.
• Where: in Splitcraft's database, visible only to your workspace. Nothing is sent to any other service.
• How long: per-visitor rows are deleted after the site's retention period (90 days by default) once a test ends; the totals and the final result are kept.

Site settings

Import and export

• Export a site's tests, or one test with its results, as Splitcraft JSON (splitcraft.site/v1, splitcraft.test/v1). Import it into another site or workspace.
• Import always creates drafts. Pages, goals and split pages must be on the receiving site's domains.
• From Convert: enter a Convert API key (application ID and secret, from the project's API keys settings). It's used for the import only and never stored. A/B experiences become visual tests (simple CSS becomes style and hide changes), split URL experiences become split URL tests, and click, page, form and code goals come across. Custom JavaScript and other goal types are listed on each draft to redo in the editor. Convert's results are kept on the draft for reference.
• Other tools: an AI agent connected to the other tool (directly or through its own MCP server) and to Splitcraft's MCP server can read a test there and recreate it here with import_test.

API and MCP

Create an API token under Workspace. It acts as you, in that workspace, and its actions show in each test's change log.

• REST API: /api/v1 with Authorization: Bearer sc_…. Sites, tests, status changes, results, previews, CSV and JSON export, import, and sample size. Errors are { error: { code, message } }.
• MCP server: /api/mcp (Streamable HTTP) with the same token. Tools cover listing and creating sites, creating and editing tests, starting and ending them, results, sample size, export and import, and Convert import. Workspace shows the exact command for Claude Code and a config block for other clients.

Best practices

Before the test

• Write a hypothesis in Notes: “Changing X to Y will increase Z because…”.
• Test one idea at a time. Several changes in one version are fine if they serve one idea, but then you learn about the idea, not each change.
• Make it bold. Small tweaks rarely move the needle enough to measure.
• Pick the primary goal before starting and don't switch it afterwards.
• Preview every version on every device.
• One test per page at a time. Overlapping tests on the same page muddy each other's results.

While it runs

• Don't stop early. “Leaning B” is not a result. Wait for 100%.
• Run whole weeks. The 14-day default minimum covers two full weeks.
• Don't change the page under a running test. If a content change breaks a test's changes, the dashboard flags missed edits.
• Avoid unusual periods (big campaigns, launches, holidays) or note them.

After the test

• Act on it: keep the winner, then build it into the page properly.
• “No clear difference” is a result. Keep the original or try something bolder.
• Record the learning in the test's notes, especially for losses.
• Check secondary goals for unwanted side effects before shipping a winner.

Keyboard shortcuts

Single-letter shortcuts don't fire while you're typing in a field.

Troubleshooting

The site never shows Installed.

Check the snippet is in the page's <head> and the page's hostname is one of the site's domains (www. and the bare domain are different; add both, or use *.example.com). Only counted visitors report in, so opted-out browsers, excluded IPs and visitors who haven't accepted cookies don't.

The editor shows a blank page or never connects.

The snippet has to be on the page for the editor to work. If the site blocks framing, allow the pop-up the editor opens.

A change shows a red number in the Changes list.

Its element can't be found on the page, usually because the page changed. Remove the change and make it again.

I can't click a link or open a menu in the editor.

You're in Select mode. Switch to Browse on the bar above the page.

Start test is greyed out.

Something on the checklist under the panel isn't done; it shows what.

The test has been “Measuring the original first” for a while.

It needs 7 days, 200 visitors and 20 conversions in the original. A rare goal takes longer.

It says “Can't finish in time”.

Traffic is too low for the planned sizing. Accept the directional read for a low-stakes change, move the end date, or duplicate the test with a bolder change.

It says “Data problem”.

Read the alert on the test: an uneven split, missed edits, slow loads or a tracking gap. Confidence to call stays frozen until the cause is fixed.

I see the original even with a preview link.

Check the test number and version letter in ?sc=ID:b, that the link is for the test's page, and that this browser isn't blocking the snippet.

The numbers don't match my analytics.

They aren't meant to. Splitcraft counts only visitors who are in a test (consent, exclusions), each once per test; analytics tools count sessions and page views differently.

Glossary

Baseline

The original's conversion rate for the primary goal. Entered in Setup, or measured in the test's first week.

Conversion

A visitor reaching a goal after seeing the test. Each visitor counts once per goal.

Exposure

A visitor seeing the test: when the first changed element comes into view (for every version, so the comparison is fair), or on page load for split URL tests.

Lift / change

How much higher or lower a version's rate is than the original's, in percent of the original.

Likely range

The range the true change probably lies in (95%). If it doesn't cross zero, the difference is real.

Smallest improvement worth detecting

The smallest lift the test is sized to find reliably. Smaller means more visitors.

Visitors needed

Per version, to detect that improvement with 95% confidence and 80% power, plus a little extra for checking along the way.

Sequential checks

Looking at the data at set points with strict thresholds (O'Brien–Fleming), so a big difference can end a test early without false wins.

Uneven split

Also called sample ratio mismatch: visitors not splitting as planned, a sign of a technical problem.

Small-sample method

Fisher's exact test, used when conversions are too few for the usual calculation.

Directional read

The chance a version is better and the expected downside of choosing it (Bayesian). Used only when a test can't finish; never a verdict.

More than two versions

Each version is compared with the original, with a stricter threshold (Bonferroni) so extra versions don't create false wins.

Snippet

The script tag each site loads. It holds the site's running tests and applies them.

MCP

Model Context Protocol: how AI agents such as Claude connect to tools. Splitcraft's MCP server lets an agent run tests for you.