Roadmap to master real-time segments

Real-time segments are streaming programs that ODP runs across all of your customers, all of the time. These programs can:

When a real-time segment is installed in your account, it immediately starts running across all of your customers, and it keeps running until you uninstall it.

The simplest use for a real-time segment is to personalize an individual's experience on your website. To do this:

Mastery of real-time segments develops through two levels of complexity:

The most foundational component of a real-time segment is the Expression.

An expression is a set of operations that evaluate to some value. For example, customer.observation.lifetime_revenue > 100 evaluates to the boolean value true if ODP calculates that the lifetime value of a customer is greater than 100 (account default currency units).

Expressions are not expressed as strings in this API and are instead expressed as a JSON tree for greater type safety and reduced ambiguity. You would encode the previous expression as follows:

The previous JSON code example declares a top level expression that is the result of comparing the outputs from two nested expressions. The first nested expression (lhs) looks up a value from the customer profile. The second nested expression (rhs) encodes the constant 100.

An expression always takes the json form {expression_type: {expression parameters}}. There are three examples of this previously.

The 13 other ways to encode and combine expressions are all enumerated in the OpenAPI spec and the documentation.

To turn this expression into a complete, real-time segment, you need to wrap it in a condition.

The previous expression lets you build a simple segment because you are only dealing with profile level data (data rooted at customer) so you can use CustomerCondition.

In JSON, this would be as follows:

The previous code example is a complete segment definition that you can send to the public-segments definition API. If you store the previous sample in a file named segment_definition.json, you can install it with the following curl command:

This now flags individuals with their membership in this segment when a GraphQL audience query is performed.

This completes an example attribute-only segment. This is the simplest segment that you can create with real-time segments. You can modify the above example to declare segments from any logical combination of user attributes.

A behavioral segment is a segment that makes decisions using a customer's events as input. An event is a bag of data that describes something the user did.

Example events include the following:

A behavioral segment might be looking for a single trigger event (customer swiped their membership card) or a meaningful sequence of events (customer swiped their membership card and then made a purchase on the same day). Behavioral segments have more complex definitions than attribute-only segments because of the potential for these segments to look for patterns across time.

The heart of a behavioral segment is a SequenceCondition.

A sequence condition is built from a sequence (which is the pattern detector itself) and the number of matches that sequence must observe before the condition is met. Optionally, you may specify a maximum number of matches after which the condition is no longer be met. For example:

The heart of a SequenceCondition is, of course, the Sequence. Sequences match patterns of event data.

When a sequence is active, its entry_event_filter considers every event that follows the time that the sequence was activated (sequences in a root_condition are always active).

If the entry_event_filter finds a matching event, the sequence spawns a partial match. This partial match contributes to the match count immediately if the sequence has no goal. However, if the sequence does have a goal, the goal becomes activated and the partial match completes when the goal completes.

In summary, to match a set of events

Partial and complete matches are immediately removed the moment their disqualifier matches. Disqualifiers are used to represent concepts like timeouts (customer who added to cart in the last 7 days) and invalidating events (customers who added a product to cart and did not remove that product).

The following is a sequence with an entry condition of "blue event". When it detects its entry condition, it creates a partial match with a goal and a disqualifier. When that detector observes a purple event, its goal is met and the match count increases to 1. If the SequenceCondition specified 1 as its minimum number of matches, that sequence condition now matches. Later, when that detector observes another blue event, the match state (the detector) is discarded by its disqualifier but the sequences entry condition also observes the blue event and spawns a new detector.

This contrived example might represent customers who have made reviewed (purple) their most recent purchase (blue).

In pseudocode, the previous animation might be written as the following:

Here Optimizely is using a simple event_filter continuation as our goal and disqualifier. Sequences can also be continuations, which lets goals chain into new sequences, which chain into new goals, and so on. You can also match sequences in parallel with the combination continuation and combine their results logically with AND and OR.

The classic cart abandon gives a great foundation for talking about other continuation types. Cart abandon is usually framed as user did (entry event) A (for example, add to cart) but did not (disqualifier) do B or C (for example, remove from cart or purchase) and this started more than 1 day ago (goal).