Executive summary
- What: Shopify rebuilt the Rollouts setup experience so a staged change is declared as one of three explicit types: a Launch, an Event, or an Experiment.
- Why: The old flow made you infer behaviour from scattered date, audience, and traffic fields. The new one asks for intent first and adjusts settings to match.
- Who: Plus merchants shipping theme, checkout, or customer account changes in stages, running seasonal storefronts, or testing before committing.
What changed
Rollouts publishes a change set to a slice of traffic instead of the whole store. Three things changed that matter operationally.
The rollout type is now a first class choice rather than an emergent property of your settings. A Launch applies to all eligible visitors and merges permanently. An Event publishes for a defined window and rolls back at the end date. An Experiment splits eligible traffic between control and treatment, defaulting to 50/50 over 90 days.
A single rollout can also carry a theme change and a checkout and accounts configuration change together, where previously those were coordinated by hand across two publishes.
The setup flow also surfaces reach and conflicts inline. You see what share of traffic the rollout reaches once market eligibility is applied, how it divides across versions, and which settings conflict, before you save rather than after you publish.
Why it matters
The practical gain is that the riskiest part of a staged launch, coordinating theme and checkout, is now one atomic unit with one audience. A seasonal storefront needing its own checkout configuration used to require two timed publishes, with a window in between where the two disagreed. As an Event it is one object with one end date and an automatic rollback.
Conflict review matters more than it reads. Most staged launches that go wrong are not undone by a bad theme. They are undone by two rollouts, or a rollout and a live market setting, disagreeing about which configuration wins. Surfacing that during setup moves discovery from production to planning.
The Experiment type also closes a measurement gap. Checkout configuration has been hard to test honestly, because most third party testing tools live in the theme layer and cannot reach checkout. Running the change as a native Experiment against a control gives a defensible read on conversion impact. If you are building a formal testing program on Plus, this is the substrate worth standardising on, and it pairs directly with conversion rate optimization work.
Role-specific impact
- Marketers: Scope a promotional storefront to a date range and traffic percentage without asking a developer to schedule a revert. Experiment reporting gives you a control group, so lift claims survive scrutiny.
- Developers: Bundling theme and checkout configuration in one rollout removes a class of race condition from launch runbooks. Expect less time on rollback scripts and more on the conflict list.
- Store admins: Rollout indicators appear on affected Markets pages, so you can see which markets a pending change touches before it goes live. That makes it far easier to answer why a given market renders differently.
Use-case example
Real-world scenario
A Plus merchant selling into the US, Canada, and the UK wants to test a redesigned product page alongside a checkout configuration that moves the delivery date picker above payment. Previously these were separate publishes and the impact was unattributable. Now it is one Experiment: both changes in a single rollout, 50% of eligible UK traffic in the treatment, over 30 days. At roughly 40,000 UK sessions per month they reach a readable sample in under three weeks, and the live control isolates the change from seasonal trend.
Implementation checklist
- Inventory current rollouts and flag open ended launches that should have been time boxed events.
- Agree which type maps to which situation, so the choice is not made ad hoc at publish time.
- Bundle the theme and checkout configuration of your next staged change into one rollout rather than two.
- Resolve every item on the conflict list before saving. It is not a warning to click past.
- Check traffic allocation against your own analytics. Market eligibility can make real reach far smaller than the percentage you set.
- Fix each Experiment's end date and success metric before launch, and do not read results early.
FAQ
Q: Does an Event delete the work when it ends?
A: No. The changes roll back but the rollout is preserved, and you can apply it permanently later if results justify it.
Q: Can we run an Experiment on checkout without checkout extensibility?
A: The rollout swaps the checkout and accounts configuration, so you need to be on the current checkout for there to be a configuration worth swapping. Merchants on legacy checkout.liquid should treat migration as the prerequisite.
Resources
Need guidance? Talk to Makro.