Segments

Introduction

Segments are the entry point into Fanplayr's powerful segmentation system. Actions and experiments, and through them widgets and offers, all combine to control the segment's output.

Segment rules are used to place users into different groups based on their browsing behavior and other attributes.

The common verbiage is to say that a user has "fallen into" a segment or that a segment has been "triggered" during a user's session. A user that has fallen into a segment becomes a candidate to experience the actions and experiments defined on the segment. The exact behavior of the segment depends on settings of the segment itself and the actions, offers, and widgets related to the segment.

General Configuration

General

  • Name: The name used to identify the segment including in Insights (required). Names must be unique, and should reflect either the intent of the segment, or a brief description of how it targets.

  • Tag: Used by Segmentation as a Service to identify that a segment has been triggered.

  • Type: Defines the basic behavior of the segment. See below for details.

  • Days to Ignore: Only visible if the segment's type is "Ignore User". Defines the number of days to ignore a user after they fall into this segment (required if visible).

  • Advanced Options: See below for details.

Types

The type of the segment controls overall behavior.

  • Standard: Users that fall into this segment will be targeted and all actions and experiments on the segment will be evaluated.

  • Hide Offers: No widgets that include offers (including the offers previously collected in a persistent widget) will be displayed while a user falls into this segment.

  • Do Not Target: No new offers will be presented while a user continues to fall into this segment. Users will continue to see offers they were previously presented in a persistent widget. No other segments will be evaluated.

  • Ignore User: No offers will be presented to users from any segment for a specified number of days after they first fall into this segment. All segments will still be evaluated.

Advanced Options

Sticky Segment

Users who fall into a sticky segment will continue to fall in it for the duration of their session, regardless of the segment rules.

Types: Do Not Target

Override Do Not Target Segments

If enabled, this segment will take priority over Do Not Target segments and any widgets and offers (via actions) in this segment will be available for presentation. Offers will continue to be hidden if the user falls into Hide Offers segments.

Types: Standard, Ignore User

Rulesets

A segment's rulesets and rules define the conditions in which a user will fall into the segment.

Rulesets are groups of rules. For a user to fall into the segment all rules in at least one ruleset must be considered valid.

There are over 150 different types of rules including the time of day, the number of page views in a session, and the user's browser language.

A segment must have at least one ruleset and each ruleset at least one rule. However, a segment can have as many rulesets and rules as needed.

Targeting Actions

General

A segment's actions define how each segment interacts with users through widgets and offers.

The segment's actions are defined in the Targeting Actions section of the portal, and any number of them can be added to a segment.

If a segment has no actions added to it a user will still fall into this segment, and this can be seen in Insights.

When a segment is triggered, each action will be evaluated individually to determine whether the widget and any potential offers are shown.

There are several special considerations for situations with multiple triggered segment actions, so please view the Segment Action Interaction section for more information. If a segment only has one action there still could be multiple actions triggered if a user falls into multiple segments.

Actions can be added or removed from a segment at any point. Disabled actions cannot be added to a segment, but you can disable an action while it is attached to one or more segments. They will appear in the list of segment actions as disabled.

Additionally, because of the interconnection of items in Fanplayr's segmentation system, errors often propagate through the system. This can cause an item (in this case an action) to be considered disabled even if it is active and within its validity schedule. For example, if we have an action that requires offers but all of the underlying offers are disabled for any reason, then the action itself is considered invalid.

Segment Action Interaction

The system will attempt to run all valid actions on all triggered segments in addition to the actions selected from each of the triggered experiments. However, that does not necessarily mean that each action will be fully realized. There are several limitations to Fanplayr's segmentation system that may prevent the execution of an action. Some of these limitations are listed below. Other limitations could be introduced by specific settings in the segment, action, or campaign.

  • The same widget cannot be shown twice on one page view. A situation in which this arises will be marked as a conflict and all offending actions typically blocked (see Special Action Logic). This also means that the same action cannot be triggered twice in one page view.

  • Only three offers can be presented in one session.

  • If an action is marked as "Triggered on Exit Intent" and the end user has not tried to exit the page, the action will not show.

  • If an action has a delay set and the specified time has not passed, the action will not show.

Special Action Logic

There is plenty of situational logic built into action interaction. For example, as is stated in the list above, the same widget cannot be shown twice (or more) on the same page view. That does not necessarily mean that all actions with the same widget will be blocked. The runtime system has special consideration in this case based on the actions triggered on prior page views. If two actions with the same widget are triggered, the system will attempt to use the action that has not yet been triggered during the session and will mark it the "best" action. If both actions have already been shown on prior page views, the system will choose the one that has been marked "best", which is usually the most recently shown action. However, if both actions are new, the system cannot possibly determine a "best" action to show and will block both actions. This logic is consistent for actions with persistent widgets, as they are considered "triggered" in each page view after they are first shown.

Experiments

General

A segment's experiments allow the user to further customize the actions that are triggered when an end user falls into the segment. A segment can have any amount of experiments. Every experiment on a segment will be triggered when a user falls into the segment.

Take a look at the Experiments documentation to learn more.

Experiments can be added or removed from a segment at any point. Disabled experiments cannot be added to a segment, but experiments can be disabled while attached to segments. They will appear in the list of experiments as disabled.

Similar to actions on a segment, experiments can also be considered invalid due to error propagation. For example, if all of the actions on an experiment are considered invalid due to status, schedule, or cascading error propagation from its own settings, then the experiment is considered invalid and will not be triggered.

Last updated