Audience Detection
Beta Feature Liferay DXP 2026.Q3+
Audience detection runs in the visitor’s browser. Liferay DXP adds a bootstrap script to the page that fetches your instance’s audience definitions. The script evaluates each audience’s conditions against values the browser can observe. The matched audiences are stored in a cookie, where element variations and your own JavaScript can read them.
The mechanics behind this process matter most when you are reading audiences from your own code, or working out why an audience is not matching.
Audiences is a beta feature behind the LPD-85746 feature flag. While the flag is off, the Audiences application is hidden and Liferay DXP adds no detection markup to the page.
What Liferay DXP Adds to the Page
Liferay DXP writes the detection markup into the page’s top_head section, but only when the page is rendered in view mode. Detection does not run in the page editor.
The markup is added whether or not any audiences exist. On an instance with none, the definition is empty:
{"audiences":[]}
Liferay DXP also writes a meta tag identifying the page’s element variations bundle, even when the page has no variations. Its content attribute holds the page layout ID, the segments experience ID, and the bundle’s hash, separated by colons:
<meta content="20125:41302:a1b2c3d4" name="audiences-variations">
The script tag carries the definition hash and the log setting as request parameters. It is also marked data-senna-track="permanent", so single page application navigation does not re-execute it:
<script data-senna-track="permanent" id="audiencesBootstrap" src="/o/audiences/bootstrap.(HASH).js?audiencesDefinitionHash=HASH&enableLog=false" type="module"></script>
The Detection Cycle
Detection runs when the page loads and again on each single page application (SPA) navigation. When detection runs, it executes this cycle:
-
Clear the audiences cookie.
-
Fetch the audiences definition and validate it.
-
Evaluate every audience against values the browser can observe.
-
Store the matched audiences in the cookie.
-
Apply the element variations belonging to each matched audience.
When SPA navigation happens in quick succession, several cycles can overlap. Only the most recent cycle applies variations. The cookie holds only the audiences matched on the current page, and on a page with no meta tag it keeps the values from the last page that had one.
The Audiences Definition
The definition is a single JSON document served per instance at /o/audiences/definition.(HASH).json.
Each entry in the audiences array carries an id, a conjunction (i.e., AND / OR) and an array of rules. A rule either compares one attribute (attribute, operator, and value) or nests its own conjunction and rules, which is how condition groups are expressed.
An audience’s id is its external reference code. Everything that refers to an audience uses that code, including element variations and the audiences cookie.
The browser validates the whole document before evaluating anything, and a failure stops the cycle before any variations are applied. Evaluating a rule can fail the same way (e.g., a custom attribute cannot be read). A single failure disables every element variation on the page, including variations unrelated to the rule at fault. See Audience Attributes Reference for available attributes.
Analytics Cloud Segment Membership
Rather than calling Analytics Cloud on every evaluation, the detection layer caches the visitor’s segment codes in sessionStorage under the liferay.audiences.acSegments key, alongside the user ID they were fetched for. Signing in or out invalidates them.
A visitor’s first page view matches no Analytics Cloud segments. The codes are not loaded yet, and detection does not wait for them, so a Segments condition starts matching on a later page view. The cache then lasts the rest of the session, so a visitor who joins a segment mid-session is not picked up until their next one.
Both batch and real-time codes are cached together, so a Segments condition can match either kind of membership. Any failure along this path leaves the visitor with no codes rather than raising an error, so a Segments condition silently fails to match instead of breaking the page.
Audience Precedence
A visitor can match several audiences at once. When more than one of them has a variation on the same element, the oldest audience wins by default. You can override this order for a page experience. In the page editor’s element variations panel, open the Audiences Priority setting and drag the audiences into the order you want.
Liferay DXP stores one ordered list per site and per experience, and that list governs every element in the experience. There is no separate order for an individual element. Audiences you place in the list always outrank audiences you leave out, and the oldest-first default breaks ties among the ones left out.
The Audiences Cookie
Matched audiences are stored in a cookie, so they survive a page load and any script on the site can read them. An empty or unreadable cookie means the visitor matches no audiences.
| Property | Value |
|---|---|
| Name | com.liferay.frontend.js.audiences |
| Path | / |
| Max age | 31536000 seconds (365 days) |
| Value | The matched external reference codes joined with a newline, then URL-encoded |
The cookie holds only external reference codes. It records no identity, no attribute values, and no history of previous pages.
Logging Detection to the Browser Console
Detection is silent by default. To watch it run, enable logging and reload the page.
-
Open the Global Menu (
) and go to Control Panel → Instance Settings → Infrastructure → Frontend Audiences Infrastructure. -
Select Enable Log and click Save.
-
Reload the site page.
Messages are prefixed with @liferay/audiences:, so you can filter the console by that string.
Leave the setting off outside of troubleshooting, since the messages are visible to anyone with the console open.