When merging databases from different centers we've found duplicate/triplicate records. Obviously we need to merge records.
Does anyone have an opinion regarding which record takes priority? For example, do records with ticketing or donor information take priority over records with more limited information? If you can share your thoughts regarding prioritization orders (or anything we need to look out for), we'd be grateful.
Thank you. I will also post on the Marketing Forum.
Elizabeth Weisser / eweisser@92y.org / 212-415-5596
When I merge records, I usually merge them into to the record has the most information. If the older record doesn’t have much information in it, I merge it into the newest record. I do have one group that has requested that if the record has their season orders in it it takes priority so that the constituent number stays the same. The ticketing order usually takes priority over the donor ones. I have found that, for the most part, donors usually have lots of tickets in their records.
Trudy Guest,
ArtTix Systems Administrator
801.323.6969
Hi Elizabeth
Our consortium established a cascading hierarchy of rules controlling which record is allowed to be the Keep ID.
1. Ranking based on Constituencies
This was mainly done to establish the relative ‘value’ of Constituencies for each partner in our Consortium (as in ‘my board member is more important than your subscriber’).
While the need to establish strata of like Codes across organisations is unique to a Consortium, the principle could apply to single orgs just as well.
We prioritise these ‘important’ records on the assumption that their address and other details are likely to be more complete and well-maintained than casual ticket buyers etc
2. Transaction recency
If Ranking is the same on the two records (or if both have no Constituency ranking), then transaction recency is the next priority.
3. Activity recency
If transaction history is the same, or both records have no transactions, then “Activity” recency (i.e. the “Activity”/”Elevated Events” functionality) is next.
Otherwise let the person scheduling the merge choose.
Regards
Peter
Peter Nelson
Business Analyst, Information Systems
T 02 9250 7180 M 0401 714 246
Sydney Opera House Bennelong Point
GPO Box 4274 Sydney NSW 2001 AUSTRALIA
Unknown said: Does anyone have an opinion regarding which record takes priority? For example, do records with ticketing or donor information take priority over records with more limited information?
Does anyone have an opinion regarding which record takes priority? For example, do records with ticketing or donor information take priority over records with more limited information?
Since all of that data will be preserved in the merged record, we usually merge into the oldest record to hopefully reflect the length of the patron's history with us. We used to be on a system that wasn't easily able to find records based on the "delete" id if the patron supplied that, so we had to be more circumspect, but with Tess that isn't really a problem.
I think its safe to say that MOST data will be preserved but some is not transferred to the "keep" account in a merge. For example, N1 and N2 and Mail/Phone/Emarket Restrictions in the General tab are not transferred from the "delete" account to the "keep" account.
I recommend the document on this subject:
http://www.tessituranetwork.com/network/Learning/Documentation/General/Managing%20Duplicate%20Constituent%20Records.aspx
Unknown said: I think its safe to say that MOST data will be preserved but some is not transferred to the "keep" account in a merge.
I think its safe to say that MOST data will be preserved but some is not transferred to the "keep" account in a merge.
Correct. I meant to comment above re:our practice for choosing the "keep" record, and not to suggest that 100% of the data from a "delete" record is retained in the "keep". In addition to the fields you list, differences in the default salutation can be lost in this process. It doesn't hurt to check Association names, either.
Also bear in mind that an Attribute will not be transferred from the DELETE_ID if the KEEP_ID already has that attribute. For this reason we always merged into the newest record with the reasoning that the latest record PROBABLY has the most up-to-date information. For us here in Aus, this is particularly true when performing searches based on email address or mobile (cell) number due to the propensity of the (presumably younger) audience that tends to move physical address due to their being in the rental real estate market.
It does help that we're weaning people off being wedded to a particular CUSTOMER_NO.
Martin
Oh - and the "Original Source" that gets kept is that of the DELETE_ID and not the KEEP_ID (annoyingly) although someone may have amended the merge routine to correct this.....