Re: How Reliable is the Marketo Email Preview?

nhabischWings · ‎06-07-2023

Long story short we're revising our branding and templates and I'm running into a weird issue. When I preview an email with the standard Email Preview tool, my mobile version has the bottom scrollbar and is not responsive to the width of the phone visualizer.

Where it gets quirky is that we also use the Deliverability plugin tool and the same email scales and looks great on all devices - as well as when I do actual sends to Gmail, Outlook, etc on physical devices.

Do I take the Preview issue to mean there's something wrong in my code? I've tried removing elements and can't find anything offending - or should I not take this tool as an accurate measure of how my email will look?

Dave_Roberts · ‎06-07-2023

You should probably trust very little of what you see when it come to email displays in the Marketo application -- this includes the Preview panel, but also extends to the working canvas and module sidebar in "Edit Mode". The reason that things show differently in Marketo is that it is a web-based application which gets the advantage (and in this case disadvantage) of using all the bells and whistles that come along with the modern browser. Email inboxes however are stuck in the past and most do not speak the same language nor have access to common browser features. A really common example of this shows up when using custom fonts in an email -- they'll usually show up in the Marketo interface (b/c it's web-based) but will not show up in every inbox.

We currently use Email on Acid for render testing b/c they'll return actual device screenshots (renders) of your email whereas Litmus uses an emulator to simulate loading on a variety of devices and inboxes which makes it a bit less honest in terms of what you can actually expect to get in terms of the render (from what I understand - it's been a few years for me, so this may have changed between now and then).

A bit unrelated but worth mentioning here...

Another way of going about this compared to using render testing (which I'd recommend for EVERY email, EVERY time) is get ahead of it all by using supported code. It's been a while since I've had a chance to play with email stuff but there's a website I used to use a ton as a reference that's still being updated where you can check to see which bits of code are supported in which email ecosystems: https://www.caniemail.com/

This'll let you check specific HTML and CSS elements against support charts categorized by email client and version. Green boxes are good, yellow have some limitations and red boxes are unsupported. Generally when referencing this, I'd look for things that had 95-100% support ratings before I considered adding them into my codebase. Your audience may be more or less specific so there may be a few things that you're able to work around based on which platforms the majority of your audience is using to open your emails.

View solution in original post

Michael_Florin · ‎06-07-2023

No being an email coder myself, I can only say that our developers don't use the preview. They don't even trust the Litmus inbox previews, but rather set up the most used email clients and versions themselves.

Dave_Roberts · ‎06-07-2023

You should probably trust very little of what you see when it come to email displays in the Marketo application -- this includes the Preview panel, but also extends to the working canvas and module sidebar in "Edit Mode". The reason that things show differently in Marketo is that it is a web-based application which gets the advantage (and in this case disadvantage) of using all the bells and whistles that come along with the modern browser. Email inboxes however are stuck in the past and most do not speak the same language nor have access to common browser features. A really common example of this shows up when using custom fonts in an email -- they'll usually show up in the Marketo interface (b/c it's web-based) but will not show up in every inbox.

We currently use Email on Acid for render testing b/c they'll return actual device screenshots (renders) of your email whereas Litmus uses an emulator to simulate loading on a variety of devices and inboxes which makes it a bit less honest in terms of what you can actually expect to get in terms of the render (from what I understand - it's been a few years for me, so this may have changed between now and then).

A bit unrelated but worth mentioning here...

Another way of going about this compared to using render testing (which I'd recommend for EVERY email, EVERY time) is get ahead of it all by using supported code. It's been a while since I've had a chance to play with email stuff but there's a website I used to use a ton as a reference that's still being updated where you can check to see which bits of code are supported in which email ecosystems: https://www.caniemail.com/

This'll let you check specific HTML and CSS elements against support charts categorized by email client and version. Green boxes are good, yellow have some limitations and red boxes are unsupported. Generally when referencing this, I'd look for things that had 95-100% support ratings before I considered adding them into my codebase. Your audience may be more or less specific so there may be a few things that you're able to work around based on which platforms the majority of your audience is using to open your emails.

nhabischWings · ‎06-07-2023

Thank you for the in-depth answer! This is helpful!