Notes from the Dev: Gmail Clipping and Enterprise Personalization
Gmail clipping can be an issue for lots of emails. Sometimes, unnecessary lines of code are the culprit because, even though there’s nothing there, it still causes bloat. One way that can happen is when senders using enterprise software include dynamic, personalized content in email campaigns.
In this episode of Notes from the Dev: Video Edition, Richard Perry Thomas joins me to explain how to avoid the Gmail clipping issue by automatically getting rid of “white space.” That’s what he and some other developers call those blank lines of code.
Doing this also lets you move your open tracking pixel to the bottom of an email for more accurate tracking.
Richard is a certified email consultant who’s worked with a bunch of recognizable brands and specializes in executing automations enabled by enterprise marketing software applications. His advice applies to more advanced email programs, but this information could come in very handy, especially when you’re working with a complex martech stack.
Check out what Richard had to show us in the video below, then read on to learn more about avoiding Gmail clipping and controlling bloat in your email code.
Table of content
Why does Gmail clipping occur?
First, let’s take a closer look at the main problem. When Gmail clips your campaign, the most likely reason is the weight or file size of your email. When a message is more than 102kb, it’s very likely that Gmail will truncate the content. 102kb seems to be Gmail’s email size limit. So, if you’re email file size (which does not include images FYI) is too big, subscribers will see something like this:
That can be a problem for several reasons. Obviously, your subscribers may be missing a big part of your message. They may not be able to see the unsubscribe link either, which could prompt them to make a spam complaint.
Potential clipping also keeps senders from placing an open tracking pixel anywhere but inside the beginning of the email <body> to make sure the pixel isn’t in part of the message that’s clipped.
White space in the email code and why it’s there
We should note that there’s a difference between white space in design and “white space” in coding. The right amount of white space can be excellent for clean, professional-looking design. Some coders refer to unnecessary blank lines of code as “white space” as well.
While I am not one of those people, I took an informal poll of email geeks, and it turns out we have a few ways of describing it. So, when you hear Richard talking about “white space” in this episode, just know that he means empty space in code, not the design.
Blank lines of code create some breathing room, but will not impact the design and layout of an email. A little “white space” in your code can help keep things easy for you and others to follow. However, those blank lines do cause code to bloat, which could lead to Gmail clipping.
While you can and should minify your email code before sending, there’s a way those blank lines sneak in there because of dynamic personalization. When Richard takes us through his example, he shows us there are hundreds of blank lines of code, and that’s a problem.
Those blank lines also seem to appear in between the modules in Richard’s email. Here’s why...
The personalization scripting problem
In the video, Richard describes how enterprise platforms like Oracle and Salesforce have a “personalization engine,” which executes scripting that is in line with your code and replaces it with the actual personalized output for individual contacts.
Email service providers (ESPs) use different scripting and languages to make personalization happen:
- Iterable and others use Handlebars
- Salesforces uses AMPscript
- Hubspot uses HubL Syntax
- Responsys from Oracle use RPL (Responsys Personalization Language)
The unnecessary white space is created because that’s where the platforms insert the scripting for personalization and/or dynamic content. When the actual personalized content is added, and the scripting isn't needed, it leaves behind blank lines of code. And now your email is bloated like it ate too much Taco Bell.
Richard says his solution is pretty simple: execute the functions for personalization before the messages are sent.
“The method that we created in order to reduce that white space is to configure and deliver all of that data in a flat file, essentially using either an API or web hooks that compile all of the personalization and execute all of those individual directives or functions pre-send. That in essence reduces the white space.”
Richard Perry Thomas, Email Consultant
Of course, as you’ll see in the video, getting my head around Richard’s method and explanation was a little tricky at first. You can check out a code snippet from Richard we've added in Parcel for a closer look and an explanation of what's happening here and how to fix it.
Open tracking pixel placement
Once you eliminate the unnecessary white space in the code, Richard explains that another benefit is having more flexibility in where you place tracking pixels to measure campaign performance.
When you’re no longer worried about possible Gmail clipping, you can place open tracking pixels closer to the bottom of an email <body>. So, the pixel won’t fire until the email fully loads.
Open rates can be an unreliable email metric, especially with Apple’s Mail Privacy Protection, which has machines opening emails before humans. But, as Richard reminds us, when the tracking pixel is lower in the email, it can tell you more about how people are engaging with it.
“If you have the open pixel at the bottom, you can have a more affirmative understanding that email completely loaded, and that person saw that email – quite possibly from top to bottom.”
Richard Perry Thomas, Email Consultant
Share your tips with the email geek community
A big thanks to Richard for joining me and passing along his knowledge. You can see some of his work, find out more about him, and even hire him to help when you visit richardperrythomas.com.
We’re always interested in hearing how others troubleshoot perplexing email development problems like this. So, if you’ve got a cool trick, a simple solution, or a creative idea for email designers and developers, tell me about it. Contact us at hello@emailonacid.com, or reach out to me, Megan Boshuyzen, in the Email Geek Slack community. Apply today if you’re not already a member.
More Notes from the Dev: Video Edition is coming your way soon. Be sure to subscribe to Sinch Email on Acid on YouTube so you don’t miss the next episode.
