Audiences

A named rule that decides who qualifies, written once and pointed at by any number of lanes across your project.

What an audience is

An audience is a rule with a name. It is not a container — nothing lives inside it and it holds no list of people. It belongs to the project, so several lanes across several placements can point at the same one. The audiences page shows you which: each row names every placement that audience is deciding for.

A lane pairs an audience with a flow: the audience answers who qualifies, the lane answers what they get. How lanes are ordered and matched is covered on the placements page.

When you reach for one

When one placement has to serve different flows to different people. You do not need an audience to ship: until there is one to route by, every placement serves a single flow to everyone.

What a rule looks like

A list of conditions, all of which have to hold. There is no OR and no nesting. You express “any of” by widening a single is one of list, which keeps a rule readable as one sentence instead of a tree.

An audience needs at least one rule — with none it is everyone, which the last lane already covers. It holds at most eight rules, and an is one of list at most twenty values.

Signals

Custom attributes are the one signal your app has to send deliberately. Everything above them the SDK sends on its own; these come from setUserAttributes(), described on the SDK page. A rule on a key your app never sends matches nobody.

App version is compared as a version, not as text. So is at least 1.9.0 includes 1.10.0; compared as text it would not, and the rule would exclude exactly your newest users.

Operators

Six in all — is, is not, is one of, is at least, is at most, is set — but each signal offers only the ones that mean something for it. Platform is three unordered values your app always sends, so it offers the first three and no more: is at least would compare them as text, and is set would match everyone. App version leads with is at least, and is set takes no value — the row reads Any value — and is how you ask whether your app sent the signal at all.

Creating one

New audience on the audiences page opens its own screen. Fill in Name, the Key, an optional What it is, and the rules under Who is in it. The key is minted from the name while you type and stays editable until you save: lowercase words separated by single hyphens, like us-ios.

You can also start from wherever you noticed one was missing. Every audience picker — in a lane's row, and on the create-a-flow screen — offers New audience… at the bottom of the list. It takes you to the same screen and brings you back to what you were doing, with the audience you just wrote already chosen and everything else still filled in.

The key is fixed; the name is not

Once an audience exists its key cannot be changed. Lanes reference it and published releases carry the rules under it, so renaming a key would be creating a different audience — which is what New audience is for. The name above it renames freely.

Editing the rulesbumps the audience's revision, and every lane pointing at it is updated to the new one. Renaming does not: a rename re-judges nobody.

An install keeps the lane it landed in

Once an install has been routed, it stays in that lane even after it stops matching — and attributes move by definition, app version on every update. Without that, an install measured in one lane could arrive in another a week later and take the rest of its events with it.

Archiving

Archive files an audience away. It is refused while any lane still references it: the console disables the button and the server names the placements still pointing at it, so point those somewhere else first. There is no delete: the name is the only thing that lets anyone read a six-month-old result and know who it was about.

Related

Placements are where audiences are put to work, in lanes. Flows are what a lane serves. The SDK is what sends the signals a rule is judged against.