“Data is the key to managing your membership base” – or is it?
For years, vendor partners in the association management system (AMS) industry have told us “the key to managing your membership is in your data.” They proceed to go off into a lengthy and detailed explanation of how their system can help unlock your data, including some nice verbiage like “analytics, engagement scores, reporting and business intelligence.” All very useful concepts and driven many of us to pay more attention, attend sales webinars, watch demos at trade shows, and seek the answers to unlocking our membership management through our data.
To further exemplify the need and desire to manage membership data properly, do a Google search on “types of data integration approaches,” and it will present you with over 390 million results. Do a second search using “older types of data integration approaches,” and that number more than doubles to 803 million hits. This tells us that we’re not alone in the association industry when asking how to access our data.
The lock and key analogy
Let’s use the analogy of a lock and key to dig in further. I contend that the data is not the key – data is the asset! The problem is that the assets (data) are locked away in a storeroom (AMS), and we can’t get to it. Furthermore, the storeroom is tedious to dig through, not well organized, and often outdated. The standard AMS used by many of us for years was not created to be a key or a lock; it was made to be a storeroom behind the lock sealed almost too tight. Antiquated and proprietary web services and manual extraction (download as a CSV) are tools that we see throughout associations and membership organizations to retrieve and push data. But are these methods really “unlocking” your data? And what actually is the key to your data?
In my opinion, we shouldn’t be locking data away at all. Secure it, yes, but unused data is a missed opportunity, and we’ve been missing it for years. Let’s start at the top of the membership data stack and work our way down.
Connecting data in your technology ecosystem
Either via self-service by your members or via your staff, information in the form of data records is collected, created, managed, updated, and sometimes deleted in a technology system you utilize. Many times, there are multiple systems in what many of us call our technology ecosystem. The information is broken down into tables, records, and fields within databases that reside at the very bottom of these technology systems. In most cases, the technology managing these databases are very intricate ecosystems of their own.
The AMS has a database, the event management system has a database, the community platform has a database, the eCommerce system has a database, the website’s content management system has a database, and so on. Each database has its own schema (way of storing data) and governance rules (how to store it, when to update it, what to do with outdated records, security, etc.). I detail this out so you can understand a very prominent but overlooked fact: the data is there but within each system and platform. In many cases, the problem isn’t that we lack data; but rather, we can’t view the data collectively, in the same place, and therefore utilize it.
The challenges of managing data in an AMS
As I discussed in another blog post, the AMS was supposed to store all important data together in its database. No matter what system the data was created in, if it’s part of the 360-degree view of our members, it was supposed to be in the AMS. The developers of these AMS systems did build-in technology, such as data exports, imports, and web services to access data structures via coded objects. But these methods are not easy to use, and unless you have a database administrator who can build tables and structures, having imports doesn’t make the data useful in the system.
Had everything worked the way it was supposed to inside the AMS, member data, along with the rest of the AMS data, should have combined seamlessly in reporting and dashboards to give us what we needed to know. The challenge is that if the data is not of the structure (remember the word schema above) governed in the AMS, the data becomes extraneous tables in the AMS. Those additions become customizations, and now we are making a system do something it wasn’t developed to do – be a data storeroom. You’ve heard the term before. Modern versions of the term include data lake, data stream, data mart, and otherwise known as a storage repository. Guess what that is at its core? Another database.
To summarize, to get access to your data within an AMS, modern thinking is that you copy the data out of all these silos within your technology ecosystem and store it someplace else. Again, the data is secure in its storeroom, but you will need to investigate options for a data lake or repository to pull in the data to utilize it.
Connecting data using business intelligence (BI) tools
Some of my colleagues might say that I missed another way to get to the data – by utilizing modern business intelligence (BI) tools to connect the data to where it is housed and create information from those disparate databases. And they would be mostly correct (albeit not about me missing anything). The caveat is that the BI tool pulls a copy of the data back to its own data storeroom to do the work. Because, again, we must apply the database laws of schemas and governance. So to be able to use the data without those limitations in the system of record, we have to copy the data someplace else.
Retrieving the data in order to utilize it
The bottom line is that we have two ways to retrieve data so it can become information to help us manage our businesses:
- We get the data into the AMS system, and I mean all the data, or
- We understand we must have a copy of the data outside of the AMS, including all the other ecosystem pieces, to build structures to truly integrate the data.
In the last several years, the industry has seen the proliferation of businesses and products doing just this. They have built integrations, where possible (don’t get me started on API access fees), and processes to extract the data from proprietary databases and copy it to their data storerooms. As a result, business intelligence, reporting, data visualization, and even a new breed of systems called Integration Platform as a Service (iPaaS) has access to that data, making it the tool we need it to be.
Data isn’t the key – making it usable is.
Let’s return to the analogy we started with that begged the question: What actually is the key to your data? The answer is there really isn’t one key; it’s a whole ring of keys like your third-grade janitor used to carry.
But what if we could find a way to bring the data we need back into our membership management system (MMS)? What if interactions from all those disparate technologies in our ecosystem caused a notification to our MMS that new or updated (changed, deleted) data was available and attached to a membership record? In that scenario, when we receive a member inquiry and pull up their record, we could see an accurate 360-degree view of the person. We might have an up-to-the-minute engagement score or notice registration to our annual meeting or a webinar that happened just a few minutes ago. In another scenario, a member updates their email in our MMS and simultaneously updates their email in our marketing automation tool, so now tomorrow’s newsletter will still end up in their inbox. Doesn’t that sound like a far better use of unlocked data?
Maybe the answer is in the middle ground somewhere between my two methods of data access. In any case, data isn’t the key; making it usable is. To achieve this, it may mean it’s time to upgrade your storeroom (or membership management system) to one that remains secure but more organized, easy to use, and up-to-date. So ask yourself, does your current system allow you easy access to data for reporting, business intelligence, visualization, or the like?