Segments

Server-calculated segment targeting in Journeys

Nuxie calculates segment membership on the server. The SDK never downloads or evaluates segment definitions.

How segment targeting works

1. You define a segment in the Nuxie dashboard from customer properties, event history, feature access, or other server facts.
2. Nuxie evaluates those rules against the customer’s ingested event stream.
3. A segment-entry trigger starts server Journey work and arms any later on-device work for the next profile delivery.
4. If an armed on-device Journey needs a segment as a state gate, its profile includes only that segment’s opaque membership boolean.

The profile does not contain segment names, rules, dependency graphs, or a general segment catalog. It contains the smallest fact table required by the Journey releases delivered in that response.

Freshness

The SDK synchronizes its canonical profile at app launch and every foreground. That request always revalidates with the server; an unchanged response may use conditional 304 delivery.

Events and identify() updates are captured immediately, but they do not make the SDK evaluate segment rules. A server-calculated membership change becomes available on the next foreground with connectivity. identify() switches to the selected customer’s cached profile without adding a hidden network sync point.

On-device entry gates

An armed Journey may read a delivered membership bit while evaluating its entry condition. Missing facts fail closed, including under negation, so a stale or incomplete profile cannot accidentally admit an experience.

This local check is an execution gate over server-owned state. It is not local segment evaluation, and local events cannot change the bit.

Next steps

• Experiences — configure Journey triggers and targeting
• Segment Builder — define server-side rules
• Tracking Events — send facts used by server evaluation