Audiences: Targeting Visitors in Pack Experiments
An audience is a saved, reusable set of conditions describing who should be included in something. Instead of rebuilding the same targeting on every experiment, you define it once and attach it wherever you need it. An A/B test can optionally target an audience; a personalization always does.
Audiences are evaluated on the server as each page is rendered, so a visitor either matches or does not before the page reaches them.
Audiences come with personalization, which Pack enables for your storefront. Once it is on, Audiences appears in the left sidebar, under Experiments, for storefronts hosted on Oxygen. See Experiments.
Creating an audience
- Go to Audiences in the left sidebar
- Click Create audience
- Give it a name that describes who it matches, such as “Returning mobile visitors” — this is the name you will pick from when targeting a test
- Add conditions (below)
- Click Save
An audience with no conditions matches everyone.
Saving a change to the conditions creates a new version; renaming an audience or editing its description does not. An experiment keeps the version that was current when you attached the audience, whether it is running or still a draft, so editing an audience never changes who an experiment targets. To move a test onto the newest version, open it, click Edit test, click Update to vN on save under Targeting, and click Save A/B test.
The audience page shows its current version and an Experiments card listing the A/B tests and personalizations that use it, with the version each one is pinned to. If any of them are running or paused, saving a change to the conditions asks you to confirm the new version first. Drafts do not trigger the confirmation, but they stay on their pinned version too.
Conditions
Each condition matches one signal about the visitor.
| Condition | Matches on | Values |
|---|---|---|
| Device type | User-Agent | Mobile, tablet, desktop |
| New vs. returning visitor | A rolling session marker Pack sets, falling back to prior-visit cookies | New, returning |
| Country | Visitor's IP location from your host | ISO 3166-1 alpha-2, e.g. US |
| Region / state | Visitor's IP location from your host | ISO 3166-2 subdivision code, e.g. TX — not Texas |
| Traffic source | utm_medium and utm_source, then the referring site | Paid, organic, social, direct, email, referral |
| UTM parameter | A UTM parameter on the current URL | Your own values |
| Cookie | Any cookie by name, on presence or value | Your own values |
| Logged in vs. guest | Whether the visitor has a Shopify customer session | Logged in, Anonymous |
Country and region take a single code or a comma-separated list. Region codes are matched on their own, so pair a region condition with a country condition when you need to be unambiguous.
Traffic source follows GA4's Default Channel Grouping, collapsed to six buckets, with paid taking precedence — a paid click from a social platform is paid, not social. Classification uses a curated subset of GA4's source categories, so edge cases can differ from what GA reports.
The Cookie condition is the escape hatch for anything else — a CDP, marketing or consent cookie your storefront already sets. It supports exists, equals, contains, starts with, ends with, and regex, and can optionally require visitor consent before it matches. With that option on, a visitor who has declined analytics consent does not match. By default a visitor who has not answered a consent banner does, the same way Pack treats them elsewhere.
Logged in vs. guest is for personalizations only, and your storefront has to report who is signed in. See Targeting signed-in customers.
Combining conditions
Conditions sit inside a group, and a group is one of:
- all conditions (AND) — every condition must match
- any condition (OR) — at least one must match
- none of these (NOT) — none may match
Tick Not on a condition to match visitors it does not apply to.
Add a nested group to express something like “mobile and (paid or social)”. Two limits keep audiences evaluable on every request:
- 10 conditions per group
- One level of nesting — a group inside your top-level group, and no deeper
The builder disables Add condition and Add group when you reach either limit and tells you which one you hit.
Targeting an experiment with an audience
For an A/B test:
- Open the test and click Edit test, or create one
- Under Targeting, choose Use a saved audience
- Pick the audience
- Click Save A/B test
A test targets a saved audience or inline rules, never both.
A personalization always uses a saved audience: pick it under Targeting when you create it. You can also limit it to the pages it changes under Pages. See Creating a personalization.
The audience version is pinned when you attach it, so later edits to the audience do not change an experiment, running or draft, until you update the experiment to the newest version.
Duplicating an audience
Open the … menu on any audience, in the list or on the audience itself, and choose Duplicate audience. You get a copy named “… (copy)” with the same conditions, opened ready to edit. The original is untouched.
This is usually the fastest way to build a variant of targeting you already have — for example the same rules for a second country.
How matching works
For Country, Region / state, UTM parameter and Cookie, a condition does not match when the signal it needs is missing.
That matters most for exclusions, and how you build one decides what happens to a visitor whose location is unknown:
- Region / state with the Not in list operator and
CAdoes not match them, because their region is missing rather than known to be different. - Region / state equals
CAwith Not ticked, or inside a none of these group, does match them. The condition fails on the missing region, and Not turns that into a match.
Country works the same way. UTM parameter and Cookie conditions also fail when the parameter or cookie is missing, so ticking Not on them matches every visitor who does not have it.
The other conditions fall back to a default:
- Device type: an unknown device counts as desktop.
- New vs. returning visitor: a visitor with no cookies from an earlier visit counts as new, so cleared cookies and private browsing read as new.
- Traffic source: a visit with no UTM parameters and no referrer counts as direct.
- Logged in vs. guest: a visitor with no customer session counts as anonymous. If the storefront cannot tell, the condition does not match.
Requirements
Audiences are evaluated by the Pack SDK on your storefront, so they depend on
its @pack/hydrogen version:
- Audiences on A/B tests: 3.3.0 or later.
- Region / state targeting: 3.3.1 or later. On earlier versions a region condition matches nobody rather than reporting an error.
- Personalizations, including the Logged in vs. guest condition: 4.0.0 or later.
If a region audience matches no one, check your storefront's SDK version first.