MailInApp
Documentation menu

Spin-to-win block

A gamified promo wheel: a title, a spin gesture, and a single configured reward. It's the studio's lightweight answer to "gamify this promotion" — no prize pool, no odds, no server-side draw, just a satisfying reveal wrapped around a link you already control.

How it works

Spin-to-win is one of the blocks built on the same :checked checkbox-and-label CSS trick as the accordion. A hidden checkbox paired with a <label> acts as a tap target, and a CSS rule keyed to :checked swaps what's visible, with zero JavaScript. Where kinetic CSS is honored, tapping the wheel graphic (🎡) checks the hidden box, which triggers a 0.9-second spin animation (a @keyframes rotation to 720 degrees) and simultaneously reveals a prize panel: a button styled link pointing at your configured prize URL, prefixed with a "🎉" for the reveal moment.

Next to that kinetic layer, mailed HTML also renders a fallback: a plain button-styled link with the same label and destination. Where the wheel can spin (Mail on iOS, iCloud Mail, Thunderbird, Yahoo Mail) a CSS rule keyed to :checked hides this button, so the reader spins and then taps the revealed prize. Everywhere else (every Gmail app, Outlook.com, the Outlook apps, classic Outlook) that rule doesn't apply, the wheel stays hidden and the button shows on its own, so recipients get to the prize without spinning.

There's no randomness anywhere in this block. Every recipient who spins — or every recipient in a client that shows the plain fallback button — lands on the exact same configured link. The "win" is guaranteed by design: the wheel is a presentation device for a single reward you've already decided everyone gets, not a prize-selection mechanism. If you want different recipients to see different offers, that's a matter of building separate versions of the email for separate audience segments (or using merge tags in the prize link itself), not a feature of the block.

When the wheel is spun in an email app that can report it, MailInApp records a reveal, as it does for a scratch-off card, and the block gets a Reveal card in Insights › Blocks. The apps that can report one are listed under Reveals and slide views. Spins in other apps can't be counted, so read that card as a lower bound.

A click on the prize link, if you set one, is recorded in every email app. Both the fallback button and the revealed prize button go through MailInApp's click tracking the same way a button block's link does, so the block shows up in the click heatmap. A click doesn't prove a spin, since the plain button is always there to tap.

Configurable fields:

  • Title — the headline above the wheel, plus its own color and font size.
  • Button label — the text on both the fallback button and the revealed prize button (default "Try your luck").
  • Prize link — where the button/reveal points. Left blank, mailed HTML falls back to the block's own hosted live-view URL instead of a dead link; the live view itself only renders a button at all when this is set (it has no fallback destination of its own to fall back to).
  • Background color, padding, border and border radius on the card.
  • Button text color and button background color — defaults to the project's $accent and $brand theme tokens respectively, so it matches your brand out of the box.

The wheel graphic itself (the conic-gradient circle and the 🎡 emoji) isn't configurable — only the surrounding copy, link and card styling are.

Examples

Subject

You've got a spin waiting

A retailer running a flash sale can drop a spin-to-win block into a promotional send with the prize link pointing straight at a discount-code landing page or a pre-filled cart. See Engagement & loyalty for the broader pattern of using light gamification to lift click-through on an otherwise ordinary promotional email. A loyalty program's "thank you for being a member" send can use it as a one-tap "claim your reward" moment instead of a plain button, since the spin animation reads as more of an event than a static link. Because there's no real randomization, it also works well anywhere you want the perceived fun of a gamified mechanic without actually varying what different recipients receive — e.g. a single sitewide discount code you want everyone to redeem.

What the static fallback looks like

<div id="em-spin-1" style="margin:12px 0;text-align:center;background-color:transparent">
  <p style="margin:0 0 10px;font-weight:700;font-size:18px;color:#111827">
    Spin to win!
  </p>
  <a href="https://acme.example.com/spin-reward"
     style="display:inline-block;padding:10px 20px;background-color:#4f46e5;
            color:#ffffff;border-radius:6px;text-decoration:none;
            font-size:14px;font-weight:600">
    Try your luck
  </a>
  <!-- kinetic wheel + reveal markup omitted — hidden from Outlook;
       where the wheel can spin, a :checked rule hides this button -->
</div>

In a real send, the fallback button's href is MailInApp's click-tracking redirect, which records the click and forwards to the configured prize link. With no prize link set, it links straight to the live view URL instead, untracked. Either way there's no /act confirm step.

Testing two prizes

To find out which of two prizes works better, run an experiment on the email. In the studio's Arm menu, give each arm its own Prize link and Button label. To give each recipient their own store code, set the prize link to the {{discount_url}} merge tag and choose each arm's reward on the experiment's Reward & attribution step.

Two things to keep in mind:

  • Measure clicks and purchases. Spins are recorded only in email apps that can report a reveal, and where the wheel can't spin the prize button shows without one, so a click doesn't prove a spin. The prize link's clicks and the orders that follow are what the results compare.
  • Check each arm's wording yourself. At launch, MailInApp refuses an arm whose email shows another arm's scratch-off prize, but it doesn't read spin-to-win buttons. Preview each arm in the studio before you launch.

Related