Skip to content
Adoptiv

A/B Split Testing

A box with an arm on each side and arithmetic deciding which one somebody takes. Because it is arithmetic and not a coin, asking twice gives the same answer twice.

Which arm a lead takes, and why it never changes

arm B
Run
58e2b3d0-91af-4c67-bd12-3e70a9c81d4b
h = 5381thenh·33 + bytegives49,365,667mod 10067
One hundred units of weight, divided by the arms
Arm A · 50
Arm B · 50
099
port a
  • Send: case study
  • Wait 3 days
  • If replied
port btaken
  • Send: short ask
  • Wait 5 days
  • Exit
ab_assigned { port: "b" } written against the runweights 50 / 50 · no field on the inspector
The remainder of the hashed run identifier against the total weight picks the arm. No random number is drawn, and the assignment is written down as an event rather than read back from one, so nothing has to be remembered between passes.
0
arms the box arrives holding
0
units of weight the default arms add up to
0
the number the hash counts up from

Product figures from the platform’s own defaults - not customer averages

The mechanism

How it works.

01

The arm is computed, never rolled

The run identifier goes through a small fixed hash and the remainder against the total weight picks the arm. Nothing random is drawn and nothing is stored to remember the choice, so re-running the same step lands the same side every time.

02

The weights are what divide the range

Each arm carries a weight and the engine cuts the range in proportion to them, so a ninety-ten division is two numbers on the box rather than a different kind of step. A box you drag on arrives at fifty apiece, which is the even split most people want first.

03

Each arm is a port with a whole subtree behind it

Whatever hangs off one side is a full branch of the cadence in its own right, with its own sends, pauses and questions. The two sides never have to meet again, and one of them may simply stop.

04

The assignment is recorded the moment it is made

Before moving on, the box writes down which side it chose against that person's run. So the population either side can be counted from the event record rather than reconstructed from who received what.

Where it sits

One moment in every run.

Every run passes through the same seven. A/B Split Testing is the lit one, and everything either side of it is a different page in this category.

  1. 01
    Trigger

    the thing that happened first

  2. 02
    Enrol

    how somebody gets onto it

  3. 03
    Wait

    the pause, and what governs its length

  4. 04
    Branch

    the fork, and which side is taken

  5. 05
    Act

    the mail, the text, the task that goes out

  6. 06
    Measure

    what counts as it having worked

  7. 07
    Exit

    how somebody comes off it

The specifics.

7 facts
Arms
Two in the box you place. The stored format allows more, each with a port name of its own
How the side is chosen
A remainder of the hashed run identifier against the weights added together. An arm with no weight written on it counts as one
Stability
Deterministic. Nobody changes sides part-way through a cadence
Weights
Fifty and fifty on a new box, held on the arms themselves and changed one arm at a time
Control groups
A different mechanism. A percentage set on the sequence parks those people before they take any step
What it will not do
No significance test, no winner declared, and no promoting the better side afterwards
Not the same as
This divides an audience by weight. Reacting to what somebody did is Branch Logic

More in Automation & Flows

13 capabilities

Sequences, dispositions and webhooks that act without being asked.

Inbound Webhooks

A unique URL per integration with HMAC signing, rate limits, payload caps and idempotency - plus a log of every delivery it ever accepted or refused.

Email Sequences

Enrol a lead once and the sequence carries them: sends, waits, branches and exits, with a ledger that makes a duplicate send structurally impossible.

Wait & Timing

Hold a lead for minutes or days between steps, clamped to the sending window you set, so that an overnight wait never lands at four in the morning.

Sending Windows

Set the hours a sequence may send inside, as a fixed offset you enter yourself, and every wait is pushed forward into them before it is stored.

Suppression Lists

One do-not-contact roll per workspace, checked when a lead is enrolled and again inside the send, straight after that send has taken its own claim.

Auto-Enrollment

New leads enrol themselves the moment they are created, and the four guards that can refuse an add are read on every single route into a cadence.

Call Tasks in Sequences

Drop a call step into a sequence and it raises an assigned task on the lead's owner, with the outcome the rep logs coming back as a branchable answer.

Disposition Behaviours

Twenty-six behaviours attach to wrap-up codes, and twenty codes ship already pointing at one, so ending a call the right way books the follow-up.

Workflow Triggers

Six event types a CRM rule fires from: stage change, field update, new record, reassignment, schedule and inactivity, agreed in four places at once.

Workflow Actions

Send the email, assign the owner, raise the task, set the field, move the stage or call a webhook. Six modules, run in the order you stored them.

Conditional Logic

Eight comparison operators guarding each action, combined with AND and only AND, so a rule meaning either of two things is built twice, as two rules.

SMS in Sequences

A text is a step on the same canvas as the email and the call task, written into the real thread and carried out by the number it is going out from.

REST API

A versioned path, a key minted once and kept as a hash, and the same role and profile model the interface runs on deciding what that key may touch.

Automation & Flows

See a/b split testing on your own floor.

Thirty minutes, your numbers and your data. We will set a/b split testing up live and you can decide from the thing itself rather than from this page.

14-day trial · no card · migration included