Data Best Practices

Growth Exchange

Tips for collecting and storing data so that it remains useful, readable, and portable.

What to collect?

– What you need.

‐ Information you are obligated to collect, by necessity to supply services, or by law.

‐ What you will use.

‐ Data that is recalled and referred to by the organization.

‐ What you can gather consistently.

‐ Information you can obtain and process easily.

Collect the data that you need.

The basics ‐ common fields found in most data‐related software
‐ Contact Information
‐ Donation Information, and any other Financial Transactions

The specifics – items fundamental to one org’s operations, services, and/or funding
‐ Custom fields have to be created
‐ Information required by grants
‐ Donor/donation information
‐ Constituent information
‐ Grant obligations
‐ Information used to provide services

Collect the data you will use.

‐ What you will use directly:
‐ Contact information
‐ Attributes that allow for targeted messaging

‐ Reporting data relevant to the org’s mission:
‐ Data which describes the population you serve,
such as age, income bracket, or census tract.
‐ Specific metrics to quantify the work you do, ex:
employment status, or completion of a class.

‐ For a specific purpose.
‐ Data used to examine and evaluate your programs
‐ Data used to provide services

Collect data consistently.

Record data points that can be gathered easily and regularly.

Most stored data will change infrequently.

A regular system of collection and input must be in place.

‐ Planning. Work.

‐ Tech Tools.

Not only a matter of collecting, but inputting.

Adopt consistent styles and conventions that will be applied throughout the
database.

Collect data you can secure.

Common sense data security ‐ Be a good steward of the personal and private
information you encounter.

‐ Password protect access to your data

‐ Use secure networks

‐ Lock up paper

‐ Comply with the law

‐ Certain personal information, such as SSN,
medical records, or financial account information,
is required to be kept confidential and secure

‐ Utilize permissions and access control settings

‐ Perform regular backups

Compound Fields

Some common data fields are composed of smaller pieces of data.

Hon. Teacup T. Samplehouse III, EdD
123 Main St Apt 506b
City, State 12345‐6525
(516) 555‐1234 x 83

What is stored separately vs. together depends on how
the data will be used.
If you’ll never use one piece without another,
Store the data together. Ex: Area Code + 7‐digit Phone
Unless you will need to refer to one piece separately.
When in doubt, store the data in separate fields. It’s easier to combine than to separate.

Storing Names

Hon. Teacup T. Samplehouse III, EdD Title But also… First Name Nickname/Informal Name Middle Name (or Initial) Format for mailings Last Name Format for public acknowledgement Suffix ‐ Where known, store full names. The first name is “William,” the nickname is “Bill.” ‐ Different cultures have different naming conventions. Try not to guess about what the middle name is. Where possible, get clarification. ‐ Group double first and double last names together. “Billy Ray” is 1 first name. “Lopez Alvarez” is 1 last name. ‐ Leading initials should be stored with the first name.

Spouses and Partners

Nobody’s first name is “Bob & Jan.” Spouses and partners should have separate, linked records. • In most cases, it’s a good idea to cultivate organization relationships with both members of a couple. • Relationship management software will have mechanisms to link two members of a couple together. • For spreadsheet/database users, include a reference field for one spouse’s unique identifier on the other’s record. Styles of address (envelope and informal greetings) can be customized to include both names, but any given record must belong to 1 individual.

Unique Identifiers – One Per Person

A unique identifier is a piece of data that no other record has, which can be used to index that data. Ex: A row number, or a record number generated by software. Unique identifiers are used to connect related records, as well as to encapsulate data related to one person or organization. There are many software functions that depend on the uniqueness of these identifiers. Systems can easily break if duplicates are found. Some systems will not allow duplicates at all. More accessible are the email and mobile phone fields. ‐ Avoid assigning an email address to more than one person. In cases where multiple people do share an email, assign it to just one of them. ‐ Most software integrations expect that the email address will be a unique identifier.

Address Formats and Conventions

An organization should establish its own “style‐guide” for collecting data. Items to consider: Street Numbers and Directions: W 54 St vs. West 54th Street ‐ Do not drop the street type. Abbreviations: When to use, how or if to punctuate Address Line 2: Apartments, Suites, Units, #s State: Abbreviate it Zip: Some software cannot accommodate zip codes that aren’t exactly 5 numbers

Address Validation

Another free service of the USPS: https://www.ups.com/address_validator/search?loc=en_US Other APIs, including Google Maps, make use of CASS (Coding Accuracy Support System) to validate addresses within software. Organizations can also pay to validate their data in a batch process. There are a number of CASS‐Certified vendors, such as Smarty, or Accuzip. A vendor doing mailings for an organization should have an address validation process.

Notes and Uncertainties

Create or utilize a data field designated for free‐form notes about a record, and use it to capture questions, uncertainties, or any data that doesn’t fit elsewhere. Do not record questions, comments, or extraneous markings in any other field. In a best case, you’ve recorded data that is useless. In a worse case, it could cause an embarrassing or offensive error. ex: “Dear Meagan/Meghan sp??,” ex: “Mr. Robert (DECEASED 5/14/02) Smith (DECEASED 5/14/02)” It is difficult to catch bad data when it is hidden in another field. All of the data validation and checking and formatting rules are designed around expected values. Completely unexpected values can evade common software checks, meaning the only way to catch errors is manual review. This is a case where an ounce of prevention is worth a pound of cure.

Change Your Mind

What would you like to learn about next?

Is there anything you’d like us to cover in an upcoming Growth Exchange? Be as general or descriptive as you’d like. Your feedback helps us find experts that address your concerns. It also helps our presenters with ideas on what to add to their presentations.

Subscribe to the Growth Exchange

Sign-up to get our Growth Exchange newsletter. Find out what topics we’ll be covering. Get updates on any changes. Get calendar invitations to each of our presentations. And get value recaps after each session.

Growth Exchange