Showing posts with label data. Show all posts
Showing posts with label data. Show all posts

Saturday, July 07, 2007

Structure of a Mailing List

In my job I deal with mailer created lists and databases on a daily basis. Some are better that others, but almost all could be structured better. Since data is one of the cornerstones of Relevancy Marketing, I thought I'd take a minute to discuss how it should be structured. I am only addressing the mailing list portion of the data here. Any additional data can be structured as required.

An address consists of several elements:

  • Addressee or Contact
  • Firm (Company or Organization)
  • Address
  • Suite, Floor or Apartment
  • City
  • State
  • Zip or Postal Code
  • Country
There is only one address line. So your data should contain only one address line. You may in fact have two or three on your data, but only one is the mailing address. The problem is that in your data, it may be spread across three fields. This type of data structure greatly increases the chances that the address will be washed out of the list during the zip+4 encoding, or become UAA (undeliverable as addresses) during mailing. Let's look at what an address might look like:

Chuck Lafean
PO Box 665
123 Court St.
Floor 2
Auburn, MA 09210

What I have here is actually two addresses, a mailing address and a physical address. If this is run through CASS sofftware (coding accuracy support system, this is a USPS term, describing confirming an address is deliverable and appending a delivery point barcode), both addresses are probably good. Great, right? No, the physical address 123 Court St. may not have a mail receptacle, and if it does, floor 2 may not. The correct mailing address in this case is:

Chuck Lafean
PO Box 665
Auburn, MA 09210

Here is a basic template for a simple mailings list: http://spreadsheets.google.com/pub?key=pG1NFxLqU5zi5m9gi7U-xZw. Simply copy and paste the header into a blank spreadsheet.

Thursday, July 05, 2007

Data Storage

At this point in the process, you are just storing data. The structure of the data is very fluid at this point. That is you really don't know what you are going to end up storing- the number of fields, what the fields are going to contain, etc. For this reason, I recommend using Excel or some other spreadsheet program.

A spreadsheet is ideal at this point because it is very forgiving and adaptable, and adjustments can be made rapidly. With a database, it is necessary to know what you are going to need to store from the very beginning. I'm sure someone will disagree with that statement, and I would admit that yes, database programs can be adapted after creation. However, I have yet to find one that automatically updates across a schema when adjustments are made. If you have one, go ahead and use it, but just remember, you are now the database administrator- do you really have the time for that at this point?

Another primary advantage to using a spreadsheet is that virtually everyone can operate the program. Even if they have never used the program before, they can be quickly taught how to enter data.

While ultimately you might want to create a relational database structure, that is not necessary now. A spreadsheet is easy to break up into parent and child tables at any point in the future and even on an ad-hoc basis.

Additionally, Excel provides easy access to ad-hoc queries and even cross-tabs (I realize this is perhaps overly technical, if you don't know what I mean by these terms, that's ok, don't worry about it.)

In short, Excel provides all the power you need future, and the simplicity and speed you need now.

A note to geeks:

It may seem like you would want a more robust database program to collect this data, and eventually you might. But unless you are already well versed in that program, taking time to learn is a momentum killer at this point. Now is time for action, not steep learning curves. Hiring the development out is not any better. First of all you can't even design the schema of the database yet so paying someone to develop the database is a waste of money; money that should be spent communicating and collecting additional data. Second, database development can be pretty time consuming, and at this point in the process you don't have the time.

Excel allows for rapid collection of data in a very free form way and with very little training. This is exactly what is needed at this point.

Monday, July 02, 2007

Anecdotal Data

As we begin the process of Relevancy Marketing, we begin to add the data that will us to determine what is relevant to a specific client or prospect. While CRM and database marketing rely on historical and modeled data, Relevancy Marketing generates it own data.

At the beginning of that process is anecdotal data. In other words, what the company thinks they know about a particular customer or prospect. For example;

  1. Rank this customer, from one to five, in terms of how recently they have done business with us.
  2. Rank this customer in terms of how frequently they have done business with us.
  3. Rank this customer in terms of how much volume this customer has done with us.
This is an RFM analysis for those paying attention.

other questions might be,
  • Rank our account penetration of this account, that is how effective have we been at selling to all the users of our products or services in a particular account.
  • Rank our account saturation for this account. This is the number of product/service lines we sell to an account- are they buying everything they can from us?
All ranking should be done on a scale of 1 to 5. This allows for distribution in quintiles or groups of 20%.

Other anecdotal data:

Business to business:
  • SIC Code or Industry Type
  • Geographical data
  • Company sales volume
  • Number of employees

Consumer:
  • Geographical data
  • Lifestyle info- what do they do for fun
  • Income
  • Homeowner Status
  • Marital Status
  • Birthday
  • Anniversary
  • # of Children
  • Children's name
  • Children's birthdays
This data is going to be used in three ways; we will use it to segment our list, and we will use it to develop a profile of our customer and we will use it when we test the effectiveness of our marketing.

It may appear that some of this information may be very private, and it is. As you begin to collect this data you need to become very conscious of security. How you store it is another potential challenge. I recommend Excel or some other spreadsheet at this point.

Collection of this data should involve anyone who might be able to contribute. If your company has sales reps, they should provide info about just their customers, thus breaking up the task. Print out a customer list and have them rate 10 percent of the list daily of 10 days. Try to make this as unobtrusive as possible. But speed is important. This should be completed with a two week period. The data entry should be complete within and additional week. You may need to hire a temp to accomplish this, but at this point speed of execution is critical.

Concurrently, data from the first mailing should be entered as well. Mail pieces with undeliverable addresses need to be purged or corrected. Responses need to be entered as well. Simply add a column in the spreadsheet for First Mailing Response and put an x or a data in it. We'll use it in a bit.

I guess I should mention that if you have access to historical data in your system that you should use it only if you can get at it quickly and without outside help and you can get it into the spreadsheet with the rest of the data. Your relevancy marketing database should include more than just current customers, but prospects, suspects, etc. Again, at this point speed of execution is more important than accuracy- that will come.

 
http://rpc.technorati.com/rpc/ping