Editor’s Note:

More and more organizations are using a variety of software applications to meet their fundraising and activist needs.  Perhaps a CRM for the main database of record, then a digital application for advocacy, another for social media, an additional one for major gifts and yet another for events.  

All too often this mashup of  software systems fails to meet  the need to get all pertinent data accurately into a centralized location so it can be used in an actionable way.  Then  frustration takes over with the tendency to throw up our hands and blame either the vendors or colleagues in some other silo.

This all-too-familiar scenario occurs because serious focus on data and the integration of software applications rank quite low on the totem pole of nonprofit management concerns.   The result of ignoring fundamental data issues is evident in flat or declining results, poor retention rates, and rising frustration among staff and vendors.   

Consequently, we’re devoting this week to a series of posts by Ilya De Coster, DonorVoice’s Director of Data Strategy. The goal of the series is to provide Agitator readers with an overview of key issues when it comes to data, the integration of data systems and practices that can harm or enhance your fundraising.

        –Roger

———————————————

I’ve spent my entire professional life in fundraising.  Some people (ok, almost everybody) calls me a data geek.  Instead, I like to think of myself as an information geek.  There’s a distinction.

After all, Anheuser-Busch InBev doesn’t consider itself in the barley or hops business; it makes beer. In fundraising data is our raw material: our barley and hops.  Information is what we transform data into. Thus, I am to be in the information business.

We are awash in data raw material. So much so that we’ve stopped counting some of it and just call it “big data.”  Take a walk; your watch counts the steps.  Drive your car; the traffic cams track you.  Use the web; leave thousands of data bits tracking your interests on servers around the world.

It’s not the collection of the data that’s important, though.  It’s what we do with it.  If engineers and planners don’t bother to collate and act on the traffic cam data, it’s not worth recording.  More to the point for us fundraisers, if our data is all in separate databases and we don’t –or can’t—gather it in one place and are able to analyze it as actionable information, it’s all for naught.  It’s like handing your guests separate buckets of hops, barley, yeast, and water  when they come over to watch football – it’s the combination and processing that’s important.

The effort of gathering and combining data into actionable information isn’t something we can afford to ignore.  Roger talked about how a one percent decline in the quality of donor address data quality can compound to cost an organization with 10,000 donors $50,000 (about 45,000 Euros) over a 5 year period.  As you’ll see in a minute there are other even more significant real and opportunity costs to poor data systems and poor data hygiene.

So what can you do to turn your data systems into actionable information?

No data system should be an island.  If you use multiple systems to collect data, in the absence of a final, centralized location for storing that data,   there will always be data that is missed and data that can’t be turned into information.  One nonprofit I know of wanted to make sure that a certain type of constituent was suppressed from all mailings.  The keepers of this constituent data didn’t trust the master database so they would not release that data.

Of course this is a stupid and damaging rule – donors should be able to decide their own communication preferences.  How can you make sure people don’t get a communication if you don’t know who those people are?

This doesn’t necessarily mean having only one database; it means having one data ecosystem.  You can have separate specialized systems (a CRM, an analytics server, a visualization server, a payment processing system, a call center’s software, an emailing tool, an automation engine, your DonorVoice feedback platform, etc.)  These tools, however, must be able to communicate with each other through syncing and API connections.

Blaze the trail, then pave it.  It is boring, stupid, and time-consuming to export comma-delimited files from database one, clean it up, and import it into database two.  (By the way, use semicolon- or pipe-delimited, not comma-delimited, files when possible; too much data has commas in it already, so things go bad quickly.)

It is also, sadly, a necessary intermediate step to getting full syncing of information.  Do this a few times and you’ll be able to tell your programming/IT resources all the peculiarities of the data, which will allow them to automate what you are doing, using what the data geeks refer to as ETL:

• Extract: pull the data out of where it’s coming from
• Transform: make whatever changes are necessary. For example, Facebook lead generation puts “z:” at the beginning of postal codes, so you have strip out this data for most CRMs to accept it.
• Load: put the data in the proper place where it can be easily accessed.

ETL processing is the standard by which any organization that considers itself data-driven should live, but to live with CSV file syncs is to introduce data error into the process and burn out your employees.  Use this step as a step, not a resting place.

Own all your data and the process for gathering it.   All of it.  A staff member will offer to do the necessary syncs for you manually.  Don’t let them.  You will be locked into and unnecessarily dependent on that person– even if they start making fish in the microwave.

A vendor or agency will offer to store all your data with them.  Don’t let them.  You will be locked into their system forever, with them taking hostages like your monthly donors.

A vendor will offer to report on your data for you and keep the raw data to themselves.  Don’t let them.  Even a great vendor doesn’t have the insight you have into all your processes.  You should be managing agencies’ data and reporting back to the agency on how they are doing, not vice versa.

Owning data — really owning it, by which I mean having access and the ability to deny others access – is key to being data driven. Data hijacking is a key topic in our sector and I’ll cover that in future posts as well.

Map your process.  You need to know how and when data is going to move from place to place.  You need to make sure a system isn’t overwriting good or recent data with bad or old data.  If you have your master database taking in data at 1 AM, you need to make sure it doesn’t send data out until it has all its data in.  Speaking of which…

Data should go in and out.  Some organization will have one central database into which all data goes, but then it stays there with no external communication.  Each sync needs to be two-way.  One organization I know of does Face-to-Face at-the- door fundraising.  Because their data system doesn’t consolidate and deduplicate data from last year’s recruitment with this year’s recruitment, they are recruiting the same donors this year who signed up, then cancelled immediately, last year and the year before.  And they are paying for the privilege in time and money, turning what should be an acquisition program into a cost-prohibitive reactivation one.

Use reports for report things and dashboards for dashboard things.  A report is static versus a dashboard, which is real-time.  Thus, a report is good for lagging indicators – how did we do toward meeting our goals.  A dashboard should give you insights for early intervention – before things ultimately go wrong. No sense in collecting insights if we don’t do something with them. And once the reports says we did badly, it’s often too late to act upon it.

Visualize results.  Not everyone is a data/informational geek.  The Agitator has talked about using stories to explain concepts to your boss just like you use them to explain mission to your donors.  That’s not bad, but visualizations are extremely helpful as well.  It’s easier to see which bar is higher or that it’s better if your line goes up and to the right.  (But be aware — it is so easy to create misperceptions with poor use of data or visualization of results.)

Remember why you are doing this. You are not doing data processing for fun.  You are doing this because turning data into information is key to donor experience.  Think about two organizations with which you’ve lodged complaints.  One solves your issue in 24 hours; the other gets to it when they can, if at all.  Running tests, customizing messaging, focusing on the donor: all of these require data systems that can get you information immediately so you can execute on it immediately.

If you’d like more detailed information on any of the issues I’ve covered in this post, just let me know in the Comments section or shoot me an email at idecoster@thedonorvoice.com

Ilja

P.S.  On Wednesday I’ll deal with the need for speed when it comes to data and donor information.