Estimated Age Range Data Entry

Options
Kristen Noe 2
Kristen Noe 2 ✭
Seventh Anniversary Facilitator 1 Photogenic
in Blackbaud Raiser's Edge NXT®: General Discussion
Our new direct mail company provided us with age append data that is an estimated age range of 10 years, i.e. "65 - 74" rather than a birthday like we were expecting. I am guessing we will get this data from them annually (if we keep the same company). Does anyone have a best practice for where to add and track this information in RE?


My thought was to treat it like a wealth screening and add it as a Rating in the Prospect tab, and/or an Attribute. But for the Date of the Attribute, my debate is whether to use the append date - or put a fuzzy date to estimate the age off of, like the middle year of the estimated DOB range. Then the comment can have the range and date of the append. We already overuse Attributes and I'm not thrilled with the idea of adding another one with each age range append. If used in conjunction with the Ratings, the Attribute could just be updated each year with the history of it kept in Ratings?


Thanks in advance!
Tagged:

Comments

  • Kristen Noe 2
    Kristen Noe 2 ✭
    Seventh Anniversary Facilitator 1 Photogenic

    Dariel Dixon:

    This is an interesting conundrum.  I'm not a fan of entering this information as the age ranges are so broad.  Also, ages are calculated figures in RE.  The system will determine your age based off the current date from the listed birth date.  I would definitely reconsider adding this appended data again from this company if it were an additional fee.


    You are creating a situation where this information would have to be manually updated.  That sounds like a process.  Birth dates are troublesome nowadays due to privacy concerns, but an age range...is so broad that it may not be as helpful as you would think.  You have no idea when the birth date may be?  Or honestly where the person falls within the date range.  Do you have a plan for how the data is used?  I'm not sure if you should try to enter this data as constructed, and try to find a place for it.  


    It would almost have to go into attributes.  I don't think that ratings is the best place for it.  

    I appreciate the input, Dariel! Agreed having such a broad date range isn't ideal. The cost would be included in our contract with the company, and they pay for the less expensive data which just gives this range. They did the age append for a planned giving mailing. We want to add it to the records in case we'd like to try another mailing without this direct mail company in the future (most likely another planned giving one) , which is why I was leaning towards a date we wouldn't have to think too hard about later. But that's about as far ahead as we've thought at this point.


    Thanks again for your response!

  • Christine Cooke 2
    Christine Cooke 2 ✭
    Ancient Membership Facilitator 4 Name Dropper Photogenic
    I agree with Dariel.  And unless you know it will be used in some way there is really no reason to add it.  This type of info just makes everything muddy.  Ten years is a huge span when it comes to ages.  It puts folks in two different generations.  Attribute would be the place to put it, with the description being the age range and the date being when this info was collected.  If you HAD to put it in.
  • Ryan Hyde
    Ryan Hyde ✭
    Tenth Anniversary Facilitator 3 Name Dropper Photogenic
    I get similar data from one of our vendors (no additional fee, just part of the service). I add this as an attribute, and I add the date reported to the date field of that attribute, exactly as Christine Cooke bCREPro suggested. I find it marginally useful on occasion, and the import is very easy because the report I get from them already has our constituent ID # associated with each person, so it gets imported along with a few other datapoints that go in as attributes (education level, family size, etc.).
  • Bob Wiebe
    Bob Wiebe ✭
    Ancient Membership Facilitator 1 Photogenic
    These are good thoughts.

    I have used an attribute called "estimated age range" with a description "estimated birthday". In the date column I entered the midpoint of the age data I had available. That data consisted of guesstimates from the rest of our team about the approximate age of a list of donors.  By using a hard date as the estimated birthday one does not have to update the information.  Admittedly, this data has only been used once to date. If I recall, we used it to compare giving on a generational basis. For that it was useful.
  • Kristen Noe 2
    Kristen Noe 2 ✭
    Seventh Anniversary Facilitator 1 Photogenic
    Thank you all very much for the responses! My team will decide what we want to do this week, and your input will be very helpful since most of our team is new to RE, our org, or both!
  • Heather MacKenzie
    Heather MacKenzie ✭
    Tenth Anniversary Facilitator 4 Name Dropper Photogenic
    Just finding this thread today, Kristen Noe‍ and I am curious what you ended up doing.  I have another idea on this too, and that would be to not even put the dates in at all, but define who your group is for the planned giving mailing is and then add that appeal or attribute.  I'm also not a fan of having something that needs manual updating.
  • Kristen Noe 2
    Kristen Noe 2 ✭
    Seventh Anniversary Facilitator 1 Photogenic
    Sorry for the delayed reply! That's basically what we ended up doing: just adding an already existing attribute to the records based on what we were using it for - Bequest Prospect. I included in the Comment a short note about where it came, and we can to reference back to the original file if we need to.

Categories