12 Data Best Practices Slide Presentation (1).pptx

1. Data Best Practices
Tips for collecting and storing data so
that it remains useful, readable, and
portable.

2. 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.

3. 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
Required to do business.

4. 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
“Why do you need to know that?”

5. 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.

6. 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

7. 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.
Be practical and consistent.

8. Storing Names
Hon. Teacup T. Samplehouse III, EdD
Title
First Name
Middle Name (or Initial)
Last Name
Suffix
But also…
Nickname/Informal Name
Format for mailings
Format for public acknowledgement
- 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.

9. 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.

10. 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.
Email addresses should be unique identifiers.

11. 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

12. 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.

13. 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.

14. Questions, comments, or
clarifications?
Megan Mooers
Data Solutions Manager, SKC
meganm@supportkc.org
913-396-8349