TG4
Is a "View this email as a web page" link necessary in emails that display properly?
Similar to this question, I'm wondering if folks include a 'View in Browser' link in their emails. If an email renders well in all email clients and displays the content in its entirety, is there any benefit to adding a link to display it in a browser? If there is benefit, what are some good way to go about including it?
Notes from Comments
- [case to include] share/post an email socially
- [case to include] provide email's code for anyone who's interested in peeking under the hood
- [suggestion] if link is included, don't put it at the top (eats valuable real estate, could trigger spam)
Back in the day, one of the main reasons I added the "view this email as a web page" link in emails was if a subscriber didn't have images on by default in their email client, and for whatever reason they chose not to display images but would prefer viewing the email as a web page. Though that's not something that can be accurately measured—who actively prefers viewing marketing emails as web pages.
Another benefit of including the "view online link" would be for social sharing—including it in a "tweet this" style button. But this would depend on the type of email and who you are.
The link doesn't have to be included at the top of an email, where it takes up some important screen real estate (even though I don't believe in the fold!). Including the link consistently in the same place, say at the bottom of an email, would be fine.
IMO, if your email works well everywhere, then the hosted web version link is just taking up valuable real estate at the very top. On the other hand, f you have a cool interactive email, then maybe you want it even more prominent than the ubiquitous top text link. As I mentioned in the #emailgeeks Slack, at my previous employer I had the brand logo also click through to the view-as-web hosted link, rather than to the home page. My reasoning was that they were getting a curated email with very specific content, and if they were just dumped into the homepage by an errant logo-click, they wouldn't be in the curated experience (and also, I wouldn't get clicks attributed). It was minorly controversial. But it shows another use to the hosted link than just "you have crappy software."
Hmm, good point about curated email with very specific content, a link would be a good way to share this.
Historically, this was a solution for rendering and the images-off case (which once upon a time was a majority).
However, due to the wide spread and pervasive practice of including it, users have developed habits and expectations.
One of these habits is to use (URL of) the web-hosted instance of the email for sharing and forwarding.
As rendering (of intent) is far easier to achieve now, and images-off is now a minority case, and there are several other sharing and forwarding options, it is reasonable to conclude this feature no longer has value to the sender. However, it would require a habit shift in order to also no longer have value for the user. I recommend making the decision based on your own data. If your audience uses the feature, provide it or provide something better.
One point I always assert is that inclusion of the link should absolutely never appear first in hierarchy or near enough to first that it ends up displaying with preview text in the inbox. The phrases “Having Trouble Viewing This Email?” or even “View In Browser” have been shown in several tests and reports to deter opens if seen in the inbox. It is essentially telling the user that the email will not render correctly before they even open it.
Thanks for sharing your insight and experience Charles. We are just about to redesign our wide range of email templates and will challenge my team this time if 'View in browser' could live somewhere else than in the top - or should be included at all. I think at least some testing should be done, before you discourage the idea of deleting it.
Absolutely. Test it. I would encourage you to conduct online user testing prior to developing and deploying to test in the inbox.
Adding a few comments I received in Slack:
I love them because it makes it easy to dig into the code of emails that I love and share them around.
At my previous gig, a text-heavy newsletter with a simple single-column layout, I had the view in browser at the bottom -- but, I also tagged the logo at the top with it, which wasn't an obvious link. having the logo go to the browser view was controversial, but I wanted to keep them in the email zone and capture any clicks rather than just dump them into the home page without any clear direction.
I like “view in browser” too not just for creeping on code but so that the email can be “bookmarked"
Couple clients we just recently moved the webpage link down to the footer area as they got low clicks, but another client has quite high clicks on it (in the top 5 clicked links), we're assuming likely due to the high Outlook usage they have. So when we give the template a design update in the coming weeks we may keep it at the top.
Apart from what others have posted, One of the benefit I think of "View this email as a web page" link is that I can open an email (which is not in the language I understand) and use google translate chrome plugin to translate the whole page, especially when I use Desktop Email client.
I love this use case. Thank you for sharing. This is also one of many reasons to never embed text into images, as well as a reminder to add the lang attribute to the document.
How about conditional view online links? We can hide/show based on rendering engine. For example show a view online link when the rendering engine is mso and if webkit is the rendering engine hide it.
I think putting the view online link behind the logo is also very interesting to try.
Interesting though. I would hesitate to link the logo to browser version of the email, as most users would expect that the logo links to your website. But I am all ears if somebody got data on it.
I like this approach, especially for folks shackled to desktop Outlook. I bet you can even get away with displaying it at the top near a logo, if only desktop Outlook would display the table-cell/link. Thanks for the suggestion!
From developers POV - "View online" link comes handy when I need to get approval from the stakeholders :) and in past, it came handy to check the code but Litmus Scope has changed that for me.
Excellent point, and I am glad that solution works for you. I have taken the opposite position and advocate that all stakeholder reviews and approvals occur from the context of the inbox in real apps on real devices. I think it is mission critical (@ my agency) to stop perpetuating a myth that what something looks like in a web browser is what it looks like in the inbox – especially as many components feature progressive enhancements.
You have a very valid point and now it makes me question the approach we take at my company :) thanks for the reply
There's also an accessibility use case here, some email clients strip aria attributes and semantic tags making the email hard to read with assistive technology. Viewing in browser would give an unedited view which would be more accessible.
With this use case then it should also be at the top of the HTML although could be visually moved to the end of the code with css.
Is there a risk that the ESP will use the same rendering engine to produce the web version and thus continue to strip out the aria attributes?
I've not done much digging into if ESP's strip aria yet, but yes that is possible. I was referring more to email clients stripping the aria attributes, if it's stripped at the ESP level you could host it yourself but then you'll loose any personalisation.
If you do find an ESP stripping aria it might be worth mentioning to them the potential legal implications of actively blocking accessibility.
Not to be silly, but my mother has an iPad and she said it was very hard to read most emails in the native email client so she looks for the 'view on webpage' link so she can actually read the email as it was intended in the browser. She had someone remove it from an email and decided to write to them and ask them to bring it back. They told her they had no idea it was that valuable. Now they should have been looking at the analytics, but I bet people would be surprised the reasons that this link is used and it probably is not the way they think. Thanks! VW
This example is the ‘habit’ case I mentioned in previous comment. However, this case is the result of poor design and development. When the sender received this feedback, they heard the literal ask to restore the link, but they failed to hear or consider causality. The design and development should be resolved to prevent the need in the first place.
Being webkit based and providing viewport, the Mail app in iOS on an iPad can easily have very precisely targeted solutions.
At the top of our template, above the logo, we have the Preheader text in a small font. It's visible because it's often a link. That's left-aligned. Right aligned is the "view in browser" - and you've be surprised how many clicks we get to the View-In-Browser link. Doesn't take up much real estate at all. (Someone suggested putting it lower in email - I would be surprised if people found it if it wasn't at the top.)
Anyhow, when in doubt, test (or check your analytics). Are people using it? What happens if you send an email without it? Any change in conversions, opens, clicks, shares, etc?
It’s great that you are getting engagement with this link. I’m curious. Do you see any significant difference in engagement with the rest of the email between the inbox and web-hosted version? Are users more or less likely to then follow your primary goal?
It's more difficult to assess - our ESP provides us with far less detail about the clicks on the webpage version compared to the inbox version. Our email is heavily scripted/dynamic. In in the inbox, we have aliases that let us easily see which module, click location (often within a module we'll have the same link on headline, hero image and CTA button) and country. In the webversion, we just know which link they clicked (not separated by location or country.
The only case to exclude that we came up with (other than the very valid real estate comments) is that for some ESPs, any code running in the email will re-run when it renders in a web page (this is the case for us with Salesforce Marketing Cloud). We sometimes add code to remind a recipient of recent purchases or to randomize suggestions, and we've had proofers mention that the email they received in their inbox does not look the same as the one in the View In Browser. Also, occasionally when data is overwritten, a record will be removed, resulting in an error when someone clicks that link because the code attempts to pull from the data that no longer exists.
Kevin Mandeville and I discussed this question in Email Design Podcast #47. You can find our thoughts on it here >>
https://litmus.com/blog/email-design-podcast-47-view-online-links-image-based-emails-and-above-the-fold-buttons