audiences

Audiences: who sees what at a placement

A segment is a set of filters, all of which a user must match. An audience is one entry in a placement: one segment (or none), one paywall or flow, one priority. The placement checks its audiences from the lowest priority up and serves the first one the user matches; the default audience (segment_ids: []) is last and catches everyone else. Every change this skill makes is live for real users the moment the placement is written.

This skill owns segments and audiences. It does not own:

• The paywall or flow itself → flow-generator builds and publishes it. An audience can only point at content that exists, and a flow only once it is published.
• Moving paywall placements to flows → migrate-placements.
• Segments built from Apple Search Ads campaigns, ad groups or keywords → ads-manager, workflow 13 (asa segments create resolves the Apple ids and keeps the dashboard's naming). Come back here to route the segment it returns.
• An attribute the app has to send (custom attributes, age, gender, customer user ID) → adapty-integration owns the SDK call. A segment over an attribute nobody sets matches nobody.
• Starting, stopping or building an A/B test — not in the CLI. The CLI reads the tests on a placement and keeps them (next section). For the rest, send the user to https://adapty.io/docs/add-audience-paywall-ab-test.

A/B tests on a placement: the CLI reads and keeps them

placements get shows an audience that runs an A/B test as an entry of its own kind (CLI 0.11.0 is the first release that does): {"content_type":"ab_test","ab_test_id":…,"ab_test_title":…, "segment_ids":[…],"priority":…}, or "flow_ab_test" on a flow placement. Send it back in --audiences exactly as read (ab_test_title is optional on a write). The audience serves the test's running content, so a test entry is not something you build or edit here.

• A shared test (cross_ab_test, flow_cross_ab_test) runs across several placements and shows read-only. Send each such entry back unchanged and never add, edit or reorder one. The backend counts its priorities and its default audience apart from the regular ones, so both groups can hold priority 0 and a default. You add and reorder only regular audiences.
• A write that only adds a segment audience or only changes priorities is safe. The test keeps running with the same start time, so the table needs no test line.
• A write that changes a test is not, and the table must say so. Three writes do: a running test's audience is replaced by a paywall or flow, or is missing from the list; its audience gets other segments; or the list carries a test id the placement does not run now. In the before/after table, show each test by its title and add one line per test: "test X stops with no winner; Y starts" (a stopped test shows as Completed with no winner), or "test X starts again with a new start time". Then wait for the user's answer, and write only after they confirm that table.
• Read again just before the write. Run placements get once more. If the placement differs from the read the user saw, show the new before/after table and ask again. An unattended run stops there and reports; it does not write.
• Put on an audience only the test id it already carries. The one exception is a test the user names as still a draft, and the table then says "test X starts on ". Never put the id of a test that runs on another audience or placement: the backend would move that test.
• An unattended run may write a placement when the table has no test line. A test line with no answer from the user means no write: give the exact dashboard change instead (which audience, which segment, which paywall or flow, which position), where the test keeps running. Creating the segment through the CLI is still fine.