Core Concepts
What each idea in ABMeter is, why it exists, and how it connects to the others
ABMeter is built from a small set of ideas in two groups. Some belong to your whole account: space, event type, measure, metric and audience. The rest live inside one space: parameter, variant, experiment, feature flag, exposure and effect. Each section below says what one of them is, why it exists, and what it connects to. The sections build on each other, so read them in order the first time. One example runs through the page: a checkout button whose color you want to test.
For field-level details, see the API Reference. To start using ABMeter, see the Quick Start Guide.
Across your account
You set these up once, and every space uses them.
Space
A space is all of your users, 100% of them, as one pool. Each experiment in a space takes a share of the pool, and the shares never overlap. A user is in at most one experiment per space.
Why it exists
You will want to run more than one test at a time, and you need to say whether two tests may see the same users. Put a checkout test and a search test in two spaces, and both run at full speed on all of your users. Put them in one space, and they split the pool: each runs slower, and no user sees both. Choose one space when the two changes could affect each other's results. A space separates traffic; whether two effects can meet is yours to judge. A space is a pool of users walks through the choice.
How it connects
Event types, metrics, user lists and predicate audiences belong to your account, and every space uses them. Parameters, variants, experiments and feature flags each belong to one space. Start with one space and add a second when two tests wait for each other's traffic.
Event and event type
An event is something a user did, sent from your code: a slug that names its type, such as purchase-completed, the user ID, the time, and any custom fields, such as amount. An event type declares those custom fields and their types.
Why it exists
An experiment needs outcomes, and only your application knows them: a click, a sign-up, a purchase. Events carry those outcomes to ABMeter. The event type exists so that a metric can rely on a field. If purchase-completed declares amount as a Float, a sum of amount means something, and ABMeter checks each event against its type when it arrives.
How it connects
Event types belong to your account, and every space uses them. An event does not name an experiment. ABMeter links it to an experiment through the user ID and that user's exposure.
Measure
A measure is an aggregate over events of one type: count_distinct(purchase-completed) is the number of distinct users who bought, and sum(purchase-completed.amount) is the total they spent.
Why it exists
A measure is the building block of a metric, and it always names its event type. So it is never unclear what is being counted: sum(amount) could mean anything, sum(purchase-completed.amount) cannot.
How it connects
A measure reads events of one type, and metrics combine measures. You do not create measures separately; you write them inside a metric's formula. The API Reference lists the available functions.
Metric
A metric is a named number you care about, written as a formula over measures. count_distinct(purchase-completed) is conversion, the share of exposed users who bought. sum(purchase-completed.amount) is revenue per exposed user. ABMeter evaluates the formula once for each exposed user.
Why it exists
An experiment answers one question, and the question has to be fixed before the data comes in. A metric names that question and keeps it the same across tests: "conversion" means the same formula in every experiment that uses it. Choose the metric that decides the experiment before you start. Picking the best-looking metric afterwards makes chance look like a result.
How it connects
Metrics belong to your account and can be reused by any experiment in any space. An experiment has one primary metric and optional guardrail metrics. Results are computed on metrics, never on raw events.
Audience
An audience is a set of users. A chosen audience is either a user list, a named set of user IDs, or a predicate, a condition on the user, such as an email address at your company's domain. A random audience is a percentage of an experiment's users, such as the 50% that see green.
Why it exists
Flags and experiments both need to say "these users", and the answer must not change between calls. The same user is always in or always out: across requests, servers and devices, as long as your code passes the same user ID. Without that, a user could see gray on one page and green on the next, and neither a rollout nor a test would mean anything.
How it connects
Chosen audiences belong to your account, so one audience, say your internal team, can serve many flags. Random audiences belong to one experiment and exist only inside it. ABMeter assigns users by their user ID; the email is used only to match predicates.
Within a space
These live inside one space. Experiments and flags in other spaces never see them.
Parameter
A parameter is a named value your code reads, such as checkout-button-color. It has a type (String, Boolean, Integer or Float) and a default, here gray. Your code asks ABMeter for the value of the parameter for a user, and ABMeter answers.
Why it exists
Your code never names an experiment or a variant. It asks for a value. The same call serves the default before any test, the test's values while it runs, and the winner after it ends, so a finished test leaves no if variant == 'test' branch behind. ABMeter works this way because the code outlives the experiment: a test runs for weeks, and the checkout button stays in your code for years. Parameters, not flags shows the three stages.
How it connects
Each parameter is created in one space. Variants set other values for it, and experiments and feature flags decide which users get those values. When you apply an experiment's winner, the winner's value becomes the new default.
* A parameter's name is unique across your whole account, by design. Your code asks for a parameter by name and never names a space, so the name has one meaning and one default, and only one running experiment can test it at a time. A space is a pool of users explains why.
Variant
A variant is a named set of parameter values that differ from the defaults. A variant green-button sets checkout-button-color to green. A variant high-contrast might set both a text color and a background color.
Why it exists
Real changes are rarely one value, and the values must agree. A user with the new text color and the old background may get a page nobody can read, and the test would measure that page instead of the one you designed. So a user gets every value of a variant or none of them. This lets one experiment test a whole experience, such as a shorter checkout, as one thing. A variant is a bundle explains the rule.
How it connects
A variant belongs to a space and sets some of that space's parameters. An experiment gives a variant to each test group, and a feature flag gives one variant to its audience. Every variant in one experiment must set the same parameters, so the groups compare the same thing.
Experiment
An experiment tests a hypothesis. It takes a share of a space's users, splits them at random into groups, gives each group a variant, and compares the groups on a metric. The control group gets the defaults. For the checkout button: half of the users see gray, half see green, and the experiment compares how many of each buy.
Why it exists
To know whether a change helps, you need two groups that differ only in the change. A random split gives you that: any other difference between the groups is chance, and the statistics account for chance. Before and after comparisons cannot do this, because the week, the season and the traffic change too. An experiment also has a fixed life: you design it, start it, stop it, and then a person decides. Applying the winner writes its values into the parameters' defaults; keeping the defaults leaves everything as it was. Once a test starts, each user stays in the group they were first assigned to, so ABMeter refuses edits that would move them; A user's group is a fact explains why.
How it connects
An experiment lives in a space and takes a share of it, its allocation. Its groups are random audiences that belong to the experiment, each with a variant, and control with none. It has one primary metric that decides the test, and optional guardrail metrics you watch for harm. If your traffic is small, check the sample size calculator before you start: it tells you whether the test can reach a result, and what to do instead when it cannot.
Feature flag
A feature flag gives one variant to one chosen audience, such as your own team, while everyone else keeps the defaults. A flag that gives green-button to your team shows them the green button before any experiment starts. A flag is enabled or disabled.
Why it exists
You often want to see a change working before you test it: on your own account, then for a few friendly users. That is a rollout, not a test. The audience is chosen by you, not drawn at random, so comparing it with everyone else tells you nothing about the change. Keeping flags and experiments apart keeps that difference visible. Your code does not change: it reads the same parameter, and the flag changes what it returns.
How it connects
A flag belongs to a space and has one audience, a user list or a predicate, and one variant. For the parameters its variant sets, an enabled flag comes before any experiment. So ABMeter refuses to start an experiment while an enabled flag sets one of its parameters. Enabling such a flag over a running experiment is possible only in the web UI, after a warning you confirm, because it takes the flag's audience out of the test. Flags record exposures too, so you can see how many users a flag reached.
Exposure
An exposure is a record that a user received a parameter value: which user, which parameter, which value, when, and from which experiment or flag. The SDK records it when your code reads the parameter; you do not send exposures yourself.
Why it exists
A user can be assigned to the green group and never reach the checkout page. That user saw no difference, so their behavior says nothing about the button. Counting them would dilute the effect toward zero. So the analysis counts only users who were exposed, from their first exposure on, and compares people who actually saw the difference.
How it connects
Exposures join the two halves of ABMeter: what a user got, and what the user did. An experiment's results count each user from their first exposure, and an attribution window counts their events from that moment on. Define metrics from events that follow the exposure, such as clicks and purchases, not from the visit in which the user was exposed.
Effect
An effect is the comparison of one group against control on one metric: the mean per user in each group, the lift, its 95% confidence interval and the p-value. The effect card shows it in the web UI, and the API and the MCP server return the same numbers. How Results Are Computed explains each number and how to read it.