The following was first posted in May of 2006 under the title, Get to Know Your Email System at iMediaConnection. As organizations strive (okay, the smart ones anyway) to become more relevant in content and timing at the individual level, and understand that monitoring their system operations and feedback helps to better manage their Sender Reputation, maybe now is a good time to look at this again….
You’ve heard over and over again the things that you should be doing for successful email marketing: opt-in methods, segmentation, relevant dynamic content, leveraging click-stream data – but try to find someone to tell you how to do it. You’ve bought all of these cool tools, the meter is ticking, you’re overwhelmed, and the salesman is back at your door.
I often hear the same questions and concerns; “How do we get started?” and, “We’ve started, but don’t really know how to get where we want to be.” What do they want? They want to be able to leverage click-stream, behavioral, and profile data to better deliver content that is timely and relevant to the recipient. They want to be able to catch problems before they become problems. They want a basic understanding of how their email marketing tools work with their back-end and an action plan. They know where they want to go; they just don’t know the steps to get there.
Let’s take a look at the back-end of email delivery tools, the kind of log files you should expect to see, what they all mean, and how they may be used for problem solving and to reconcile your business operations with your email marketing communications.
Behind your cool ESP account GUI are – or behind you in-house system ought to be – the email system logs. These logs are used to monitor all deployment activities of your ESP or in-house tool. They are used to identify problems in deliverability, missing variables and attributes not being processed by the back-end, and actions taken by the recipient in regard to the messaging received. They are also used to reconcile event-triggered or processed records vs. the actual number of records deployed, and the content conveyed.
There are two basic types of logs: deployment logs and response logs. Other logs may be used to support other aspects of campaigns such as event-triggered campaigns. An enterprise-level ESP will give you visibility into these files.
Deployment logs include:
Sent Logs— These are just as they sound: logs of all message deployment through the email system. This is the log that your ESP will use to bill you. The recorded fields should include: the recipient email address, a campaign identifier, time/date stamp the email message was sent, a content identifier if applicable and message format (HTML, Txt)
Bounced Logs— You’ve heard all about bounced emails: hard bounces, soft bounces. These are logs of all messages sent through your account that have bounced.
Too many ESPs these days will re-attempt to deliver a soft bounce over a set period, and then will classify that soft bounce as a hard bounce. This is not a good thing. Sure, they’re trying to protect you from yourself, but they’ve already sold you a loaded gun without instruction, so are they really looking out for you?
Fields in the Bounce Log should include: the recipient email address, a campaign identifier, time/date stamp of the final bounce, a content identifier if applicable, and a bounce description or reason for the bounce.
Skipped/Failed Logs— Not all ESPs or in-house systems skip or fail a message deployment for other than a missing email address. Some ESPs will insist that you use a default value for instances where a field value may be missing. That’s fine if you’re doing a name replacement, but how does one set a default value for a lost password email or other transactional message that may include relevant customer data or order information? Some ESPs and in-house systems will deploy the message with blank values, leaving you with more work trying to determine who may or may not have received a blank email, or message with blank fields. What kind of image does that portray to your customers?
If your organization operates a call center, you may find that your call volume increases with questions and complaints from recipients of incomplete transactional or post-transactional messages. And in some instances, credit card processors will charge-back your account if you cannot prove a good-faith attempt at delivery of a receipt. Both come with a cost to business.
Skipped/Failed log fields should include: the intended recipient email address, a campaign identifier, and a description of the skip or failure. If a field value was missing, it should log that field.
Response logs include:
Rendered/Opened Logs— This is a log file of all HTML messages that were determined to have been opened by the recipient. Fields should include: the recipient email address, time/date stamp of each open of the message, the email message format (HTML, Txt), a campaign identifier, and a content identifier if applicable
Clicked/Responded Logs— These are logs of all clicked links in a message. Fields should include: the recipient email address, time/date stamp of each click instance, a description or identifier of the link clicked, a campaign identifier, and a content identifier if it applies
Unsubscribe Logs— These are logs of people who have unsubscribed from your recipient list. Unsubscribing does not apply to transactional messaging. Like the others, the fields should include the recipient’s email address, the time/date stamp of the opt-out and the campaign from which the recipient unsubscribed.
Incoming (distribution) Logs— Incoming logs for API posts often act as distribution tables for event-triggered messaging. A customer transaction receipt sent via the ESP is really just an event-triggered message, usually posted from the organization’s back-end using an API-type post for real or near real-time processing. To trigger the event at the ESP, data is posted to a distribution table that also acts as a log file.
Do you want to know how long it really takes your ESP to deploy an event-triggered message? Compare the time a record was posted to a distribution (log) table to the time the Sent Log records the message as being deployed. If it’s more than two minutes, then maybe it’s time to start shopping for a new ESP.
Fields for this log should include the recipient email address, a campaign identifier, time/date stamp, and variables and attributes to be populated in the message.
Complaints Logs— A.K.A. Feed Back Loops (FBLs). You’ve heard about these, the closed-loop reporting mechanisms between ISPs and your ESP or in-house system. A reputable ESP will set up and maintain these for you and will automatically block complainant email addresses from receiving any future email messaging. Those using in-house systems must maintain these Feed Back Loops themselves. ISPs expect recipients that have complained not to be mailed to again by you. To make it even more fun, several ISPs will redact the email address of the person making the complaint and it’s up to you to map the complainant to the address.
Here is something to be watched when it comes to a paid subscription product and FBLs: Someone pays to subscribe to your service and receive whatever it is that you sell electronically. They forget their password and submit a lost password request. When they receive their password they report the message as SPAM since there is no provision for them to opt-out of receiving Lost Password email messages. A week later when they forget their password again they can’t receive the message with their password and now want a refund because you won’t tell them what their password is. This is a true story and one that I have experienced too many times.
The complaint log should display the recipient’s email address or unique identifier, the time/date of the complaint, and the identifier of the campaign from which they complained.
The diagram offers an example of what the different logs we’ve discussed might look like. Each business is different, and you’ll want your files set up to meet your business needs.