Time-Based Experiences

A time-based variant is a version of an experience that applies only during a scheduled time period. It lets you prepare campaign or seasonal settings in advance and have them activate and expire on their own, instead of changing an experience by hand at the start and end of every campaign.

Note that a time-based variant is a variant of an experience, and is unrelated to product variants and SKUs.

Typical use cases include:

• campaigns with a fixed start and end date
• seasonal sales and holidays
• product launches that should change the result order from a known moment
• promotions that should hand back to the normal setup automatically

How a period works

Each time-based variant owns exactly one period. A period is a time interval with:

• a required start time
• an optional end time

Leaving out the end time makes the variant open-ended, so it applies from the start time onwards and never expires.

A period always has one of three statuses:

Statuses are calculated from a single clock when the request is handled, so all periods in a segment are evaluated against the same moment. Periods are stored in UTC and shown in the local time zone of the reader, which means colleagues in different time zones see the same interval expressed in their own time.

A period belongs to the variant that owns it and cannot be shared or reused. Two experiences that both run a Christmas campaign each define their own period, even though the dates are identical.

How a variant relates to its experience

A time-based variant belongs to exactly one experience, which is called the base experience. The variant does not replace it, and it does not define its own conditions beyond the schedule:

• The variant carries exactly one condition, which is its period.
• The variant inherits the conditions of the base experience. Its effective conditions are the conditions of the base experience plus the period.
• Changing the conditions of the base experience therefore changes them for every one of its variants.
• The variant holds its own business rules, so it can boost, bury, pin, and facet differently while the period is active.
• The base experience applies whenever none of its variants is active.

This means a variant narrows when an experience applies, not what it matches. Everything the base experience matches, the variant matches too, for the duration of its period.

Time-based variants are managed in Playground. They are not listed in the experience overview or the experience tree, and they are not included when experiences are compared.

How periods affect matching

A period is the highest-priority business rule condition, ranking above targets. See business rule condition priority.

The practical effect is:

• While the period is active, a business rule on the variant is preferred over an otherwise equivalent rule on the base experience.
• While the period is not active, rules that depend on it do not match at all, and the next best rule applies instead. That is usually the equivalent rule on the base experience.

Only currently active periods take part in matching. A search request is never aware of upcoming or expired periods.

Scheduling rules

Two variants of the same experience cannot cover the same moment in time, because it would be undefined which of them applies. A period that overlaps an existing one on the same experience is rejected when it is saved, and an overlap also blocks publication.

Periods that merely touch count as an overlap, so one period must end before the next one starts rather than ending exactly when it starts.

Overlap is only evaluated within one experience. Two different experiences may hold periods that overlap each other, because only one experience is resolved for any given search request.

When to use a time-based variant instead of a target

Use a time-based variant when:

• the change should happen at a known date and time
• the change should end, or hand back to the normal setup, without anyone intervening
• the online store should not have to know that a campaign is running

Use a target when:

• the change depends on who is searching rather than when
• the customer solution decides when the change applies and can send a target id with the request
• you need a split test or another audience-driven variation

Both can be combined. An experience can be resolved by a target, and a time-based variant of that experience can still change the business rules while its period is active.

Publication behavior

Creating, editing, or deleting a time-based variant is a draft change. Search resolves periods from the published configuration, so a variant has no effect on live traffic until the segment is published.

The publication overview lists scheduled variants under Experience Variations, together with their period and status, so it is possible to review what is about to be scheduled. Overlapping periods surface here as a blocking conflict and must be corrected before the segment can be published.

Because publication is what activates a schedule, an upcoming variant should be published before its start time. A published upcoming variant becomes active on its own when the start time is reached, with no further action.

What happens when a period expires

Nothing is removed when a period ends. The variant keeps its configuration and is shown as Expired, its business rules stop matching, and results fall back to the base experience or to another variant whose period is active.

An expired variant can be edited and given a new period, which makes it a convenient starting point for a campaign that runs again next season. Deleting a variant removes its period and the business rules that belong to it.

Next step

To schedule a variant in Playground, follow Time-Based Experiences.