Decoding Database

Decoding Your Database

A good fundraising database will contain not only biographical and gift information about your supporters, but should also contain other pertinent information that can help you tailor communications to make them more personal. This information might include volunteer contributions, events they’ve attended, areas of interest and mailing preferences.

A lot of fundraising databases, however, also contain fields and code tables with other information that is frequently used to generate mailing lists or segmentations. My challenge to you this week is to look at some of these code tables to determine if they contain extraneous or redundant information. It’s not that this information isn’t important to your organisation and your DM/Communications programs, but can you find the same information in another field already in your database?

Some common examples of fields which may not be necessary or may already be recorded elsewhere in your database are:

•    Frequently I see databases that have some kind of a code against a donor indicating whether or not they are an individual or organisational donor, even though that information is already recorded in the supporter’s record type.

•    A lot of supporter records contain a code indicating simply ‘Donor.’ Do you need a separate code to determine this, or can you look for donor records that have made at least one gift?

•    Are you recording mailing preferences by including all mailings that a donor wants to receive, or are you only recording the ones they have opted out of? It would be much more efficient to assume supporters are willing to receive all mailings until they opt-out, at which point you can report that on their record.

Again, I am not suggesting that all information you have on your database isn’t important to the work you do. In an effort to make data entry and list selection as easy as possible, I am suggesting you look at what information you require and if it is currently being entered in more than one way.