Personalization: Showing Content to a Specific Audience

A personalization shows one version of your content to everyone in an audience. Visitors outside the audience keep seeing your default content.

Unlike an A/B test, there is no control and no traffic split. You are not trying to find a winner; you already know what this group should see.

Requirements

• Personalization enabled by Pack. Once it is, A/B tests in the sidebar becomes Experiments and Audiences appears.
• @pack/hydrogen 4.0.0 or later on your storefront. Earlier versions do not serve personalizations.
• Your storefront set up for A/B testing, as described in Test Implementation. Personalizations are served and reported through the same wiring, so there is nothing extra to add unless you target signed-in customers (below).

Creating a personalization

1. Go to Experiments in the left sidebar
2. Click New experiment, then choose Personalization
3. Fill in the details:
   • Title — the name you will see in the Experiments list
   • Handle — a unique identifier, filled in from the title
   • Description — what this personalization changes and who it is for
   • Impression trigger — when a visit counts as an exposure: On page load, or On element view for content further down the page
4. Under Targeting, pick the Audience it is for, or click + New audience to build one without leaving the page
5. Under Pages, add the pages it changes, for example Path Equals / for the homepage. Leave it empty to apply on every page (see Limiting a personalization to pages)
6. Click Create

You can save a personalization before it has an audience, but it cannot run without one. Until it has one, the form shows Pick an audience before publishing under the audience picker.

Limiting a personalization to pages

Pages limits where a personalization applies. A visitor sees it only when they are in its audience and on a matching page.

• Conditions use the page's Path, such as / or /collections/sale.
• Every condition must match. To cover several pages, use Contains or Matches regex in one condition, for example Path Matches regex ^/(collections|products)/.
• A condition left empty is removed when you save.
• Changes apply within about a minute of saving, even while the personalization is running.

Limit a personalization to the pages it changes. Without pages it applies everywhere, so visitors in its audience are kept out of A/B tests on pages it never touches (see When a personalization and an A/B test overlap, below). Once its variant changes content, the form warns you while Pages is empty.

The variant

A personalization has exactly one variant, named Personalized. It is what everyone in the audience sees.

To edit its content:

1. On the personalization, open the … menu on the variant and choose View variant in customizer
2. Edit sections and content as you would in test mode

In the Customizer you can also switch to the personalization from the perspective picker at the top: personalizations are listed under Personalizations, and the picker reads Personalization: followed by its name while you are editing it.

Running, pausing and ending

• Run personalization starts showing the variant to the audience. It is available once the personalization has a saved audience.
• Pause personalization stops showing it; everyone in the audience sees your default content again until you run it again.
• To end it, open the … menu on its row in the Experiments list and choose End personalization.

If the variant's content has unpublished changes when you click Run personalization, the personalization does not start. Publish the content, or choose Run anyway to serve what is currently live.

When a personalization and an A/B test overlap

If a personalization and an A/B test overlap for the same visitor, the personalization is shown. A visitor who was already in the A/B test stays assigned to it; the test just does not supply that content while the personalization applies. A visitor who matches the personalization before joining the A/B test is not added to the test.

They overlap when both change the same kind of content, not only the same page: both change pages, both change products, both change site settings, and so on. An edit to a section counts as changing every kind of page content. So a personalization that edits a homepage section overlaps an A/B test on a product page, and keeps visitors in its audience out of that test.

To avoid this, limit each to the pages it changes: the personalization under Pages, and the A/B test with its targeting. Where their pages do not match, both apply.

When two personalizations overlap

A visitor can match more than one personalization, and is placed in every one they match. If two of them change the same kind of content, only one is shown for that content: the one created first. The other still applies to any content the first does not change.

To control which one a visitor sees, limit each to its own pages under Pages, or use audiences that do not overlap.

Reporting

Reporting uses the same reporting source as A/B testing. See BigQuery Integration and GTM & GA4 Integration.

Once a personalization has run, its page shows Exposures: total exposures, unique visitors, and a daily chart of both. It can take up to a day for GA4 events to reach BigQuery.

Personalizations have no goals. Everyone in the audience sees the personalized variant, so there is no control group to compare conversions against, and a conversion rate on its own would not show whether the personalization helped.

To measure its effect, compare visitors who saw it with those who did not in your analytics tool. Pack sends the same experiment exposure event as for A/B tests (see GTM & GA4 Integration), so you can build that comparison from it.

Targeting signed-in customers

Audiences that use the Logged in vs. guest condition need your storefront to tell Pack who is signed in. This condition is for personalizations only; it cannot be used to target an A/B test, because a visitor who signs in or out mid-test would stay in the test after they stop matching and bias its result.

Pass getCustomerContext to createPackClient in server.ts:

const pack = createPackClient({
  // ...your existing options
  testSession,
  getCustomerContext: async () => ({
    isLoggedIn: await customerAccount.isLoggedIn(),
  }),
})

• It is called at most once per request, and only when an audience on that request could depend on the answer. An audience that its other conditions already decide, such as “US and logged in” for a visitor outside the US, does not call it.
• It receives { request }. Keep it a local session check, like customerAccount.isLoggedIn() above, rather than a Customer Account API query: it runs before the page renders. Only add shopifyCustomerId if you need the id itself; it costs that query.
• If the option is missing, throws, or takes longer than customerContextTimeoutMs (300ms by default), Pack treats the visitor's sign-in state as unknown and does not show them personalizations whose audience depends on it. It never assumes a visitor is a guest.