Link Rotators and Self-Optimizing Split Tests

Two features look almost identical on a feature list and answer completely different questions. A rotator spreads traffic from one short link across several destinations. An A/B test splits traffic between variants and tells you which one did better. Both put more than one address behind one link; only one of them is a measurement.

This guide covers where the two genuinely differ, how weights behave in each, why keeping a visitor on one destination matters more than the distribution does, what a health check can and cannot detect, how automatic reweighting works and why it refuses to act early, and when the simpler tool is the right one.

A Rotator Is an Operating Tool, a Split Is a Measurement

The distinction is not academic. It determines which behaviours you get for free and which ones you have to build around.

| | Destination rotator | A/B split | | --- | --- | --- | | Purpose | Keep one address working across changing destinations | Compare destinations and decide | | Weights | Relative, any values | Integers totalling exactly 100 | | Set of options | Changes constantly, up to twenty | Fixed for the duration of the test | | Per-option limits | Click caps, date windows, country and device filters | None — a variant is a variant | | Failure handling | Unhealthy destination removed automatically | Not applicable | | Ends with | Nothing; it keeps running | A winner, or an honest "not yet" |

A rotator earns its place when the address is the stable thing and the destinations move: a printed code that will outlive three offers, a bio link, an affiliate placement where the advertiser rotates creatives weekly. A split earns its place when you have one question and enough traffic to answer it. Running both on the same account for different links is normal; running both on one link usually means one of them is doing nothing.

Weights: Relative, and Recalculated on Who Is Eligible

Rotator weights are shares, not percentages. A destination's share is its weight divided by the sum of the weights of the destinations that are currently eligible — so weights of 3, 2 and 1 mean a half, a third and a sixth, and nothing needs to be renormalised by hand when you add a fourth.

Eligibility is evaluated before weights, and that ordering is what makes the feature operational rather than decorative. A destination drops out of the candidate set when it is switched off, when it has used its total or daily click cap, when its date window has not opened or has closed, when the visitor's country or device is outside its filters, or when a health check has taken it down. The rest absorb its share in proportion to their own weights, immediately and without anyone editing anything at three in the morning. When every destination is out, a fallback address catches the remainder; without one the link keeps serving its main destination rather than becoming an error page.

The rotator also offers two unweighted distributions: round robin, which sends consecutive clicks to consecutive destinations, and uniform, which splits evenly. Round robin is the one for load spreading between mirrors, being the only mode that guarantees consecutive clicks land in different places.

The A/B split behaves in the opposite way, and for a good reason. Its weights are integers that must total exactly one hundred, because the redirector maps a visitor into a bucket from 0 to 99 and walks cumulative weights: any gap in that range would be traffic served by nothing. The weighted rotator distribution is checked against a hundred thousand synthetic visitors and required to stay within one percentage point of the configured shares, which is the level of precision worth expecting from any tool that claims to split traffic.

Keeping One Visitor on One Destination

Rotation without stickiness produces nonsense. A visitor opens the link, sees offer A, comes back an hour later, sees offer B, and every funnel report built on those clicks is fiction — not slightly wrong, fiction, because numerator and denominator now describe different pages.

The sticky window is therefore a first-class setting, configurable from zero to thirty days, and the mechanism has two layers. The base assignment is derived deterministically from the visitor's daily fingerprint, so it is stable without a session, a database row or anything stored per visitor. A first-party cookie on your own redirect domain then carries the chosen destination forward for the length of the window, which is what makes stickiness outlive the nightly rotation of the fingerprint salt.

Two consequences are worth knowing rather than discovering. A visitor who clears cookies or arrives on another device falls back to the derived assignment, stable within a day but not necessarily across days — the same trade the analytics layer makes to avoid persisting an identifier. And a pinned visitor stays pinned after you change the weights, because the pin wins over the distribution while the destination is still eligible.

One implementation detail has a visible effect. The rotator derives its bucket from a different slice of the visitor fingerprint than the A/B split does. Sharing a slice would correlate the two assignments, and everyone in variant A would systematically see only part of the destination list.

Health Checks and Getting a Dead Page Out of Rotation

Destinations rot. A partner takes a page down, a certificate expires, an offer is pulled, a domain lapses and reappears as a parking page selling itself. Meanwhile the short link keeps sending its share of traffic into the wall, and nobody notices until the weekly report.

A scheduled check follows each destination the way a visitor would and records four things: the status code, the number of hops in the redirect chain, the response time, and the expiry date of the TLS certificate. It also compares the page against a fingerprint captured when the destination was added — the final host and the page title — which is how a URL that now returns a healthy 200 from a parking page is caught. The same probe underpins the link checker, and a destination is not rechecked more often than every fifteen minutes so that a large workspace cannot turn its own monitoring into a traffic source.

What happens next is a per-link choice. The default is loud but passive: the destination is badged in the link list, owners get a digest email, and a webhook fires. Turn on automatic removal and it is also taken out of rotation until it recovers, marked as auto-disabled rather than quietly deleted, so "the rotator is fine" becomes something somebody checked. Re-enabling is manual on purpose — a page that flapped once will flap again, and a human should see it before traffic returns.

Two honest limits. The check runs from our infrastructure, so it verifies that the page answers, not that it answers correctly for a visitor in a particular country on a particular device. And parking detection matches known patterns; a destination that returns a perfectly valid page with the offer removed will still look healthy, which is why per-destination conversion data matters more than any health badge.

Caps That Hold Across an Edge Network

A click cap is only meaningful if it holds when the same link is opened simultaneously in a dozen countries. Independent per-region counters are how a destination limited to a thousand clicks delivers fourteen hundred: fourteen data centres each counted to a hundred and each believed it was under the limit.

The design that avoids it runs at two speeds. Counter snapshots travel inside the link's cached configuration, so the redirector knows roughly where a destination stands without a round trip on the hot path. When a destination comes within a few dozen clicks of its cap, the redirector switches to an authoritative reservation in a shared store before answering, so two simultaneous clicks on the last slot are resolved by one atomic increment and the loser goes elsewhere rather than over the limit.

The trade-off, stated plainly: away from the boundary the number is a snapshot rather than a live count, so a cap is exact where exactness matters and approximate where it does not — which is what keeps an unlimited destination from paying a round trip for a limit it does not have.

How Self-Optimisation Actually Works

A self-optimising split adds one thing to an ordinary split: a scheduled job that recomputes the weights in favour of whichever variant is doing better on the goal. Everything else — bucketing, stickiness, reporting — is unchanged, and the redirector never learns the mode exists, because it receives ordinary weights that happen to have been calculated for it.

The job runs hourly and works in three steps. It collects each variant's click deltas since the last run and adds them to a stored sample. It scores each variant with a smoothed rate, adding one to the successes and two to the trials, so a variant with three clicks cannot post a perfect score and a divide-by-zero cannot happen. Then it distributes one hundred integer points across the variants in proportion to those scores, after reserving a floor of five points for every variant.

That floor is the most important line in the algorithm. A variant reduced to zero would never accumulate another observation, and the decision to abandon it would become permanent on the strength of whatever sample produced it. Five points is enough to keep learning and cheap enough not to matter.

Here is a two-variant run after the gates have opened:

| Variant | Clicks | Goal events | Raw rate | Smoothed score | New weight | | --- | --- | --- | --- | --- | --- | | A | 620 | 31 | 5.00% | 5.14% | 54 | | B | 610 | 25 | 4.10% | 4.25% | 46 |

Note what the algorithm did not do. A relative difference of roughly a fifth in conversion rate produced a 54/46 split, not a 90/10 one, because the reweighting is proportional to the score rather than a winner-take-all rule. Automatic optimisation tilts; it does not switch. If you want a switch, fix the winner by hand — that routes all traffic to one destination and ends the experiment, and the decision is recorded in the link's history alongside the automatic ones.

Why a minimum sample comes before any of this

Two gates keep the distribution even before the optimiser is allowed to touch anything: a warm-up period measured in calendar time, and a minimum total sample measured in clicks, one thousand by default. Below either gate the weights are not adjusted at all rather than adjusted a little.

The reason is not statistical fussiness, it is the shape of link traffic. The first hours of a campaign are dominated by whichever channel published first and by automated traffic scanning the link, as covered in our guide to tracking link clicks. A rate computed on that window describes the publishing schedule, not the pages. Worse, an optimiser that acts on it starves the variant that happened to launch into a quiet hour, and the starved variant then accumulates evidence more slowly, which makes the early mistake self-reinforcing. The floor limits the damage; the gates prevent it.

Two things the automatic mode does not do. It is a proportional reweighting, not a sequential test: it does not compute a significance level and it never declares a winner, which stays a human action taken next to the confidence note the split test screen prints under the variant table. And the sample it reweights on is only as meaningful as the goal you feed it — if every click counts as a success, every variant scores the same by construction and the split stays effectively even. A tilt requires a goal that not every click reaches, which is what conversion tracking records per variant; the signed click identifier carries the variant label, so orders and revenue break down by variant in the reports described in conversions.

When You Do Not Need a Rotator

| Situation | Better tool | | --- | --- | | One destination now, a different one next month | Edit the link's destination; the short address and its history are unchanged | | A different page per market | Ordered targeting rules — deterministic and readable | | One question, two candidate pages | A plain split with the confidence note | | Phones into an app, desktops to the site | Deep link fields on the link | | Several mirrors of the same page | A rotator in round robin mode, which is the case it was built for |

The general rule: a rotator earns its complexity when destinations change without the address changing, and costs clarity everywhere else. A weighted share is harder to reason about than a rule, and anyone who has debugged "why did this visitor get that page" at eleven at night knows which they would rather read. Configuration details are in the rotator guide and the links guide.

A Setup That Holds Up

1. Start with the simplest tool that answers the question, and add rotation only when the destination list actually changes.
2. Set a sticky window of at least a session for anything with a funnel behind it, and zero only for load spreading.
3. Give every destination a cap or a window if it has a real limit, and set a fallback so exhaustion is not an error page.
4. Turn on automatic removal for destinations you do not control, and leave it off where a brief outage beats a silent redistribution.
5. Let the warm-up and minimum sample expire before reading anything into a self-optimising split, and check the confidence note before fixing a winner.
6. Read results per destination: the click event records which one served it, so clicks, unique visitors and revenue all break down that way.

The pattern behind all of it is the same. Rotation, caps and reweighting keep a link doing the right thing while nobody is watching it. They do not replace looking at which destination earns — they buy you the time to look properly.