Why Your Product Recommendation Email Doesn't Look Like Your Brand (And How to Fix It)

You’ve invested in the recommendation engine. You’ve connected your product catalog, configured your affinity models, and your ESP is pulling the right products for the right people. And then a customer opens your product recommendation email on Gmail, and it looks like every other brand’s email: Arial font, raw white-background product shots, prices in a default weight, and a layout that fractures depending on which client they happen to use. The data is right. The design is broken.

This is the dirty secret of personalized product recommendations in email. The industry has spent a decade optimizing which products to show. Nobody talks about the fact that the rendering layer, the thing the customer actually sees, has barely evolved since 2015. Your brand’s $40,000 typeface gets stripped by Gmail. The product photography your creative team art-directed gets replaced by a raw PDP crop. And the layout your designer pixel-perfected in Figma gets reassembled differently by every email client on the planet.

Here’s the thing: that rendering gap isn’t just an aesthetic problem. It’s a conversion problem. And it has a measurable cost.

The Product Recommendation Email Problem Nobody Names

Every product recommendation email in your program is built on the same architecture: an HTML table containing individual product cards, each pulling a product image, name, price, and CTA from your catalog. The recommendation engine decides what goes in each card. The HTML decides how it looks.

The problem is that HTML email has never been able to deliver what a modern brand needs. Email on Acid’s October 2025 guide confirms that the entire list of truly email-safe fonts is six: Arial, Courier New, Georgia, Times New Roman, Trebuchet, and Verdana. That’s it. If your brand’s typeface isn’t one of those six, it doesn’t render in most email clients. It just gets replaced.

Gmail makes this especially painful. As of their latest rendering behavior, Gmail supports exactly two web fonts: Roboto and Google Sans, both Google’s own. Every other @font-face declaration gets silently stripped. Topol PRO’s Complete Guide for Email Fonts puts it plainly: “Gmail strips out all external font imports, so custom fonts never display. Instead, Gmail defaults to system fonts such as Arial or Times New Roman.”

According to Litmus’s February 2026 Email Client Market Share Report, Gmail holds 23.54% of all email opens. Add Outlook at 5.67% and Yahoo Mail at 2.06%, and roughly a third of your audience (at minimum) sees your product recommendation email in a typeface you never chose. Apple Mail, at 45.51%, is the only major client that reliably renders custom fonts. That means for every subscriber not on an Apple device, your brand typography is gone.

Why HTML Product Cards Can’t Carry Your Brand

The font problem is just the start. HTML product cards have three structural failures that compound on each other, and they affect every product recommendations email you send.

Failure one: typography. As we covered, your brand fonts don’t render in Gmail, Outlook, or Yahoo. They fall back to system defaults. Your product name that was supposed to be in your custom serif? It’s in Arial. Your price that was supposed to be in a specific weight and size? It’s in whatever the email client decides.

Failure two: product photography. Most product recommendation engines pull the default PDP image from your catalog. That’s typically a flat-lit, white-background studio shot cropped to the product’s bounding box. It’s not the lifestyle photography your brand team produced for the campaign. It’s not art-directed. It’s just a product on white, which is exactly what every competitor’s email looks like too.

Failure three: layout control. HTML email rendering is not like web rendering. Different clients interpret padding, margins, and table structures differently. A product grid that looks clean in Apple Mail might stack awkwardly in Outlook or overflow its container in Yahoo. Your designer doesn’t get a single canonical layout. They get a range of “close enough” approximations, and they have no control over which version any given subscriber sees.

As Litmus notes in their eCommerce personalization guide: “Balance personalization with brand consistency: your emails should always feel on-brand, even when content is dynamically tailored.” Good advice. But the technical reality of HTML email makes it almost impossible to follow.

What Customers Actually See

Put yourself in your subscriber’s inbox. They get a product recommendation email from your brand. The header is on-brand (it’s a static image, after all). The hero section looks good. Then they scroll to the product grid, and the visual language shifts. The fonts change. The product images are flat-lit and generic. The price and review treatments look like default HTML. The spacing varies by client.

What the customer experiences is a visual break. The top of the email feels like the brand. The product section feels like a database query result. It’s the email equivalent of walking from a beautifully designed storefront into a fluorescent-lit warehouse. The products might be the same. The experience is not.

And this matters to the brand team, who spend enormous effort creating a consistent visual identity across every other channel. Your website, your social, your packaging, your retail displays: all pixel-perfect. Then the email channel, which touches more customers more frequently than any of those, renders product recommendations in Arial on a white background.

What an On-Brand Product Recommendation Email Looks Like

The fix isn’t better HTML. It’s getting product recommendations out of HTML entirely and into image-based rendering. Instead of assembling a product card from HTML elements (text nodes, img tags, styled divs), you compose the entire product grid as a single image per recipient, rendered at the moment of open.

That image contains your brand fonts (because they’re rendered server-side, not by the email client). It contains art-directed product photography, or AI-extended backgrounds that match your campaign’s visual language. It contains custom price treatments, review star designs, and layout spacing that your designer controlled. And it renders identically in Gmail, Outlook, Apple Mail, and every other client, because email clients all render images the same way.

This is what Zembula calls the image-based product grid. It’s a single image URL serving the entire recommendation block, with live price, inventory, and review data pulled at open time. The recommendation engine doesn’t change. The rendering layer does.

The result is a product recommendation email where the personalization section looks like it belongs to the same brand as the rest of the email. No font fallbacks. No layout drift. No raw PDP crops. Your creative director gets their veto back, and the email channel finally matches the visual standard of every other touchpoint.

The Performance Case for Brand Fidelity in Your Product Recommendation Email

Brand fidelity isn’t just a design preference. It’s a conversion variable. When the exact same personalization logic (same products, same data, same recipient) is rendered as an on-brand image block instead of an HTML product card, it drives 5-7% more conversions. The lift isn’t from better targeting. It’s from brand fidelity.

That number might sound modest until you run it through your program’s economics. If your product recommendations email block generates $200,000 per month in attributed revenue, a 5-7% lift is $10,000-$14,000 in incremental monthly revenue. Same products. Same recipients. Same recommendation logic. The only variable that changed is how it looked.

For teams also managing paid acquisition, the contrast is stark. Average ecommerce ROAS fell to 2.87 in 2025, down across 13 of 14 industries (per Upcounting), with Meta CPMs up 20% YoY and Google CPCs up 12.88% YoY. Meanwhile, email operates on an owned audience with first-party identity, zero marginal distribution cost, and privacy-durable measurement. A 5-7% lift on an email block doesn’t require more spend. It just requires fixing the rendering. For a deeper look at how email stacks up as a performance channel, check our 2025 email performance benchmark report.

Zembula’s block-level CTC attribution makes this measurable at the individual content block level, not just the campaign level. You can see exactly how much revenue the on-brand product grid generates versus the HTML version, on the same send, to the same audience. That’s the kind of measurement rigor that performance marketing teams expect, applied to email.

How to Fix It in Six Weeks

Replacing HTML product cards with image-based product grids doesn’t require rebuilding your ESP stack or migrating to a new platform. Here’s the practical path:

Weeks 1-2: Brand asset setup. Upload your brand fonts, define your color palette, and establish your product card template (price treatment, review star design, CTA styling). This is the creative brief translated into a rendering template. Your design team leads this.

Weeks 3-4: Data connection. Connect your product catalog and recommendation engine. Zembula’s Smart Banners and Smart Blocks pull live data at open time, including price, inventory status, and reviews. Your CRM or data team handles the integration, which typically connects via the same product feeds your ESP already uses.

Weeks 5-6: Template replacement and testing. Swap the HTML product card block in your email templates with the image-based product grid URL. Test across clients (it should render identically everywhere, that’s the point). Run an A/B test against the old HTML version to measure the lift. Your modular email architecture makes this a block-level swap, not a full template rebuild.

The key here is that the recommendation engine stays the same. You’re not changing what gets recommended. You’re changing how it’s rendered. That means no disruption to your data science team’s models, no retraining, no new integrations with your CDP.

What This Means for Your Design, Data, and CRM Teams

For design and creative teams: you get control back. The product recommendation section of your emails can finally match the visual standards you hold everywhere else. Your fonts render. Your photography is art-directed. Your layout is pixel-perfect across clients. The brand narrative across every content block reads as one story, not a story with a generic middle chapter.

For data and CRM teams: nothing changes on your side. The recommendation engine, catalog feeds, and personalization logic all stay the same. You keep optimizing the models. The rendering layer just got upgraded underneath.

For marketing leadership: you now have block-level attribution on your product recommendation email content, measured the same way you measure paid ad performance. Revenue per mille (RPM), click-to-conversion (CTC), and incremental lift, all at the content block level, not just the campaign level. That’s the data you need to make the case that email deserves a larger share of the performance marketing budget.

Key Takeaways

• The product recommendation email problem isn’t data, it’s design. Most recommendation engines are already good enough. The conversion ceiling is set by how recommendations render, not what gets recommended.
• HTML email structurally cannot deliver brand fidelity. Gmail, Outlook, and Yahoo strip custom fonts. That’s 30%+ of opens seeing your brand in Arial or Times New Roman, per Litmus’s 2026 market share data.
• Raw PDP images and default layouts erode brand trust. The product section of your email looks like a different brand than the rest of it. Customers notice.
• Image-based rendering fixes all three problems at once. Brand fonts, art-directed photography, and pixel-perfect layout, all composed server-side and rendered identically everywhere.
• The lift is measurable: 5-7% more conversions on identical personalization logic. Same products, same recipients, same recommendation engine. The only variable is rendering.
• You can fix this in six weeks without changing your ESP or recommendation engine. It’s a rendering layer upgrade, not a platform migration.