Experiments

Experiments are Clickport's built-in A/B testing. You test two versions of a page against each other and measure which one converts better, using the goals you already track. There is no separate testing tool to buy, no extra script to load, and no cookies: the variant a visitor sees is decided and remembered on their own device, and only the variant name, a plain string like new-hero, ever reaches Clickport.

You create an experiment in Settings → Experiments, make the change visible with a few lines of CSS or a duplicate page, and read the result in the Experiments tab on your dashboard. Clickport tells you in plain words when a test is decided, and, just as important, when it is not.

How it works

An experiment is three things bolted together:

• A variant assignment. The tracker splits visitors between your variants by the weights you set. The choice is stored in the visitor's browser (localStorage), so they see the same variant on every visit from that device.
• A tag on the data. The assigned variant rides along on the visitor's pageviews as a custom property. That means variants work everywhere properties work: you can filter your whole dashboard by a variant with one click.
• A goal as the metric. The experiment measures one of your existing goals. Nothing new to instrument: if the goal already counts signups, the experiment compares signup rates per variant. If your goals carry revenue, you see revenue per variant too.

The tracker checks for running experiments once per visit with a single small request. If your site has no experiments, that request returns an empty list and nothing else happens.

Create your first experiment

Open Settings → Experiments and click + Add experiment. Four fields: a name, your variants with their traffic share, where the experiment runs, and the goal it measures.

The name is lowercase with digits and hyphens, like hero-test: it appears in your CSS and dashboard. The first variant is your control, the current version, and weights must add up to 100. Any existing goal works as the metric: clicks, forms, pageviews, or custom events. Save, press Start, and the experiment is live for your visitors within a few minutes.

Reading results

The Experiments tab on your dashboard lists every experiment with its status at a glance:

Click an experiment to open the breakdown. Each variant row shows visitors, conversions on the measured goal, the conversion rate, and attributed revenue:

The bar compares rates at a glance. Clicking a variant row filters your entire dashboard by that variant: Sources, Pages, Countries, and Sessions all reorient around the visitors who saw it, like any other filter in Clickport.

What "chance to win" means

The verdict line shows the probability that the challenger genuinely converts better than the control, given the data so far. 50% means a coin flip: no information yet. 92% means strong evidence, but roughly a 1-in-12 chance the difference is noise. Clickport declares a winner at 95% or better, and only after the minimum run is met.

Why Clickport refuses to declare early winners

Every experiment has a minimum run: 7 days and 1,000 visitors per variant by default. Before both are met, the verdict stays at "collecting data" no matter what the numbers show. This is deliberate, and it is the most important honesty feature in the product.

Checking a test daily and stopping the moment it looks significant produces false winners at several times the promised rate. It is the single most common A/B testing mistake. The time floor also protects you from weekday effects: a test started on Friday sees weekend traffic first, and weekend visitors often behave differently.

Once an experiment has run for a few days, the breakdown shows the chance to win day by day. A real effect climbs steadily toward the threshold. Noise wobbles. Seeing the history protects you from trusting an early spike:

The engagement guardrail

Every experiment automatically watches a second metric: engagement. If the challenger wins on conversions but visitors on it engage noticeably worse, the verdict says so instead of celebrating. A pushier page that converts more but drives people away is the most common false win in practice, and it never gets flagged by tools that only look at the goal:

The guardrail never stops an experiment on its own. It puts both numbers on the table and leaves the decision to you.

How long will a test take?

The honest answer: longer than most people expect. Detecting a small improvement takes a lot of visitors. Rough guide, assuming a 4% baseline conversion rate:

• Detecting a +50% lift (4% to 6%): about 1,700 visitors per variant.
• Detecting a +20% lift (4% to 4.8%): about 10,000 visitors per variant.
• Detecting a +10% lift (4% to 4.4%): about 39,000 visitors per variant.

Divide by your daily traffic on the tested pages and you have the test duration. If the tested page gets 40 visitors a day, a +20% test would take over a year, and you should not run it. Test on your highest-traffic pages, test sitewide elements, or test against high-baseline goals like outbound clicks, where differences show up much faster.

Example experiments

Six tests worth copying, each with the result screen you would see. All numbers are illustrative.

Pricing page: annual billing first

Variant B shows the billing toggle preset to annual with the discount note visible. Measures a Trial started goal. A classic, and often a real winner because it changes what visitors anchor on.

Affiliate box style on a content site

Variant B renders product boxes with a visible price and an explicit button instead of text links, via pure CSS. Measures a click goal on outbound links containing your partner domain. High baseline, so results come fast even on moderate traffic.

Signup form length

Variant B asks only for an email; name and company move to after signup. Measures the Account created goal. Form-length tests routinely produce the biggest lifts of any test type.

Blog newsletter box placement

Variant B moves the newsletter box from the end of the article to after the intro. Measures the newsletter signup goal, with the engagement guardrail watching whether the pushier placement hurts reading. This one usually ends the honest way:

Landing page message match for ads

Ads land on a page whose headline repeats the ad's exact promise (variant B) versus your generic page (control). Measures a lead form goal. Filter results by campaign to read each ad separately.

Split-URL redesign test

A full redesign of a key page, built as a separate URL. The builder's split-URL mode sends half the visitors there. Early days look like this, and the verdict keeps you patient:

Ship the winner

When a test is decided, the verdict turns green and Ship winner appears. It ends the test and serves the winning variant to every visitor from that moment on:

Shipping the winner buys you time: hardcode the winning version on your site whenever convenient, then delete the experiment. The other lifecycle actions work the same way. Pause stops assigning new visitors while keeping data. End closes the test; its full history stays readable in the dashboard.

Make the variant visible

Clickport decides which variant a visitor gets. What that variant looks like is your side of the deal, and there are three ways to do it, from no-code to full control.

Pure CSS, no JavaScript

While an experiment runs, the tracker sets the assigned variant as an attribute on the page's root element. Your stylesheet can react to it:

/* both versions live in your page markup */
[data-cp-hero-test="new-hero"] .hero-old { display: none; }
[data-cp-hero-test="control"] .hero-new { display: none; }
/* default while no variant is assigned yet: show the control */
html:not([data-cp-hero-test]) .hero-new { display: none; }

This works in any CMS that lets you add custom CSS. No template logic, no JavaScript.

A JavaScript callback

For changes CSS cannot express, register a callback. It fires as soon as the variant is known:

clickport.onVariant('hero-test', function (variant) {
  if (variant === 'new-hero') {
    // reorder sections, swap text, change behavior
  }
});

Code-defined experiments

You can also skip the dashboard setup entirely and define the experiment in code. One line assigns, persists, and tags:

clickport.variant('hero-test', ['control', 'new-hero'], function (v) {
  if (v === 'new-hero') document.documentElement.classList.add('new-hero');
});

Code-defined experiments split traffic equally and show up in your dashboard like any other, keyed by their name.

Split-URL tests

The easiest test for non-developers: duplicate the page in your CMS, change what you want on the copy, and give the challenger variant a URL in the experiment builder. Visitors assigned to that variant are redirected from the original page to your variant page.

• Target the experiment at the original page (Page is /pricing).
• Give the challenger variant the URL of the copy (/pricing-b). The control needs no URL.
• On the variant page, set <link rel="canonical" href="https://yoursite.com/pricing"> pointing at the original. This tells search engines the two pages are the same content and keeps the original in the index. This matches Google's published guidance for A/B testing: temporary redirects and canonical tags, never a permanent redirect, and never special treatment for crawlers.

Preview and QA before you start

Append ?cp-variant=hero-test:new-hero to any URL on your site to force that variant on your own device. The choice sticks, so you can browse around and check every page. Force the control the same way to switch back. Preview works even on devices that are excluded from tracking, so you can QA without polluting your data.

Before starting a real experiment, check the whole chain once: the variant renders (preview link), the goal fires (check the Goals panel), and the experiment shows in the dashboard as running.

Limits, behavior, and privacy

• Up to 20 experiments per site, 2 to 4 variants each. Weights are whole percentages summing to 100.
• Assignment is per device. The variant is stored in the browser's localStorage. The same person on their phone and laptop can see different variants. For marketing-site tests this is acceptable; for logged-in product experiments you want a different kind of tool, and we would rather tell you that than pretend otherwise.
• First visit timing. On a visitor's very first visit, the variant applies as soon as the tracker has loaded its experiment config. A change high on the page can flash from original to variant for a moment on that first visit. Repeat visits apply instantly from the device's cache. Prefer testing elements below the fold, or keep both versions in the markup with the CSS default rule shown above.
• No cookies, no identifiers. The assignment never leaves the device; only the variant name travels with the pageview, like any custom property. Nothing about experiments changes Clickport's privacy model.
• Excluded devices never enter experiments on their own. The preview parameter is the deliberate way in.
• Variant data is a normal custom property under the hood (exp:<name>), so it appears in exports and the Stats API like any other property.