• Replies 4 replies
  • Subscribers 337 subscribers
  • Views 53 views
  • Users 0 members are here
Related

Fuzzy Dates in Attributes

Galen Brown
$organization

Has anybody implemented any attributes that allow for fuzzy dates? I'm trying to find a way to handle the fact that we don't always know things like birthdates precisely.

Our current practice is to use January for an unknown month, and the 1st for an unknown day, so:

  • If we know you were born in 1950, your birthday is set to 01-01-1950
  • If we know you were born in June of 1950, your birthday is set to 06-01-1950
  • If we know you were born on June 14, 1950, your birthday is set to 06-14-1950

This has the advantage of allowing the data type to be a date, but the problem that you there really are people born on January 1st and June 1st, and we can't tell the difference.

One option would be to set up a second attribute that stores the known level of precision, but that gets messy, both on the list building side and on the data entry side. Especially since there's no way to link two attributes and require that if you have one you have to have the other.

I would really like the attribute to work with the date picking tools on the front end, if at all possible.

If there's no way to do it in an attribute, I'm willing to consider putting it in a custom screen.

Anybody have any brilliant ideas? Anybody done it before?  Thanks!

Parents
  • $organization

    We use two attributes:

    ·         Birthdate_1 for the actual birth date

    ·         WE age append (most of these came in via Wealth Engine) for approximate birthday along the lines you set out

     

    Thanks to “or” in list pulls, it’s easy to get anyone who has both or either of these attributes. Let’s say I want to get all the people in my database who are under 60. I’ll arbitrarily set 1/1/1955 as the birthdate to use.

     

    Here’s what the list setup looks like for my list Born 1/1/1955 or after:

     

    Criteria                                 Operator             Value

    Birthdate_1                        >=                           01/01/1955

     

                                                    OR

     

    Criteria                                 Operator             Value

    WE age append                >=                           01/01/1955

     

    Lucie

     

  • $organization in reply to Lucie Spieler

    Lucie--I can see the argument for doing it that way if data from one source (e.g. Wealth Engine) always has one level of precision, and other data always has a different level of precision, and you want to keep those data sources distinct. But in our case, my priority is having everything in one place. That said, you've made me think about the value of capturing the source of the data, since we do sometimes get age append data. If we end up putting birthdate in a custom screen, I may add a field for birthdate data source.

Reply
  • $organization in reply to Lucie Spieler

    Lucie--I can see the argument for doing it that way if data from one source (e.g. Wealth Engine) always has one level of precision, and other data always has a different level of precision, and you want to keep those data sources distinct. But in our case, my priority is having everything in one place. That said, you've made me think about the value of capturing the source of the data, since we do sometimes get age append data. If we end up putting birthdate in a custom screen, I may add a field for birthdate data source.

Children
No Data