Hi all,
We're in the process of working with Experian to do our first NCOA in many years. For our first pass at this process, we've opted to NCOA as many records as possible in 4 rounds. We have roughly 3,000,000 records in our database and I'm curious if any of you have insight/experience/advice about the following things:
1. How many years back should we consider casting the net for lapsed ticket buyers? Is there a standard number of years that acts as a reasonable cut off point?
2. As a follow up, what if we exclude certain ticket buyers based on our cutoff who engage with the museum post- NCOA, and don't have an updated address? How common is this and any recommendations for dealing with that?
3. Any further recommendations about how to segment records for an NCOA of this scope?
Thank you!
Kristin
When we transitioned to Tessitura in 2020, we decided that we only needed to put three years of ticket buyer data into scope. Our thoughts were, if you hadn't transacted with us in the past three years, we didn't need to invest in ensuring that transaction data that was older than three years was included in marketing communications. We continue to use this metric when targeting lapsed ticket buyers.
As for NCOA, we put all constituents into scope for NCOA. All to us means all constituents that are not deceased, inactive or in a special category (i.e. - VIP donors). We handle VIP donors and the like, manually.
As for your follow up, as I said above, we don't base our NCOA on engagement per se. That said, your file is quite large. Segmenting by year or by some other metric might be a good way to ensure things run smoothly. Maybe segment by calendar or fiscal year and start with constituents that have not transacted in X years (oldest engagement to newest engagement) and progress year by year. For instance, start with constituents whose most recent transaction was five years ago for the first file. Next, create a file with constituents whose most recent transactions were four years. Continue this until you get to the current year. Doing this will ensure you have a chance to understand the sizes of the data sets and how the process is affecting the data once you get to the most recent. By this time, you'll know if you want to segment the files into a smaller set or if you need to use a different selection criteria.
I will also recommend that you do ALL of this in your TEST (or similar) environment first. We always run our NCOA process in DEV first before we run it in PROD (we use DEV because we use it as a volatile environment for development, our TEST environment is used for stable development releases and we don't consider NCOA a stable process). We QA the process in DEV by taking a standard deviation of records after the vendor has completed the NCOA process on them and review them. This is usually around 1,000 records. Our data team scrutinizes the records to ensure things look proper.
Good luck and feel free to reach out with any other questions.
Kristin Nyquist said:We have roughly 3,000,000 records in our database
That's a lot!
Kristin Nyquist said:1. How many years back should we consider casting the net for lapsed ticket buyers? Is there a standard number of years that acts as a reasonable cut off point?
That's a good thought, especially for a database that large. I don't think there is a standard, you might want to try to figure out a number that makes sense for your organization, perhaps by looking at the longest gap in engagement for your customers (in some nice round number like years) and then see what the curve is for that engagement gap. If you have small but significant count who had, say, a six year gap then you might want to go back at least that far.
We have about 800k, and I've never restricted the list based on engagement. I've been looking at that a bit, when we came on in 2004 I think we wound up importing decades of prior data, so we have a lot of customers who probably haven't engaged with us in this century, or even at a time when a computer would have been involved.
What I do limit is Address Type: Generally only "Home Address" or variants.
Kristin Nyquist said:2. As a follow up, what if we exclude certain ticket buyers based on our cutoff who engage with the museum post- NCOA, and don't have an updated address? How common is this and any recommendations for dealing with that?
I'd think about how that engagement might look. In theory if they buy or donate online they will at least see their address there, although they might skip over it without looking if buying an ETicket (almost all of our business now). Likewise, if a cashier is taking their order, would they ask to confirm their address?
Kristin Nyquist said:3. Any further recommendations about how to segment records for an NCOA of this scope?
I dislike the way the Tessitura handles the data returned from an NCOA update. It's been a long time, but if memory serves:
I don't like either. As a University, we're often interested in being able to see how customers evolve with us based on their past residences. Also, this can distort reporting: "Gosh we had a bunch of people on the East Coast buying tickets to these student-oriented events in 2010!". No, they were students in Berkeley at the time, and have since moved back to their original states. With deletes, we lose the original Address Type.
What I have built (not currently working for a couple of reasons, but soon! Maybe!) is a system that creates a new address on a Move action, which is then flagged as primary. Then the old address is inactivated and marked with a Contact Point Purpose that declares it either an NCOA Move or NCOA Delete.
I have a similar SQL system (that is working as of 15.2) that creates a new address, marks it as primary and then changes the former address to an "NCOA Old Address" type and marks it as inactive. I also dislike overwriting existing data for the reasons you state.
Agree with everything else Gawain Lavers and Phillip Parks say about segmenting and so forth.
We go back six years, for any donor, creditee, subscriber, or STB. We send around 200k constituents each quarter.
John A. Moskal II said:I also dislike overwriting existing data for the reasons you state.
Agreed. Like some of you, I think, I also run custom SQL for the NCOA "process" step, and move addresses that that process would overwrite to a new, inactive address set to a custom "Bad Address (fr. NCOA)" address type. Overwriting address data is bizarre and unacceptable.