A prize wheel with a budget you set before it starts

The idea comes up every autumn. Someone suggests a prize wheel for Black Friday: visitors spin, land on 5%, 10% or 15% off, maybe free shipping, and the shop collects e-mail addresses on the way. Then someone else asks the question that usually ends the meeting. How many people will land on 15%? What happens if a link to the wheel ends up on a deal forum? Can a visitor just keep spinning until they win the big one?

Those are the right questions. A wheel is a discount campaign with a game on top, and like any discount it needs a cap. This post is about how to set one up so that you know, before it starts, roughly what it can give away, and so that the answer does not depend on visitors playing fair.

Why the draw has to happen on the server

The simplest way to build a wheel is to decide the result in the browser. The page holds the list of prizes and their chances, spins, picks one and then asks the server for a code. Anyone who opens the browser's developer tools can see the chances, and with a little effort can ask for the code of the prize they want.

In our Spin to Win module the browser never decides anything. When the visitor presses the button, the server draws the prize using the weights you set, issues a personal code if it is a win, and tells the browser which segment to stop on. The wheel only animates to the answer it was given. Every winner gets their own single-use code, generated through the shared Promotions core of the CommerceGears promotion modules, and by default that code only works for the e-mail address or customer account that won it.

There are also checks that make scripting harder: the request must come from a page of your shop, the wheel carries a signed token, there is a hidden honeypot field, and spins are rate limited per IP address and per browser. If Magento's reCAPTCHA v3 module is installed and its keys are set, you can switch on a reCAPTCHA check for spins as well. None of this makes abuse impossible, but it moves the cost of cheating from "open the developer tools" to something most people will not bother with.

Setting the chances and the limits

A wheel has between 2 and 12 segments. Each one has a label, a colour and a prize: percent off, an amount off the basket, free shipping, "no prize, try again", or a code from one of your own cart price rules (it needs "Specific Coupon" with "Use Auto Generation", so each winner gets a new code). Each segment can have a minimum subtotal, so "15% off" can mean "15% off orders over £80".

Chances are set as weights. You type a weight per segment and the admin shows the resulting percentage as you type, so you are not doing the sums in your head. A weight of 0 means the wheel never lands there, which is useful for a prize that only exists as a fallback.

Then come the limits per prize: a maximum number of winners in total and a maximum per day. When a prize has run out, the draw carries on with the remaining segments. Say you are happy to give away 15% off, but only to 50 people a day. You set the 15% segment's daily limit to 50, and on a busy afternoon the 51st winner lands somewhere else.

How often a person may play is set separately: once per e-mail address, once per customer account, once per browser (a signed cookie with no personal data in it), a limit of spins per IP address per day, and "spin again after N days" if you want the same people to come back. Keep the IP limit generous; offices and mobile networks share addresses.

The campaign budget

Per-prize limits stop one prize from running away. The budget caps the whole wheel. You can set a maximum number of prizes, a maximum prize value in your base currency, or both.

Prize value needs an estimate, because "10% off" costs nothing until someone uses it and then depends on the basket. You can enter a value per segment yourself. If you leave it empty, the module estimates it from a typical basket and a typical shipping cost that you enter on the wheel: 10% off is counted as 10% of the typical basket (or of the segment's minimum subtotal when that is higher), and free shipping as the typical shipping cost. These are estimates, not accounting. They are there so the wheel stops at a number you chose, not at a number you find out about in December.

When the budget is used up, you choose what happens: the wheel ends and disappears from the storefront, or everyone gets the fallback prize from then on. The budget, the prize limits and the draw are updated together in one database transaction, so two visitors spinning at the same moment cannot both take the last prize.

What visitors see

The wheel opens as a popup, or a bottom sheet with a smaller wheel on phones. You choose when: after a delay, after scrolling, on exit intent, straight away, or only from a small floating "Spin & win" tab. The basket and checkout are left out unless you allow them. Guests either enter their e-mail address before spinning or only after a win, to receive the code; logged-in customers never type an address. A consent checkbox with your own text is optional, and a ticked consent is stored with the e-mail address.

Winners see their code with a Copy button, the validity (a countdown for codes valid three days or less) and "Apply to basket now", which applies the code straight away or as soon as they add a product. The popup works with the keyboard, traps focus, announces the result to screen readers, and skips the spinning animation for visitors who prefer reduced motion.

The wheel's page in the admin shows a budget bar and, per segment, how often the wheel landed there and how many winners it had today and in total. A Preview button lets you try the wheel on the storefront with the real chances, without creating coupons or using budget.

Limits worth knowing

With "e-mail after a win", a guest who wins must claim the prize within 30 minutes in the same browser session, and an unclaimed prize still counts towards the budget and the prize's limits. Each wheel has one set of texts, so a shop in two languages needs a wheel per store view. Fixed amounts are in the base currency.

And the honest point: a wheel is not the cheapest way to collect e-mail addresses. A plain sign-up form with one fixed welcome code costs less to run and is easier to explain. A wheel earns its place when you want the event to feel like an event and you are comfortable paying for that in discounts, within a budget.

If you also use Exit Intent Offers, it can show the wheel as its offer to visitors who are about to leave, instead of opening it on a timer.

The Spin to Win module page has the full list of settings and more screenshots of the wheel on Luma and Hyvä.