BY JENN FERNANDES Between conceptualizing, designing, copywriting, and testing, creating emails for your clients puts a lot of pressu...
BY JENN FERNANDES
Between conceptualizing, designing, copywriting, and testing, creating emails for your clients puts a lot of pressure on your team to perform.
Add another layer of complexity to the mix: strict company guidelines or legal parameters around sensitive content and data. Industries from financial to pharmaceutical, government, and higher education will rely on your team to make sure their content and data is handled appropriately.
Below are some actionable tips to ensure you meet not only their marketing goals, but also their specific privacy guidelines.
WHAT IS “SENSITIVE CONTENT AND DATA?”
Sensitive content is content relative to private information about a subscriber and/or information in the email that cannot be released prior to the official send. For example, when dealing with financial clients, customer account numbers, ID’s, or even the full customer name itself can be considered sensitive.
It’s important to these types of clients that actual subscriber information is never seen or tested by you, as the end agency or designer. They may have real content, but don’t want it tested or built into the template for fear of this being shared prior to the official send.
Sensitive data pertains to the capture, storage, and possible review of Personally Identifiable Information (PII). In the email world, PII is usually the subscriber’s email address. Clean subscriber lists are the holy grail of the email send process, and need to be handled as such.
NOT THE REAL CONTENT? NO PROBLEM!
You may be thinking “How is our team supposed to build, test, and edit these templates without all the real content?” Well, fear not! Below are some ways to get around building and testing when you are missing some or all of the real content.
MASK CERTAIN AREAS OF SENSITIVE CONTENT
You should seek ways to mask or use Lorem Ipsum (fake text) in areas of the email containing sensitive information. For example, if an area is meant to contain an subscriber account number, use placeholder text. This will allow your team to test the structure, HTML, and overall rendering of the mailing, without the worry of real information being exposed in the process.
Keep in mind, though, any areas of content you mask might affect your Spam Testing process and results. When you test with Litmus’ preflight Spam Testing tool, you’re also testing your reputation and authentication, which includes an assessment of the content. Thus, masked areas with fake or placeholder content could potentially skew the Spam Reporting results. It’s important to convey this to your client when delivering their assets and Spam analysis.
RETEST & BUILD OFF SHAREABLE, MAIN TEMPLATES
If you have been tasked with retesting an old email campaign for continued accuracy, you need to make sure that your team doesn’t grab an actual email with subscriber info or sensitive content.
Instead, consider using general templates that do not have this information and make them accessible to your whole team, such as within Litmus Builder, for future use and testing. This way, you’re maintaining client privacy while creating consistency around design.
REMOVE PERSONALIZATION IN TEST SENDS
Your clients may open your test mailing and see their information populating these fields and assume this means that you are accessing/viewing their subscribers’ sensitive information. It may seem a bit silly, but if you are tasked with setting up and sending over test sends to your clients, you may want to remove any personalization elements until you are ready for the final send.
Doing so can prevent distracting them with privacy concerns. Instead, relay to your client that you have removed these strings for testing purposes and they will be added back post- test send.
HAND OVER THE RESPONSIBILITY
If their sensitive content is not being dynamically generated in their system or platform, have your client manually place this content before the actual send.
If you do decide to give your the client the responsibility of updating the final content for send, make sure they’re comfortable working with emails. If your client is not acclimated to code and/or their email service provider (ESP) editor requires them to update in the HTML itself, make sure they know how to do this (so all your work and testing is not thrown out the window)!
TRAIN YOUR TEAM
And finally, if you want to ensure you can take on clients with sensitive email needs, make sure your team knows the correct processes to build them. Your team should be aware of the risks and know the correct process for testing to avoid privacy/security concerns.
DATA, PRIVACY, & PII
If you are handling and have access to your clients’ subscriber data, they may have concerns around how the data comes in and/or what your team can view for PII. Below are some ways to remove PII when setting up analytics tracking and handle the data thereafter.
REPLACE THE PII PIECE WITH A UNIQUE ID
Many analytics tracking products, including Litmus Email Analytics, rely on a piece of code inserted into your mailing.
If you are using Litmus Email Analytics, this piece of code contains a merge tag that identifies the email address of the subscriber and all the information associated with how that user interacted with your mailing. For example, if I opened your mailing, you could see that mynamehere@litmus.com opened your email on mobile, Apple Mail 7, was located in Boston, Mass, US, and more.
Many clients want to hide this email address info from their data and from you, the end agency or designer. To hide the email address, you can use a unique identifier or merge tag, replacing the email address field in your reports.
For example, you could use a customer number, ID number, or any other string of information that the client can understand on their side, but you cannot decipher. And to do this in Litmus Analytics, simply remove the email address merge tag from the snippet of code itself (for ex. d+*[Email]*).
Once you’ve hidden this data, you will simply pull in another way of classifying the subscriber and their interactions, such as subscriber ID number. It’s important to note that your client will need some way of lining up this subscriber decrypted info with the actual email addresses on their side.
REPLACE THE PII PIECE BY “HASHING”
Another option to replace the PII piece is through “hashing.” Hashing involves using a special algorithmic process that transforms email addresses (or any other piece of data) into a string of characters. That string of characters can then be decoded back to the original value. Hashing is complicated stuff, so we recommend you get your development team involved in any attempts to hash data.
REMOVE PII ALTOGETHER
If your client is concerned with metrics at an aggregate level, and does not need to see when/how a specific subscriber interacted with the mailing, you can remove the merge tag or identifier for email addresses and therefore remove PII altogether.
You can either remove the merge tag for email address (for ex. d+*[Email]*) when you generate the HTML tracking code or leave the ESP from the dropdown unchosen. Both ways will ensure that you are not pulling in any subscriber level information that is sensitive.
Creating email is not easy, and creating an email where you have to dance around sensitive content or data, even less so. Understanding sensitive data will better equip you to serve clients in industries where this isn’t optional—it’s a standard.
NEED MORE HELP?
For more information about Litmus Email Analytics and removing PI, take a look at our help articles on excluding PII from email opens and using custom parameters in your reports.
For more general resources for agencies or teams creating emails for clients, check out our blog post on how to create great emails for clients.
COMMENTS