With this article, I realize that I’m finally consciously building new-economy business relationships. I’m going to share some new realized knowledge. Ten years ago, I would have kept this a corporate secret and would have benefited from it in the short term.
But that was then, and now as a true follower of the latest initials (which I think as I write this are eCRM), I’m more concerned with building a relationship than with the immediate dollar. I understand that if I do this correctly, the dollars will truly follow. If not, at least my industry associates may benefit.
E-mail merge/purge, not just e-mail dupe elimination, has come of age. This is not the big moment of this article, so hang on (with the “X-Men” movie in theaters, I feel like Stan Lee, co-creator of the X-Men and Spider-man). Last month I gave tips on how to avoid the look and feel of spam because e-mail merge/purge was not yet available. Now I can show how it can be done.
First, the main deterrent to e-mail merge/purge has been the reluctance or refusal of most list owners or managers to send their e-mail files to the varied transmittal houses to perform a rather simple merge/purge procedure. Security and permission decisions have kept many companies from sharing this data or emulating the procedures and etiquette of the postal world.
Here is a standard scenario:
A mailer is about to rent a number of e-mail lists from a number of list owners, managers or e-mail database houses. Of course, they are using one of several experienced list brokerage houses (and with the further experience of e-mail list acquisition). We also will assume that all of the lists selected are opt in, permission-based, yada yada yada (no joke here). Now the question becomes, if each house is transmitting its particular files, how can a merge/purge occur?
This is how – but before I continue, everyone with a license to Group 1 software or Postal Soft, or the marketing sales executives from those companies, should really listen because these are new benefits to your software and new sales opportunities.
The mailer’s broker working with its postal service bureau must create an “algorithm” based on, say, positions one, three, five, seven and nine of the e-mail record. Follow that with the inclusion of special characters if they fall into those positions such as @ and “.” (dot). Once you have a standard formula, the following steps are taken. I want to give special thanks to my colleagues for assembling this procedure.
Using conventional (Group 1 or Postal Soft) postal merge/purge software:
• Have each of the e-mail list managers use the algorithm based on the actual e-mail addresses. Remember to include all special characters. The output should be an encrypted file based on the standardized formula. This file is sent to the mailer’s regular merge/purge house or an e-mail center ready to do a merge/purge that is, in fact, a simple merge/purge.
• Load the data into a merge/purge project. This allows the service bureau to assign list codes, priorities and the inclusion of house and suppress files without any of the outside providers sending the actual e-mail record.
The provided data would be loaded into the last-name field of a conventional name and address record layout. The first-name field would remain blank, and the balance of the postal information would be populated with a constant dummy address.
This allows all records to be identical except for the e-mail algorithm (now contained in the last-name field).
The next step is the real benny of using merge/purge software instead of just a dedupe:
• Merge/purge software does not dedupe on a straight match key (which is all that’s been available so far for deduping e-mail addresses). Instead, it looks at the elements of the name and address information and creates a numerical threshold to determine whether two or more records are duplicates. All things being constant in the address data, the threshold would be calculated on the e-mail algorithm data.
Based on the same tight, medium or loose criteria that have been at the core of postal processing for years, the software would evaluate that e-mail addresses (or e-mail algorithms) should be considered duplicates. This is where merge/purge companies vary and the artist emerges.
• The software outputs its standard files (unique mail files and a file of “duplicate groups”) as well as providing the gamut of merge/purge reports (summary reports, detailed list interaction reports and list-by-list matrix reports) as well as being able to provide computer verification to the list managers and list owners.
• The clean data would then be extracted on a list-by-list basis and the e-mail algorithms (only) would be sent back to the list managers.
• The list manager would in turn match the algorithm back to its master file, extract the actual e-mail address and transmit on the records that survived from the merge/purge.
I realize that in recent weeks several e-mail merge/purge houses have been announced and they too should be considered. However, the above methods allow experienced and valued vendors to involve themselves in this new arena. It also permits the same reporting structures from the postal world to be used for another direct marketing channel.
The benefit is the standardization not by one coding structure (we never had one match code) but by a system that we all know works. And by employing a group of brokers and service bureaus that had respect for lists long before list was spelled with an “e.”
