By Chris Lewis

Many of the best features of Campaign Enterprise is the ability to write directly back to a database triggered by certain events. In the early days of email marketing many were using simple database structures so the writeback methods were simple field updates.  If a response event occurred, a database field would simply be incremented corresponding to a click through or unsubscribe event.  As time moved on, clients wanted more flexibility and the ability to add SQL statements (stored procedures) were implemented but the field update/increment method was kept.  I will discuss the differences of the two methods in order for you to figure which is the most appropriate for you:

Simple Field Update
Using this method, you simply select a field that you want incremented when a conversion event occurs.  If you need this simplicity and you just need to know if a recipient responded in some way that this will work fine.  One of the biggest roadblocks for this method is that your datasource, the table or view you specified, cannot be written back to for some reason.  These reasons can be as simple as the table is locked or the SQL statement you are using does not allow updates for a multitude of reasons.  Some of these reasons can be that your SQL statement is a one-to-many relationship, you are using grouping or aggregate statements, you are using a union query, etc.  Campaign Enterprise can only do as much as you allow it to do and many of the reasons for non-updateable data can be subtle.  If you just specify a table for your datasource field increment updates should not be a problem, but the key is to keep it simple.

SQL Statements (Stored Procedures)
This method of database updates give you complete control of the situation.  You are no longer bound to using the original datasource for updates, in fact, you can write back to any table you specify or perform mammoth size operations for a response event  like click throughs.  In Campaign Enterprise you can specify any SQL statement that your SQL Server will allow and Campaign Enterprise just passing that statement along to your SQL Server.  The only modifications that are done to your SQL statement is the replacement of "merge fields" in the statement.  For example, you can use this to record conversion events:

UPDATE tblMyClientList set EventEmailDate=GetDate() where ID={UNIQUEID};

If you put this statement in the particular event tab in your campaigns, when the event occurred this statement would be sent to your SQL Server with the {UNIQUEID} merge field replaced with the true unique ID value for that recipient.  As you can see, this is a free-form area and you could make the SQL statement anything you want.  You can even have a stored procedure run:

EXEC spTrackingEvent {UNIQUEID};

In that way, you don't have to put any code at all in Campaign Enterprise.  Also, no tables are exposed and your can even lock down the security in the SQL Server for this stored procedure.  There are other merge fields you can include in your SQL statement that Campaign Enterprise will replace, but it is too big for this article. You can request a list from us or look in the documentation for more merge field replacements.

There is a switch in the Campaign Configuration section in the Administrative area of Campaign Enterprise if you want to use this ability.  It is by default turned off to now confuse people when they first start to use the product.

General Bounce Information
Managing bounces is one of the most important steps you can take with email marketing. Remote servers (those responsible for delivering to your customers) tally up the number of failed emails to their domain and will score you based on the percentage. If your bounce percentage is high, they can start blocking you on the fly to other emails in their domain. Identifying bounced emails the first time, and filtering them or removing them from your list is critical for email deliverability.

In order for Campaign Enterprise to manage bounces, you must set up an email account exclusively for Campaign Enterprise's use. Create a new POP3 or IMAP4 email account as though Campaign were a new employee. This account cannot be an alias of another account and must be exclusive to Campaign. Once you configure the account, use it as the return path address, which is identified as the bounce email address on the compose message page in the Campaign edit screens.

The Return Path email address is where non-delivery failure notifications go, also known as NDFs or bounces. These are notices from your mail server, or subsequent mail servers in the delivery chain, indicating a problem with sending the message. A permanent NDF is considered a hard bounce, either the domain or address doesn't even exist. These are identified by Campaign as a hard bounce, and can be filtered or removed from your list immediately in most cases. A temporary NDF is a notice from an email server that there was a problem with delivery, but your mail server may retry the message on a scheduled retry. You'll need to talk to your mail administrator about the number of retries your server has. These are identified as soft bounces by Campaign and you can use more discretion on filtering or fixing these addresses.

Managing Bounced Emails with Campaign
Other write back features in Campaign Enterprise use the unique id, but the id is frequently stripped out of bounced email messages. The only thing that is always preserved is the original to address. Unlike other features with Campaign Enterprise, the record that bounces is updated by comparing the original to address with the address field in your source table, not the unique id. Since this is the case, you will need one bounce email account for each table to which you are connecting.

Scenario One
In the example below, there are three different campaigns, all using the same source table. In this case, all the campaigns use the email address for bounce account 1, but only one campaign needs to actually have bounce enabled. All bounces, regardless of which campaign sent them, will update in the source table.

Since the source table is updated, all three campaigns will be able to identify the bounced emails and apply the filter to prevent those emails from going out again. Using this scenario, you can create a Bounce Campaign, which is open to the entire table, no filtering, and enable it to monitor the account. It will monitor the account for all of the campaigns connected to that table and using that bounce email account.

Scenario Two
This example shows how bounces should be managed with multiple tables, one for each campaign. Since the source table has a specific group of addresses, you cannot check that account with the same bounce account being used by another campaign, the email address may not appear in the table. Each campaign would use the email address for the specific bounce account to which they are connected.

Scenario Three
Finally, you can set up your bounce account to monitor an email account that accepts wild cards. With this option you can use VERPS, or Variable Envelop Return Paths. This is explained in more detail in these two articles.
Using VERPS
More on VERPS

Unfortunately, MS Exchange Server 2010 does not support email accounts with wild cards. For more information on setting up your bounce email account, check with your email service provider.

By: Chris Lewis

I encountered an interesting phenomenon this week concerning email that started me thinking about ramifications this had on overall email distribution for professionals like us.  I have a few different email accounts with different domains that all forward to my one email account. It is not an optimum way of doing things but it works for the way I work. Awhile back I stopped receiving the forwarded emails from my custom domain hosting with Google Apps.  The emails sent to this custom domain account did not bounce, and no other error indications where happening, the emails were just not seemly being forwarded.  After scouring the internet for hours no one had a really good explanation...but then I thought, SPF record.  When I forward emails from the custom domain on the Google Apps account, in essense, Google Apps becomes an SMTP server for that custom domain.  If that is the case, then the receiving SMTP server is going to check to see if the Google Apps account has "authority" to send on behalf of my custom domain (using the SPF record), and if not, the email will be dropped.  Well, I created an SPF record in the DNS for the custom domain, waited a few hours for it to propagate, and bam the forwarded emails started showing up.  Here is the DNS TXT record entry I made in GoDaddy:

This statement gave "authority" to Google Apps to send these forwarded emails to my destination email!  This is simplistic, and you may have other SMTP servers you want to give authority to send your emails.

So, I suppose the moral of the story is if you are sending emails for a specific domain, make sure you give authority to this SMTP server or servers sending those so that the destination SMTP server will not reject them.  Remember, the destination SMTP server is not obligate to return a bounce saying the email did not make it.  With all the effort we do to make clean lists and work in a professional scenario, it is a shame if something as simple as this hinders your efforts.

Enjoy!

As your database grows in size and complexity, it may affect the performance of your email marketing campaigns. Frequently, performance issues appear to some people as a sudden change, causing them to blame the program for the issue, when the problem may be much deeper. One of the best ways to improve database and campaign performance is to index your fields, especially the fields you are using for merging and updating.

According to Wikipedia
A database index is a data structure that improves the speed of data retrieval operations on a database table     at the cost of slower writes and increased storage space. Indexes can be created using one or more columns     of a database table, providing the basis for both rapid random look ups and efficient access of ordered             records. The disk space required to store the index is typically less than that required by the table (since             indexes usually contain only the key-fields according to which the table is to be arranged, and exclude all the     other details in the table), yielding the possibility to store indexes in memory for a table whose data is too         large to store in memory.

In a relational database, an index is a copy of one part of a table. Some databases extend the power of indexing by allowing indexes to be created on functions or expressions. For example, an index could be created on upper(last_name), which would only store the upper case versions of the last_name field in the index. Another option sometimes supported is the use of "filtered" indexes, where index entries are created only for those records that satisfy some conditional expression. A further aspect of flexibility is to permit indexing on user-defined functions, as well as expressions formed from an assortment of built-in functions.

When I worked on running dive meets (springboard and platform diving) for my daughter, we had a system where people would turn in dive sheets based on age brackets, gender, and diving level.  At first, we had just one inbox for the divers to turn in their dive sheets. With a total of 50 divers we could answer the questions of how many girls vs. boys are there, how many 10-11 years olds, how many novice or junior Olympic levels are there. We had to cycle through the whole pile to get those questions answered each time, but we could answer the questions pretty quickly. As the season progressed, we started having more divers come, and when it go up to 500 divers, having the one in box was crazy and it took a lot of time to answer those questions.

In the same way, using a database, a small number of records within a table can be managed pretty efficiently without any indexing.  When a question is asked of the database (filtering), the database system cycle throughs ALL of the records noting which records should be included based on the filtering criteria (ie: State='CA').  The time it takes to do this is unnoticeable until about 10 thousand records or so.  Now you start noticing a lag time, but, it is still acceptable and you are too busy to deal with it.  Time moves on, the number of records in your table is increasing (which is good!) and now your waiting 10-15-20 seconds. Then someone imports 50,000 records into the table and boom, you start getting timeouts.  You say, "this worked this morning!  And I did not change anything."  You have just crossed over into the "Indexing Zone."
 
These types of issues sneak up on you unless you have a completely static list of people to send email too. It will happen!  Now even the most seasoned database programmer can get caught in this trap.  The only way to really make sure things are in tip-top shape is awareness and maintenance.

Indexing is kind of like presorting.  Say you have a table with basic contact information in it (name, city, state, etc.).  When you add a record to the table without having any indexing, all you are doing is simply appending a piece of data onto the end of the table, no order, no nothing. Contact your database administrator today to start indexing your data and improve your email marketing performance. 

By: Chris Lewis

We are asked frequently "what database should I use?"  Now since the question is being asked, usually that means you don't have one and the field is wide open. Though you can convert to other database types later, it is better if you can look at your future needs and plan based on that.  This might take a bit more cost and setup, but if you are planning on growing your lists and abilities, it is the best course.  The following is a list of databases with their advantages and disadvantages

Microsoft Access - This is a "file" based database which is a great start and may actually be all you need.  If you are primarily sending out emails, don't have a ton of responses events, than this database is great.  We have actually seen it work for many years for large situations.  An MS Access file is very stable, easy to backup (one file), and portable.  The disadvantages is that with heavy use the file can become corrupted but very rarely.  You do need to compress this file so that the database does not get too inflated, especially if you are adding and deleting a lot of records.  Some people have used an Access database for the database back-end for Websites, and that may be OK, but if it is used with an active webserver and Campaign Enterprise at the same time there can be a chance of deadlocks (trying to access the same info at the same time). Since many processes may be accessing the database file at one time without "each other's knowledge", there is the potential for collisions.  BUT, don't worry about this until it happens.  Access is a great solution and will be support by Microsoft for many years to come.  MS Access is not free but it is usually $100 or part of the MS Office Professional package.

Microsoft SQL Server - This system is a true client-server database. Since the server takes requests from many different processes and lines them up in a queue, these requests are handled in an orderly fashion and avoids a lot of the problems that a single-database file has.  Advantages are that the SQL server can be installed on the same or a different computer than the one running Campaign Enterprise so you can distribute the workload.  It also allows you to have your webserver, database, and email sending system separated.  We always recommend you use an SQL server like this whenever possible.  This system can cost from $995 and up for MS SQL Server 2012.

Microsoft SQL Server Express - This free database functions just like the full SQL server above, but they have a database volume size limitation and it will only use on CPU core.  The limitations of the Express versions change each release, but many will find this system to be more than sufficient.

MySQL - This free database is created and maintained by the public domain.  Many people use MySQL with Campaign Enterprise successfully.  Most of the time people use ODBC to connect to the database but there have been OLEDB providers available too. MySQL will use multiple cores on your computer and there is not a limit on the database volume size like MS SQL Express.   If you don't like Microsoft products and want a good free SQL database then MySQL is a good choice.

Oracle 11g - Oracle works well with Campaign Enterprise. You will need to be experienced setting up database connections using their ODAC connector.  You can use a personal version of Oracle for free.  The full versions of Oracle have a lot of different pricing structures so it is hard to quote.

DB2 (AS 400)  - This database is for IBM mainframes. Campaign Enterprise has connected to this type of database but it is mostly used large companies with established systems.

Many Others - Campaign Enterprise can connect to any database that has an ODBC or OLEDB connector.  We have successfully seen it work with Foxpro, Filemaker, and even text-based files. These databases many times do not allow for outside writebacks so if you are trying just read information from a database than these will work but they are not recommended.

A new label is being applied to a specific category of unwanted emails. BACN is the "clever" new acronym that applies to emails that don't quite fall into unsolicited bulk email, or as highly prized and desired email. It falls somewhere in between on the desirability scale. As email marketers it is imperative that you take steps to avoid your messages falling into the BACN designation.

What is BACN?
Unlike SPAM, BACN email is slightly more palatable, but too much of it is not good for you. The email that falls into this category is best described as something you signed up for, but don't really read. However, you don't want to unsubscribe because every so often you might get a golden nugget of information, or a coupon for something you really need. From the email marketer's standpoint, the problem with BACN email is that it is rarely read.

There are three major steps you can take to avoid the BACN designation:

1. Create anticipation. The main reason your email messages may be going unnoticed is that you send them too frequently. You want to generate some anticipation for your next offering so that when your email enters the inbox, the recipient says to him- or herself, "Oh, I haven't heard from them in a long time. I wonder what’s going on?" Limit email sending to enhance the reader's expectation.
2. Add more personalization. Over time, you collect a lot of data on your subscribers: who they are, what they like, how much they spend. Use this data to create engaging, one-on-one communications. Make your subscribers feel that your email message is a one-off message that engages them in a real conversation.
3. Segment unresponsive subscribers. As hard as it may seem, at some point it is best to let unresponsive email addresses go. If you see a drop off in opened emails -- especially in click through results -- the recipient may no longer be interested. This is not to say to get rid of them altogether… but at least put unresponsive addresses in a separate list segment. Eventually you may send them something to see if they are still interested in receiving what you have to offer, or something that directly asks for what subscribers would like to see from you.

While it may not seem like a bad thing to send to people that never read your email, it’s a waste of time to send to people who do not respond. While BACN isn't considered unsolicited bulk email, it does add to people's frustration when it comes to managing their inboxes. It may come to a point where they declare email bankruptcy, and you’ll lose them altogether if not properly managed and cultivated.

By: Chris Lewis

I lightly addressed this issue last month but many asked for a better description of the SPF authentication method, so here it is.  Setting up a new SMTP server is pretty easy, especially if you are using an IIS SMTP server.  Many have set up SMTP servers on Webservers just so that when someone fills out a webform that this information is emailed to you. What can happen though is that even though the email is sent to your SMTP server, it never makes it to your Inbox.  The emails seem simple enough and could not even come close to SPAM, so what is the problem?  The problem is usually it is that YOUR email provider (the receiving system of email), like Gmail, that is dumping those emails because it could not authenticate the domain part of the email.  If you don't have an SPF record setup for your domain in DNS, it is possible that 90% of your emails will never make it to recipients and you will never know it because it is not considered a bounce!

Here is what is happening:

- You send an email with your email client, mass mailer, or website form to your sparkling new SMTP server
- Your SMTP server happily sends the email off to the destination SMTP server
- The destination SMTP server sees your email is coming from something@yourdomain.com and before accepting the emails asks the DNS system for the SPF record for the yourdomain.com domain
- If the SPF record does not exist on your DNS, the destination SMTP server is going to consider your SMTP server as not authorized to send on behalf of yourdomain.com and will reject the email
- If the SPF record is found for yourdomain.com, the IP address in the SPF record is compared to that of your SMTP server that is attempting to deliver the email.  If they match, the email is accepted. If not, the email is rejected.

So, if you are setting up an SMTP server to send one email a day or 1 million, you need to have an SPF record in your DNS server for the domain you are sending from.

SPF is just one of the ways email messages are authenticated as being legitimate senders for the domain. The advantage the SPF method has over other authentication methods is that the SPF record is easy to enter into the DNS, the email message is not modified as in the DKIM method, and it is basically a perfect way to stop SPAM.  The disadvantages of this method is that every email addresses domain you have needs to have an SPF record, so if you are sending emails on behalf of others, there is a lot to manage.

SPF, DKIM, and other email authentication methods are many times used in combination with one other.  Most of the time these methods are used in SPAM scoring, and though an email's successful delivery is not absolutely based on the presence of these SPF records, it adds a TON of good SPAM scoring points to the equation.  Below is a simple example of a SPF record entry in a DNS system.  This can be added in the TXT section of the DNS record. 

For HOST: normally use the @ sign which means use the domain name for the DNS entry.

For TXT: v=spf1 a ip4:XXX.XXX.XXX.XXX ip4:XXX.XXX.XXX.XXX include:yourdomain.com ~all

Change the XXX IP addresses to the IP addresses your SMTP server using to send.

Obviously this SPF record could have a lot of different variations on formatting, but this will give you an example of a simple format and shows you just how easy it is to set this record up.  I hope this helps your deliver-ability!

By: Chris Lewis

Well, not really for dummies, but knowing more about this anti-spam system will help you get your emails into the Inbox.  Most of the time, the question is, "should I use DKIM for my email sending..." YES!  "Will it ensure my emails get into Inboxes?"  NO!  But, it helps a ton.  DomainKeys Identified Mail (DKIM) is a method for associating domain name to an email message thereby allowing a person, role, or organization to claim some responsibility for the message.

Here is how it works:

- You send an email using your SMTP server.
- Your SMTP server that has authority to send in behalf of your domain adds a DKIM signiture header to your email and sends it
- The destination SMTP receives the email, sees a DKIM signature in the email, and then looks up the public signature on your domain using via DNS
- If the signature in your email authenticates with the public signature in your email, then the email is "good"

Now, saying that the email is "good" means that the destination SMTP knows it is from you, but the destination mail server will still SPAM score your email by the content.  DKIM adds a ton of "good" SPAM scoring advantage to your email and thus will greatly improve it's inbox-ability.

So, if you are not using DKIM, use it!  Click here is a great link in Wikipedia on the subject

Understand this will not have anything to do with your email sending client, like Outlook or Campaign Enterprise. The system works because it is on a SMTP server level of activity and is based on authority that can only be established by domain owners.

By: Chris Lewis

Working with clients over the past 15 years on email projects I have seen some really great emails.  Many times I have seen these great emails have really bad subject lines.  You may craft the best email ever, but if your subject line is not done correctly, it is like it never existed.  The subject line many times is just an afterthought right before you send the emails but it is probably the most important element of an email. When a recipient receives the email, they usually only see two pieces of information that determine whether it is worth opening your email is the From and the Subject.

So spend a good amount of time crafting your subject line.  Here are some guidelines to consider:

• The subject does not have to be something "catchy", but needs to appeal to the viewer to open the email to see more, so don't give too much away or they may not even bother.
  
• Don't use lots of punctuation or capitol letters.  This can be sign of a spammer or just trying to get cheap attention. Many spam filters look for this and your email may not make it in the Inbox anyway
• Personalize if you can.  Adding some familiarity will help show some thought even if machine generated. Example of this would be a specific product or service that pertains to the specific recipient
• Don't make the subject super long or too short.  Try to use about 10 words, it is easier to scan.
• Test subject lines.  Use A/B testing where you send out a variation of subject lines to see which ones have the most effective open rate.