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. Underneath that kinetic layer, mailed HTML also always renders a second, permanently visible control: a plain button-styled link with the same label and destination, CSS-hidden only where the kinetic tier is active. Outlook and any other client that can't honor the :checked rule simply shows that second control instead — recipients never have to "spin" anything to get to the prize, they just tap the button.
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.
Spin-to-win doesn't post anything back to MailInApp when it's tapped — there's no vote, submission, or reveal event recorded anywhere. That means it never appears in the responses dashboard, the CSV export, or the click heatmap (which only tracks plain button/image/social/generic-element links, and spin-to-win's button isn't wired through that mechanism). If you need to know how many people actually engaged with the wheel, put the prize link on a landing page you control and measure it there, or use the click heatmap on a button block instead if you don't need the wheel animation.
Configurable fields:
- Title — the headline above the wheel, plus its own color and font size.
- Button label — the text on both the always-visible 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
$accentand$brandtheme 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,
CSS-hidden everywhere else once this fallback link is visible -->
</div>
The always-present button is a plain <a href> straight to the configured prize link (or the live view URL if none was set) — no /act confirm step, since nothing is being recorded.