Managing Rules

Edits to a rule's body (its targeting, variations, traffic split, name, order, and the act of declaring an A/B test winner) flow through the draft pipeline and require Publish changes to go live. Turning a rule on or off uses the separate Run and Pause controls and goes live immediately. See Rule Statuses for the operational flow.

Editing a rule: the ruleset in the middle, the rule's full editor on the right, and the draft's Publish bar below.

Rolling out to a share of people

The traffic allocation slider on a Targeted Delivery rule is a percentage rollout. At 30%, about 3 in 10 people who match the rule get its variation. The other 7 in 10 skip this rule and move on to the next one, and to the flag's default value if nothing else matches. At 100%, everyone who matches gets the variation.

Each person's place in the rollout is fixed for that rule, so raising the percentage only adds people. Nobody who already has the variation loses it when you go from 30% to 50%.

Percentage rollouts need these SDK versions or later: @avsbhq/node 1.8.0, @avsbhq/browser 1.5.0 and @avsbhq/edge 1.2.0 (the framework packages released with them require them), and 1.0.1 of the Python, Ruby, PHP, .NET, Java and Go SDKs. An older SDK ignores the percentage and gives the variation to everyone who matches.

Reordering rules

Each rule card has a grip handle on the left edge. Drag a card by its handle and drop it where you want it in the list. The new order is staged in the draft and shows up in the bottom bar's change count as one pending change, regardless of how many cards moved.

  • The handle responds to mouse, trackpad, touch, and keyboard input. Use Tab to focus a handle and Space to start a keyboard reorder.
  • The Add Rule menu and each rule's actions menu work with the arrow keys, and Escape closes them. Choosing a rule type puts the cursor straight into the new rule's name.
  • While you write a new rule, it shows at the end of the list as Not added yet until you publish or save it.
  • The change appears in the publish review as a single Reordered N rules entry that lists the new order, and the bottom bar counts it once.
  • Publishing persists the new sortOrder values to every affected rule in one transactional bulk save.
  • A/B Test and Targeted Delivery rules can be dragged into any order relative to each other. Nothing stops you from placing a Targeted Delivery rule above an A/B Test rule. Whatever order you leave them in is the order visitors are evaluated against.

Copying rules from another environment

Open Add Rule and pick an environment under Copy rules from. Every rule in that environment comes into your draft at once, so you don't have to rebuild them by hand.

  • Each copied rule lands in your current draft as a new rule with Draft status, whatever status it held in the source environment. You still need to click Run on each one yourself.
  • A copied rule keeps its source key when this environment doesn't use that key yet. If it does, the copy becomes <key>-copy (then -copy-2 and on), the same rule a copy through the API follows. Its run history is cleared: launch date, conclusion, and any early-stop reason.
  • Exclusion group membership and per-user overrides are not copied, because both decide who sees what in this environment. Set them on the copy if you need them.
  • Like any other draft change, nothing is written until you click Publish changes.

Choosing metrics for an A/B test

The Metrics picker on an A/B test rule lists every metric your project can use: the project's own metrics and the ones shared across your organization. A metric does not have to be in use by another rule before you can pick it, so a brand-new project can attach its first metric straight away. Archived metrics are not offered.

If the metric you need does not exist yet, click Create a new metric at the bottom of the picker. The metric editor opens on top of the rule, so nothing you have typed into the rule is lost. Save the metric and it appears in the picker, already selected for this rule. Close the editor without saving and the rule is exactly as you left it.

Allowlists

An allowlist sends specific user IDs straight to a variation you choose, before targeting and traffic splits are checked. Each rule has its own allowlist, and the environment has one more. If a user is in both, the environment's allowlist wins.

  • Each user ID can be listed once per allowlist. The rule panel tells you as you type: a repeated user is named under its row, or the Add button refuses it with the reason. Publishing is refused too until the second entry is removed, and nothing is published in the meantime.
  • The same user can sit in the environment's allowlist and in a rule's allowlist: they are separate lists.

Opening a deleted rule by URL

If you (or another editor on the shared draft) have queued a rule for deletion, the rule no longer appears in the list. But a deep link with ?rule=<id> still resolves, opening the rule detail panel with a yellow banner instead of silently doing nothing.

The banner gives you two options:

  • Undo delete: Restores the rule in your draft. The rule reappears in the list, marked Edited so you remember it was touched. Publishing keeps it.
  • Close: Closes the panel and leaves the deletion queued. The rule still goes away on the next publish.

The rule's form fields are read-only while the banner is showing. Native inputs are disabled, and every custom control inside the panel (chip pickers for audiences and metrics, the drag-to-reorder primary-goal list, the Manual / Allocate Equally toggle on the traffic allocation card, and lock buttons on the variation sliders) renders a faded, non-interactive state so it's obvious at a glance the form is currently a tombstone. Restore the rule first if you want to edit it.

Concluding an A/B test

Declaring a winner used to write directly to the live tables and force a page reload. It now goes through the draft like every other edit:

1

Open Conclude

Open the actions menu on a running or paused A/B test rule and choose Conclude. A rule whose winner is already staged or published does not offer it again.

2

Pick the winner

Select the winning variation and click Conclude.

3

Confirm an early stop, if asked

Concluding a Frequentist-engine rule before it reaches its target sample size opens a second screen that warns you about stopping early. Type an optional one-line reason and click Conclude anyway and log. Or click Let it run to back out and keep the rule running. Under the Bayesian or Sequential engine, or once you've reached the target sample size, this screen never appears: the winner stages as soon as you click Conclude.

4

Publish changes

A message confirms the winner is staged. Click Publish changes to commit. The rule becomes Concluded, the winning variation gets pinned to 100%, concludedAt is set, and (if you stopped early) the reason you gave is persisted alongside it. Your SDKs start serving the winner to everyone the rule targets in the same step, and History records the conclusion with the winner's name.

You can conclude from the rule's card or from its open panel. With the panel open, its traffic card switches to the winner at 100% as soon as you click Conclude and stays locked. Anything else you changed in the panel is published together with the conclusion, and the rule keeps its metrics.

Info

If you change your mind before publishing, click Revert in the bottom bar to discard the conclude (along with any other staged edits in this session).

Concluded rules can no longer be edited, only duplicated or deleted, and they don't move with drag-to-reorder, since their order doesn't affect bucket assignment any more.

Was this helpful?