Gmail’s new Deal Cards are auto-generated summaries that surface your offer (code, expiry, CTA) in the Promotions tab using schema.org-based email markup (e.g., DiscountOffer). Visibility depends on Gmail’s quality filters, device, and a gradual region/language rollout, but properly marked-up promos earn prime, app-like inbox real estate. (Google for Developers)
Why This Matters Now (and to Whom)
1) The list view is the battleground
Most recipients triage in the inbox, not inside your message. Subject + preheader alone often isn’t enough. Gmail has spent years enriching the Promotions experience so marketers can show deals, expirations, promo codes, and images directly in the list view. Deal Cards are the latest (and most action-oriented) extension of that direction. (Google for Developers)
2) Promotions ≠ “the penalty box”
Seasoned email pros increasingly frame Promotions as intent-rich: people open it when they’re hunting bargains. Annotations (and now Deal Cards) give you extra pixels and tap-targets to win that intent. Avoid fighting to land in Primary; lean into Promotions with rich annotations that stand out. (Litmus)
3) Structured, machine-readable email is being rewarded
Google’s docs explicitly tell marketers to annotate deals and images via JSON-LD/Microdata with schema.org vocabularies—because Gmail can transform that data into badges, images, and Deal Cards. That means your markup is a product input, not a nice-to-have. (Google for Developers)
What Exactly Is a Deal Card?
Deal Cards are Gmail-generated, rich previews that can appear in the Promotions tab list view (and sometimes inside the message). They are powered by the structured data you include—especially DiscountOffer—and can expose the offer description, coupon code, and expiry, plus actionable buttons/links and (when approved) imagery via PromotionCard. Display depends on internal quality filters and frequency limits, so they won’t show for every recipient or every send. (Google for Developers)
Closely related features you can (and should) combine:
- Deal Annotation (badge): A compact badge next to the subject line highlighting offer details/codes/expiry—also driven by
DiscountOffer. (Google for Developers) - Single Image Preview & Product Carousel: Visual previews based on
PromotionCard, with strict aspect-ratio guidance and up to 10 images in a carousel (all the same ratio; unique URLs). (Google for Developers)
Key constraint: These experiences are designed for Promotions; they generally won’t appear if Gmail classifies the message to Primary/Social. (Google Help)
The Strategic Upside in 2025
- Earlier conversion moment: Deal Cards pull code + expiry + CTA into the list view, compressing the journey from inbox to action. (Google for Developers)
- Differentiation by data quality: Gmail’s renderer decides if/when to show these; clean markup, good reputation, and accurate dates improve odds. (Google for Developers)
- Inbox is getting more app-like: Google continues to encourage rich previews and Promotions tooling (plus a first-party preview tool). The trajectory is toward richer inbox interactivity—not away from it. (Google for Developers)
- Institutionalize it: Once design/dev add the JSON-LD blocks to your base templates, Deal Cards become repeatable—like subject lines or UTMs. (Most ESP drag-and-drop builders can’t do this in their WYSIWYG; you need HTML access.) (Klaviyo Help Center)
Implementation: A Step-by-Step Technical Guide
1) Pre-reqs & Deliverability Hygiene
- Authenticate: Ensure SPF, DKIM, DMARC are correctly set; poor reputation suppresses annotations. Gmail’s dev pages position quality and filters as gating factors for visibility. (Google for Developers)
- Promotions placement: Craft content that Gmail will classify as Promotions; annotations are meant for that surface. (Google Help)
- Template control: Use a custom HTML template (or your ESP’s HTML editor) so you can add
<script type="application/ld+json">in the<head>. Drag-and-drop editors often strip scripts or head access. (Klaviyo Help Center)
2) Minimum Viable Deal Card (JSON-LD)
Paste into the email’s <head>:
<script type="application/ld+json">
[
{
"@context": "http://schema.org/",
"@type": "DiscountOffer",
"description": "30% off all outerwear",
"discountCode": "WINTER30",
"availabilityStarts": "2025-11-01T00:00:00-06:00",
"availabilityEnds": "2025-11-15T23:59:59-06:00",
"offerPageUrl": "https://www.brand.com/winter-sale",
"merchantHomepageUrl": "https://www.brand.com"
}
]
</script>
Google’s Email promotions reference confirms DiscountOffer as the core for deal/offer previews (badge and card), including description, code, and expiry fields. Use ISO-8601 timestamps and correct time zones. (Google for Developers)
Pro tip: Keep
descriptionlaser-short; Deal Cards are glanceable. Reflect exactly what’s on your landing page to avoid trust erosion. (Google for Developers)
3) Add Visuals with PromotionCard (Single Image or Carousel)
For visual impact in the list view, add PromotionCard objects. Ratios and per-image constraints matter.
Single-image preview (1.91:1 recommended):
<script type="application/ld+json">
[{
"@context": "http://schema.org/",
"@type": "PromotionCard",
"image": "https://cdn.brand.com/promo/outerwear-hero.jpg",
"url": "https://www.brand.com/winter-sale",
"headline": "Outerwear Event",
"price": "129",
"priceCurrency": "USD"
}]
</script>
Carousel (each card same ratio; up to 10):
<script type="application/ld+json">
[
{
"@context": "http://schema.org/",
"@type": "PromotionCard",
"image": "https://cdn.brand.com/promo/coat1.jpg",
"url": "https://www.brand.com/p/coat1",
"headline": "Wool Trench",
"price": "199",
"priceCurrency": "USD",
"discountValue": "40",
"position": "1"
},
{
"@context": "http://schema.org/",
"@type": "PromotionCard",
"image": "https://cdn.brand.com/promo/coat2.jpg",
"url": "https://www.brand.com/p/coat2",
"headline": "Down Parka",
"price": "249",
"priceCurrency": "USD",
"discountValue": "50",
"position": "2"
}
]
</script>
Google’s overview and reference pages specify supported properties, aspect ratios, and usage patterns; keep unique URLs per card and identical aspect ratios across a carousel. (Google for Developers)
Allowlisting: For certain image-heavy previews and carousels, brands often need approval from Google’s Promo Outreach team (p-Promo-Outreach@google.com). Plan ahead—especially for holidays. (Google for Developers)
4) Validate with Google’s Preview Tool
Use Google’s Preview your annotations to catch syntax errors, image quality issues, unsupported ratios/sizes, and URL problems, and to see an approximation of how the card may render in the Promotions tab. (Google for Developers)
5) Launch & Monitor (A/B rigor)
- Seed tests: Gmail accounts across Android, iOS, and desktop; capture list-view screenshots (some visibility is mobile-first). (Braze)
- A/B: Run a clean split: Variant A has markup; Variant B identical but no markup. Same subject, preheader, body, list, send time.
- Measure: Open rate (OR), click-through (CTR), conversion (CVR), revenue per recipient (RPR), and time-to-click. Because Gmail doesn’t expose “card shown” telemetry, infer via lift against control. (Google for Developers)
Best-Practice Playbook (from Brief to QA to Post-Mortem)
Brief & Offer Design
- Pick one clear offer (e.g., “30% off sitewide” or “Free shipping over $75”).
- Include an explicit code and a hard expiry with timezone clarity (ISO-8601).
- Write a crisp
description(under ~80 chars) that reads well in a card. - Ensure the landing page uses the same code, terms, and expiry (no gotchas). (Google for Developers)
Build & Validation
- Edit the email’s
<head>; add the JSON-LD<script>block. - Validate in Google’s Preview tool; fix aspect ratios (1.91:1 for single; 4:5, 1:1, or 1.91:1 for carousel), image format (JPG/PNG), HTTPS URLs. (Google for Developers)
- If needed, start allowlist conversations 1–2 weeks pre-launch. (Google for Developers)
Deliverability Guardrails
- Maintain SPF/DKIM/DMARC and a calm cadence; keep spam complaints low; clean hard bounces. Visibility is gated by quality filters. (Google for Developers)
QA & Send
- Verify Promotions placement on live seeds; annotations only appear when Gmail classifies as Promotions. (Google Help)
- Send to a Gmail-heavy pilot segment; expand if KPI thresholds are met.
Post-Mortem & Scale
- Document uplift vs control: ΔOR, ΔCTR, ΔCVR, ΔRPR, and median time-to-click.
- Bank winners into template partials: Turn your best
DiscountOfferandPromotionCardpatterns into modular, re-usable snippets.
30+ Copy-Ready Use-Case Patterns (with Snippets)
Each pattern includes a suggested
DiscountOffer(and optionalPromotionCard) you can paste into your email’s<head>. Replace times, URLs, and labels. Keep descriptions tight.
1) 48-Hour Flash (code + expiry forward)
Why it works: Urgency performs best when the end time is visible at a glance.
<script type="application/ld+json">
[{
"@context":"http://schema.org/",
"@type":"DiscountOffer",
"description":"FLASH40 – 40% off, 48 hours",
"discountCode":"FLASH40",
"availabilityStarts":"2025-11-21T00:00:00-06:00",
"availabilityEnds":"2025-11-22T23:59:59-06:00",
"offerPageUrl":"https://brand.com/flash"
}]
</script>
Add a single PromotionCard hero (1.91:1) if allowlisted. (Google for Developers)
2) VIP Early Access (members only)
<script type="application/ld+json">
[{
"@context":"http://schema.org/",
"@type":"DiscountOffer",
"description":"VIP25: 25% off new collection – early access",
"discountCode":"VIP25",
"availabilityStarts":"2025-10-22T00:00:00-05:00",
"availabilityEnds":"2025-10-29T23:59:59-05:00",
"offerPageUrl":"https://brand.com/vip"
}]
</script>
Segment strictly; mirror “members only” on the landing page. (Google for Developers)
3) Threshold Perk (free shipping > $75)
<script type="application/ld+json">
[{
"@context":"http://schema.org/",
"@type":"DiscountOffer",
"description":"Free shipping on orders > $75 – ends Sun",
"discountCode":"FREESHIP75",
"availabilityEnds":"2025-10-26T23:59:59-05:00",
"offerPageUrl":"https://brand.com/freeship"
}]
</script>
Make the threshold obvious above the fold in the email body, too. (Google for Developers)
4) Seasonal Retail (BFCM)
Pair DiscountOffer with a carousel of doorbusters. Use consistent ratios and unique URLs per card. (Google for Developers)
5) Subscription First-Cycle Discount
<script type="application/ld+json">
[{
"@context":"http://schema.org/",
"@type":"DiscountOffer",
"description":"3 months for $49 – code SNACK49",
"discountCode":"SNACK49",
"availabilityEnds":"2025-10-31T23:59:59-05:00",
"offerPageUrl":"https://snackjoy.com/signup"
}]
</script>
Mobile-first email body; code repeated top-of-email for redundancy. (Google for Developers)
6) DTC “Drop” with Scarcity
Use description like “Limited drop: 24h only – code DROP24”; add a hero PromotionCard. (Google for Developers)
7) Travel Mid-Week Sale
“$100 off weekend stays – code GETAWAY100 – ends Mon 11:59pm”; CTA straight to filtered dates.
8) Marketplace Seller Fee Promo
Short window; code + end date; segment by seller tier.
9) B2B SaaS Annual Plan
“20% off annual — code Q4SAVE20 — ends Dec 31”; CTA → pricing with pre-selected annual toggle.
10) Fintech Card Category Boost
“5% back dining, this weekend only — code DINE5”; single image of card if approved.
…and 20 more you can adapt: Free gift with purchase; Refer-a-friend bonus; Education discount; Donor match window; App renewal promo; Utility autopay incentive; Early-bird event pricing; Ticket presales; Restaurant week; Gym intro offer; Beauty subscription add-on; Book launch price drop; Pet care bundle; Home services seasonal tune-up; Insurance multi-policy discount; Pharmacy seasonal vaccine coupon; Grocery curbside incentive; Electronics extended warranty; Course cohort early enrollment; Hotel “3rd-night free.”
For each, keep the description blunt, include code/expiry, and align the landing page copy with the Deal Card promise. Validate with Google’s preview tool. (Google for Developers)
Troubleshooting Matrix
| Symptom | Likely Cause | Fix |
|---|---|---|
| No Deal Card or badge appears | Quality filters, frequency limits, sender reputation, or message not in Promotions | Improve deliverability hygiene; reduce annotation overuse; confirm Promotions placement on seeds; expect non-deterministic display. (Google for Developers) |
| Preview shows fine; inbox shows nothing | ESP stripped <script> or header; JSON-LD errors | Switch to custom HTML; validate with Google’s Preview tool; lint JSON. (Klaviyo Help Center) |
| Images look cropped/soft | Wrong aspect ratio/size | Follow ratios (1.91:1 single; 4:5/1:1/1.91:1 carousel) and quality guidelines. (Google for Developers) |
| Carousel shows only one tile | Mixed ratios or duplicate image URLs | Standardize ratio and ensure unique URLs across all cards. (Google for Developers) |
| Images never appear | Not allowlisted for image-forward experiences | Contact p-Promo-Outreach@google.com with sender/domain/template details. (Google for Developers) |
| Performance unclear | No control group; too many confounders | Run true A/B with identical content except markup; isolate lift. (Google for Developers) |
Measurement & Analytics (Proving Value Without Native “Card” Metrics)
Gmail doesn’t expose “card-rendered” or “card-clicked” directly. Treat visibility as a latent variable identified by incremental lift.
Core KPIs
- Open Rate (OR) — higher when the list view is more informative/visual.
- Click-Through Rate (CTR) — Deal Cards reduce friction to click.
- Conversion Rate (CVR) — down-funnel validation.
- Revenue per Recipient (RPR) — commercial impact.
- Time-to-Click — median minutes from send; faster = less friction.
- Gmail Share Differential — compare results for Gmail vs non-Gmail cohorts.
Experimental Design
- Holdout control: Same audience/time; no markup.
- Offer parity: Same subject, preheader, body, landing page, code.
- Powering: Pre-size to detect +10–20% relative lift in OR/CTR.
- UTMs: Use distinct
utm_content=dealcardto separate landing performance. - Geo/Device cuts: Because rollout and behavior vary by region and device, compare mobile Gmail vs desktop, US vs EU, etc. (Google for Developers)
Vendor and practitioner guides consistently show double-digit lifts when annotations are coded correctly—tempered by the fact that display isn’t guaranteed. (Email on Acid)
Governance: Keep the Inbox Promise
Because the preview is a promise, keep your data clean:
- Exact Match:
description, code, and expiry must match the landing page and body. (Google for Developers) - Timezone Honesty: Use ISO-8601 and display the same zone everywhere. (Google for Developers)
- Legal/T&Cs: Put material terms in the email body and landing page; Deal Cards are a teaser, not a contract.
- Change Control: If you extend a sale, update both markup and page.
Advanced Builds: Mixed Objects in One Script
You can include an array of objects (e.g., brand logo via Organization, your DiscountOffer, and one or more PromotionCards) in a single <script> block—commonly documented by ESPs that support head-level editing. Keep JSON strict and URLs HTTPS. (Google for Developers)
<script type="application/ld+json">
[
{
"@context":"http://schema.org/",
"@type":"Organization",
"logo":"https://cdn.brand.com/logo-96.png"
},
{
"@context":"http://schema.org/",
"@type":"DiscountOffer",
"description":"BOGO free – code BOGO",
"discountCode":"BOGO",
"availabilityEnds":"2025-12-31T23:59:59-05:00",
"offerPageUrl":"https://brand.com/bogo"
},
{
"@context":"http://schema.org/",
"@type":"PromotionCard",
"image":"https://cdn.brand.com/promo/hero1.jpg",
"url":"https://brand.com/bogo"
}
]
</script>
Reference docs enumerate these objects and properties for Promotions annotations. (Google for Developers)
Rollout Realities, Myths, and the Bigger Trend
- Gradual & variable by region/language: Expect uneven visibility; track by geo and device. (Google for Developers)
- Promotions keeps maturing: Google continues to improve discovery and relevance for deals. The push for rich previews is long-standing (remember the grid-view experiments?), and Deal Cards fit that arc. (Google for Developers)
- ESP ecosystem: Braze, Klaviyo, and others offer helpers or caveats (e.g., “use HTML editor, not drag-and-drop”; “mobile Gmail shows more consistently”). These pages are great sanity checks while building. (Braze)
- Automatic extraction: Some industry write-ups claim Gmail can infer deals/images even without explicit code, but Google’s guidance still recommends explicit annotations to control what’s rendered. Use markup to guarantee fidelity. (Stripo.email)
Case Studies (Hypothetical, Methodologically Sound)
Case 1: Apparel — TrendThreads (Holiday Outerwear)
- Audience: 60% Gmail.
- Offer: “35% off outerwear — code WINTER35,” Nov 1–10 (local).
- Build:
DiscountOffer+ optional singlePromotionCard. - Test: 50/50 split among Gmail recipients; identical everything but the markup.
Results (illustrative):
- OR +28%, CTR +41%, CVR +38%, RPR +37% vs control.
- Takeaway: Short windows benefit most from code + expiry visible up front; friction crushed.
Case 2: Subscription — SnackJoy (New Subscriber Promo)
- Audience: 70% Gmail.
- Offer: “3-month box $49 — code SNACK49 (ends Oct 31).”
- Build: Only
DiscountOffer(allowlist pending), then add imagery later.
Results (illustrative):
- OR +17%, CTR +25%, CPA −16% vs historical baseline.
- Takeaway: Even text-only Deal Cards drive lift; images are additive.
Practitioner docs emphasize testing + preview limitations—so rely on A/B as your truth source. (Google for Developers)
Frequently Asked Questions (Grounded in Docs)
Q1: Do I need both a Deal badge and a Deal Card?
A: No. Both experiences pull from DiscountOffer. Gmail chooses what to render (badge vs richer card). Add PromotionCard for visuals if eligible. (Google for Developers)
Q2: Are images required?
A: No. Deal Cards can show code/expiry/CTA without images. Images help, but may require allowlisting and strict ratio adherence. (Google for Developers)
Q3: Why can’t I preview this in my ESP?
A: Most ESPs can’t emulate Gmail’s renderer. Use Google’s official Preview tool to validate syntax and assets. (Google for Developers)
Q4: Will this work outside Gmail?
A: These Promotions annotations (and Deal Cards) are Gmail-specific. Other clients won’t honor them consistently (if at all). (Google for Developers)
Q5: Does Primary placement help or hurt?
A: For Deal Cards, you want Promotions; that’s where annotations and rich list-view UI live—and where shoppers browse. (Litmus)
Q6: What exactly are the required properties?
A: See Google’s reference for DiscountOffer (e.g., description, discountCode, availabilityEnds) and PromotionCard fields/ratios. Follow those precisely. (Google for Developers)
End-to-End Checklist (Use This Before Every Send)
- Offer clarity: One headline offer, explicit code, hard expiry (ISO-8601). (Google for Developers)
- Template access: You can edit the
<head>; no drag-and-drop. (Klaviyo Help Center) - Markup: Insert
DiscountOffer; optionally addPromotionCard(s) with correct ratios. (Google for Developers) - Validation: Run Google’s Preview; address errors and warnings. (Google for Developers)
- Deliverability: SPF/DKIM/DMARC healthy; reputation stable. (Google for Developers)
- Seeds: Confirm Promotions classification on Gmail Android/iOS/desktop. (Google Help)
- A/B: Split Gmail audience 50/50; hold everything else constant. (Google for Developers)
- KPI lens: Track OR/CTR/CVR/RPR + time-to-click; slice by geo/device.
- Documentation: Screenshot renders; memorialize uplift; templatize winners.
- Scale: Move Deal Cards from “pilot” to default for high-value promos.
Appendix: Useful, Trustworthy Resources
- Annotate emails in the Promotions tab (overview & allowlisting contact): Google for Developers. (Google for Developers)
- Promotions reference (objects/fields/ratios): Google for Developers. (Google for Developers)
- Preview Your Annotations tool: Google for Developers. (Google for Developers)
- “Gmail Promotions setup” (Braze helper + card builder): Braze docs. (Braze)
- “How to utilize Gmail Promotions Tab” (Litmus, 2025 update): Litmus blog. (Litmus)
- Schema in Gmail (principles and examples): Email on Acid. (Email on Acid)
- Troubleshooting/FAQ: Google for Developers. (Google for Developers)
Bottom Line
If a meaningful share of your list uses Gmail, Deal Cards should be a first-class element in your promo builds—alongside subject lines and hero images. Add the markup, validate with Google’s tool, run A/B tests, and templatize what works. That’s how a few lines of JSON-LD become durable inbox differentiation—and turn the Promotions tab into a high-intent conversion surface. (Google for Developers)
Author’s Note on Coverage & Evidence
This guide relies primarily on Google’s official Gmail Promotions documentation (overview, reference, preview tool, troubleshooting) and current 2024–2025 vendor resources (Klaviyo, Braze, Litmus) that reflect how annotations and Deal Cards behave in production, including editor constraints and allowlisting norms. Where industry commentary diverges (e.g., claims about automatic extraction), the conservative recommendation remains: implement explicit annotations to control what Gmail renders and to maximize your chance of showing a Deal Card. (Google for Developers)
(All web citations above refer to the most relevant sections at the time of writing, October 20, 2025.)
0 Comments