Scheduled Distributions

A Scheduled Distribution is a second distribution with a start and an end. While its window is open it takes over the model's traffic completely, and when the window closes the model returns to its always-on split on its own.

Reach for one when a creative needs the traffic for a fixed period and then needs to get out of the way: a holiday offer running December 20 to December 27, a launch-week price, a Black Friday Paywall, a regional sale. You set the window once, and there is nothing to switch back afterwards.

A scheduled window is built from Placements running live A/B tests, which makes the window measurable by design: the seasonal creative goes in front of users, and the test behind that Placement tells you whether it beat its control. Inside the window each user is assigned to one Placement and stays there, so a window is a real user-level read rather than a per-request coin flip.

Schedules live on the model's Traffic Control tab. Open AI Pricing Models, open the model, select Traffic Control, and scroll to Scheduled Distributions. For the always-on split, see Traffic Control.

What has to exist first#

A schedule targets Placements, never Paywall IDs, and every Placement it points at has to be eligible as a traffic target. Eligible means the Placement has exactly one audience, that audience is the all-users audience rather than a segment, and that audience is running a live A/B test.

So the setup order is: build the seasonal creative, put it behind a Placement of its own, launch an A/B test on that Placement's all-users audience, then schedule the Placement. See Placements and A/B Tests Overview.

Creating a scheduled distribution#

Open the model's Traffic Control tab, scroll to Scheduled Distributions, and choose Add Schedule.

Pick the Placement. Search for the Placement hosting the seasonal test and select it. Each Placement carries a chip for every routing its audiences use: AI Model, A/B Test, or Paywall. Pick one whose chip reads A/B Test. Choose Continue to Traffic Allocation.
Set the allocation. Set the Placement to 100 with the slider or the number field. The status bar reads Total must equal 100% until the weights add up, then switches to Ready to schedule. Choose Continue to Schedule.
Set the window. Set the Start Date & Time, tick Set end date, then set the End Date & Time. Days already covered by another schedule are grayed out. Choose Confirm Schedule.

The schedule appears in the list with its window, a Scheduled badge, and its own Total: 100%. Confirming saves it, so there is no separate Save Changes step.

For example, a schedule running from 12/20/2026 at 9:00 AM to 12/27/2026 at 11:59 PM leaves the model on its always-on split until 9:00 AM on December 20. From that moment until the end of the window, every request goes to the Placement behind the seasonal creative.

The list is not filtered, and the chip does not say whether the test is live

Eligibility is checked at Confirm Schedule, not when you pick. A Placement that fails is rejected with one of three messages naming the reason: it must have exactly one audience, its audience must be the all-users audience rather than a segment, or its audience must be running a live A/B test.

Nothing is saved when this happens. Fix the Placement or pick a different one and run the dialog again.

A window does not have to be a full takeover. Select more than one Placement in step 1 and give each its own weight, so a window can run 70% on the sale creative and 30% somewhere else. Every Placement has to be eligible on its own, and the weights have to total exactly 100.

What happens when the window opens and closes#

The start time is inclusive and the end time is exclusive. The schedule is serving from the start instant, and the instant the end time arrives it is not.

A running schedule fully replaces the always-on distribution. Nothing is blended, and the always-on weights are ignored for the duration. On screen, the always-on section is retitled Default Distribution and marked Paused, which only means a schedule is currently overriding it.

Reversion is automatic. At the end time, traffic returns to the always-on distribution on the very next request, and the schedule row reads Completed. A completed schedule stays in the list until you delete it.

No background job runs. The active window is worked out per request against the server clock, so a window that has just opened or closed takes effect immediately. The earliest day the date picker accepts is today, so to start a schedule right now, pick today with a time that has already passed.

Who sees what during the window#

While a window is open and the Paywall request carries a profile ID, the split is resolved per user rather than per request. Each profile is hashed into one of the window's Placements and stays there for the whole window, so a user who opens the Paywall twice sees the same Placement both times.

Opening a window draws membership fresh. The hash is seeded on the schedule itself, and each schedule is a distinct distribution, so who lands where inside the window has no relation to who was in which slice under the always-on split. When the window closes, the always-on assignment resumes exactly as it was.

This only matters for split windows. A window giving one Placement 100% sends every user to that Placement, so there is nothing to reshuffle.

Editing a schedule keeps its users; deleting and re-adding does not. Changing a saved schedule's dates or weights in place keeps the same schedule, so membership carries through. Deleting and adding again creates a new one, drawn fresh.
Changing a weight moves the boundary, not the hash. Widen a Placement's share and the users already on it stay while more are added. Narrow it and the users nearest the boundary move off.
The variant a user sees inside the test does not move. Variant assignment is bucketed on the A/B test's own salt, independently of Traffic Control. Relaunching the test is what reshuffles variants.
Requests with no profile ID are drawn per request. With no user to hash, the window's split falls back to a weighted random draw every time, and the A/B test behind the Placement draws randomly too.

Planning the window#

Without an end date, the schedule blocks every later one

Set end date is what makes the window close on its own. Left unticked, the schedule is open-ended, and because an open-ended window covers all time after its start, the calendar then caps every other schedule at the day before it starts.

For a seasonal takeover, always tick it.

Windows may not overlap. Only one scheduled window may cover any given moment, and an overlapping save is rejected. The calendar disables every day another schedule touches, including its final day, so the earliest a next window can start is the day after the previous window's end date. Ending windows at the end of a day keeps that gap to a minute.
Dates and times are your browser's local timezone. They are entered and displayed in whatever timezone your browser is in, with no timezone label on screen, and stored and compared in UTC. A teammate elsewhere reads the same schedule as a different clock time, so agree on whose clock the window is set to.
To end a window early, delete the schedule. There is no pause. Deletion takes effect immediately, with no confirmation prompt, and traffic returns to the always-on distribution on the next request.
The window covers this model's traffic. A takeover reaches users who hit this model's Placement and match its audience, not everyone using your app.

Good to know#

A window's traffic is attributed to the A/B test, not the model. A Paywall served through a scheduled Placement comes back carrying abTestId and abTestName, while aiPricingModelId is left off. The answer is byte for byte what a Placement running that test directly would return. Read how a window performed in the A/B test's own results over the window's dates.
Deleting a Placement removes any allocation pointing at it, including inside a saved schedule, with no warning. That leaves the schedule under 100, and the remaining rows are renormalized at serve time, so both the effective split and each user's slice boundary shift away from the numbers on screen. After any Placement cleanup, reopen Traffic Control and check each schedule still totals 100.
Saving a schedule does not touch the model's own Paywalls or its weight. That write-back happens only when you save the always-on distribution.