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 clickstream data. For all of the great ideas, many of which you may already have, professionals and pundits like to tell you what you should be doing-- 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.
In my consulting practice I've found that new clients always seem to have 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 a basic understanding of how their email marketing tools work with their backend and an action plan. They know where they want to go; they just don't know the steps to get there.
In this first article we'll take a look at the backend 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 the email marketing system logs. These logs are used to monitor all deployment activities at the ESP. They are used to identify problems in deliverability, missing variables and attributes not being processed by the backend, 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 ESP. This is the log that your ESP uses 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 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 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 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:
Opened Logs-- This is a log 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.
Other Support Logs
Other support logs include:
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 backend 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 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-- You've heard about these. These closed-loop reporting mechanisms between ISPs and your ESP are maintained by the ESP and automatically block complaint email addresses from receiving any email messaging. This is something to be watched when it comes to a paid subscription product.
Here is an example: 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, the time/date of the complaint, and the identifier of the campaign from which they complained.
The Diagram below 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.
My next article will dig a little deeper into the logs that we've discussed today to explain email audit trails, why they are important and how to use them to meet your business needs.
Successfully segmenting email marketing since 1997 on his own projects and professionally since 1999, John Caldwell has played a hands-on role in the development and operations of successful email marketing campaign management in both agency and enterprise environments. Caldwell is known for tying operational metrics to business and marketing operations that provide the foundation to support leveraging clickstream and supplemental data to drive relevant dynamic content. His agency days include email marketing for companies such as WebEx and Lawson Software, while at Experian Consumer Direct he developed and maintained over 300 automated and event-triggered campaigns, in addition to tens of static campaigns per month.