Audiences and segments
An audience is built from context dimensions: named signals that targeting rules read when the server picks a variant. Some arrive with the request, and the server works out the rest from who is signed in.
Dimensions sent with the request
Three dimensions are built in and supplied by the caller: device (desktop, mobile or tablet), platform (web, iOS or Android) and locale. A read passes them in its contexts argument.
Sign-in status
The platform sets an authentication-status dimension from the user's token. It has one value, authenticated. A signed-out visitor has no value at all, so no rule can match "signed out", and the default variant is what serves them.
Segments
A segment is a dimension that carries a rule. The rule is evaluated fresh on every request and comes out true or false for the signed-in user. Nothing is stored, so there is no membership list and no member count. Segments can reference other segments, and an anonymous visitor never matches one.
Conditions combine with AND and OR, can be nested, and can test equality, numeric comparison, text matching, list membership and regular expressions.
A profile model as a source
One dimension per project can name a model as its source. It has to be a singleton model owned by your users (the docs say "customer-owned"). The server loads the signed-in user's record of that model into the user namespace for rules to read. That load is privileged, so a profile field hidden from the client by field-level access can still drive targeting.
Defining and releasing
Define dimensions in the console, with the CLI, or with defineContextDimension in your config file. A new or edited dimension is a draft until it is published in a release. Dimensions declared in config are owned by that config: a push creates, updates and prunes them, and leaves the ones made in the console alone.
Read the detail
The targeting guide covers context dimensions and how a read passes them, and segments have a guide of their own.