Scratch-off block

A scratch-to-reveal prize card, built on the same :checked CSS technique as the accordion and spin-to-win blocks. A hidden checkbox, a tappable label styled as a scratch surface, and a CSS rule swap what's visible the moment it's checked — no JavaScript anywhere.

How it works

Wherever kinetic CSS is honored, the block renders a scratch surface — a <label> styled with a diagonal gray-striped background and a "Scratch here" prompt — layered over the prize. Tapping it checks the linked hidden checkbox, which triggers a CSS rule that hides the scratch surface and reveals the prize underneath, right in the inbox. There's no drag gesture or partial-scratch animation. It's a single tap-to-reveal: the same interaction spin-to-win's wheel and the accordion's expand/collapse both use.

The fallback is what makes this block worth calling out specifically: instead of a separate always-visible control the way spin-to-win and quiz have, scratch-off relies on a "safe default" in the styling itself. The scratch surface's own inline style is display:none; it only becomes visible at all once a <style> rule (scoped to kinetic-capable clients) explicitly forces it to display:block. In Outlook and any other client that doesn't honor that stylesheet, the surface simply never appears, and the prize element (which carries no such hiding style) is visible by default.

Every rule that hides the prize is tied to the scratch itself, so an email app that keeps part of the card's styling but can't run the scratch also shows the prize. So there's no "unscratched" dead end anywhere: a client either shows the scratch gesture (and the prize appears once tapped), or skips the gesture entirely and shows the prize outright. Nobody is ever stuck staring at an un-scratchable card.

Keyboard and screen readers

Where the scratch works, recipients who don't use a mouse or touch screen can scratch too: the Tab key moves to the card, a clear outline in your brand color shows it's selected, and Space reveals the prize. Screen readers announce it as "Scratch to reveal the hidden reward", which describes what the control does without giving the prize away. You don't need to set anything up for this. The preflight checklist tells you if a card ever loses it.

When the card is scratched in an email app that can report it, MailInApp records a reveal, and the block gets a Reveal card in Insights › Blocks (see Measuring reveals). A click on the prize link, if you set one, is recorded in every email app: it goes through MailInApp's click tracking the same way a button block's link does, so the block shows up in the click heatmap.

Configurable fields:

• Title — the headline above the card, plus its own color and font size.
• Prize text — what's revealed underneath the scratch surface (default "🎉 20% off your next order!").
• Prize link (optional) — if set, the revealed prize renders as a real button-styled link to that URL; if left blank, it renders as plain bold text instead, since there's nothing to link to.
• Link placement and button text — with a prize link set, Inside the revealed prize (the default) makes the prize itself the button. Button below the card keeps the prize to its reward text and puts a separate tracked button under the card, labelled with the button text ("Shop the collection" if you leave it empty). That button shows before and after the scratch, and in the fallback.
• Background color, padding, border, border radius on the card.
• Prize text color and prize background color — deliberately have no built-in default the way most color overrides do, because the block renders two visually different prize variants (a white-on-color button when a link is set, dark text with no background when it isn't) and a single hardcoded default would make one of the two variants invisible. Each variant falls back to its own sensible default only when you leave the field empty.

Examples

A retention email can use scratch-off as a lighter-weight alternative to spin-to-win for a single guaranteed discount reveal — see Engagement & loyalty for more on this kind of lightweight gamification. A birthday or anniversary send can reveal a personalized coupon code as the prize text (combine it with a merge tag to personalize the code per recipient, since the prize text itself is just configurable copy). A "we picked a winner" campaign-conclusion email can use it to reveal whether a specific recipient won a giveaway, with the prize link pointing at a claim page.

What the static fallback looks like

<div id="em-scratch-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">
    Scratch to reveal your prize!
  </p>
  <!-- scratch surface (checkbox + label, display:none by default) omitted:
       only shown where a kinetic-tier <style> rule forces it visible -->
  <div class="sc-prize" style="margin-top:10px">
    <a href="https://acme.example.com/claim"
       style="display:inline-block;padding:10px 20px;background-color:#4f46e5;
              color:#ffffff;border-radius:6px;text-decoration:none;
              font-size:14px;font-weight:600">
      🎉 20% off your next order!
    </a>
  </div>
</div>

The prize <div> carries no hiding style of its own, so it's visible unconditionally unless a kinetic-tier stylesheet actively hides it — the reveal gesture is purely additive on top of an already-visible prize. In a real send, the prize link's href is MailInApp's click-tracking redirect, which records the click and forwards to the URL you set.

Measuring a scratch-off

MailInApp records two signals from a scratch-off: a reveal, from email apps that can report one, and a click on the prize link, from every email app. Plan your measurement around clicks and the purchases that follow:

• Set a prize link. Clicks on it go through MailInApp's click tracking, so they show up in the click heatmap. A store link also carries the UTM tags that attribute a Shopify or WooCommerce order to the campaign.
• Decide on clicks and purchases, not reveals. Reveals come only from some email apps, so they can't speak for the whole audience.
• Remember the fallback shows the prize. In email apps without the reveal (Outlook, for one), the prize and its link are visible from the start. Treat everything in the card as visible to everyone.

Measuring reveals

A reveal is recorded when the card is scratched in an email app that can report it. Of the apps we measured, Mail on iPhone and Thunderbird can report a reveal. Gmail and Outlook.com show the prize without the scratch, so there's no reveal to record there. Yahoo runs the scratch, but its image proxy hides the reveal from MailInApp, so it isn't counted. The full table is under Reveals and slide views.

• In Insights › Blocks, the Reveal card counts the people who revealed, as a share of everyone who opened or engaged. People whose email app can't report a reveal are in that base, so the share is a lower bound.
• In an experiment, the Observed reveal rate counts only the emails in apps that can report a reveal, and Reveal coverage shows what share of the delivered emails that was. The Post-reveal click rate depends on who revealed, so it isn't a randomized comparison.
• No recorded reveal isn't a missed prize. A recipient with no recorded reveal may have seen the prize in the fallback, or in an app that can't report it.

Where the link sits

Link placement decides what a click can tell you:

Inside the revealed prize, as mailed (scratch the card to reveal the link):

Button below the card, as mailed:

In an experiment, the placement is chosen once for every arm, under Scratch-off call to action on the Reward & attribution step. It replaces the card's own setting, so every arm is measured the same way.

To find out which of two rewards works better, don't compare two separate sends: run an experiment, as described next.

Testing two rewards in an experiment

An experiment can give each group its own prize (say, free shipping against 10% off), with one email and a different prize per arm. Each arm can also get its own single-use store code, shown in the prize with the {{discount_code}} merge tag, and its results count the purchases each reward brought in. Test which reward sells more with a scratch-off A/B test follows one such test from start to finish.

Each group's email has to show only its own reward. Otherwise the people in one group find out about the other offer, and the test stops being fair. MailInApp checks this for you when you launch: it builds each group's email the way it will be sent and stops the launch if one group's email mentions another group's prize, anywhere in the email or its plain-text version. The message names both groups and the prize, so you know exactly what to reword. A common culprit is shared copy such as a heading saying "Free shipping on every order" in an email where only one group gets free shipping.

A few things this check can't catch, so it's worth a quick look yourself before you launch:

• It matches the prize text as written. "Free shipping" is caught, but "we'll cover delivery" isn't. Reread any copy that describes a reward in other words.
• It looks at scratch-off prizes only. Rewards mentioned in other blocks, images or the subject line aren't compared between groups. Text inside an image can't be read at all.
• A group that uses a different email (a content variant built in another project) isn't checked. Preview that email yourself.
• The preflight checklist checks the email as you saved it, not each group's version. Use the studio's Arm menu to preview each group, and the launch check covers the rest.

Related

• Block reference overview
• Spin-to-win block
• How fallbacks work
• Interactions & analytics