Skip to main content

We're looking to start sending happy birthday messages to our customers and currently have a "birthDate" field that is populated in our instance with MM/DD/YYYY format, but it is a string field, not a date field. Any thoughts on how to dynamically check a string field against the current date to trigger a message send every morning? Best I could come up with is creating a month and a day field on profile table and then creating 12 journeys, 1 for each month and then after they enter, run through an up-to-31 day logic check before firing off the email, but that seems pretty tedious and I imagine there's a better way to do this with RegEx or the like. Has anyone else gone through this exercise?

Hey Matt Calnan - You can definitely do something with segmentation like you suggest, where you use RegEx to check the string. One thing that might reduce overhead is doing 'birthday week,' where you can check the RegEx for 1-10, 11-21, etc. for birthdate.

Is there any way to change the 'birthDate' field that you're sending across so that it's passing as a date field? You'd have to establish a new data point (maybe 'dateOfBirth') but that might help.

As an alternative method (and this is probably the one I'd do), you can create a specific Workflow where you take your birthDate string and convert it into another profile value (ex. dateOfBirth) that is in a date format. Using the Update User Profile tile, you can do something like: {"dateOfBirth": {{dateFormat birthDate MM-dd}} -- (Though definitely test this for proper formatting!)

That would give you a date field that you can use in a segmentation, where your dynamic segment can just be, "dateOfBirth IS EXACTLY now/d", and would let you just have a single journey to support it.

(hat tip to Emily Benoit )


Abigail Gailey Thanks for the suggestions! I agree, I think the RegEx approach with string fields is going to be a bit convoluted and given my relative inexperience with regEx, probably prone to breaking, even though it could be made to work.

It'll definitely make my life easier with a new field cast as a date type, I'll go that route. Thanks for the thoughts & comments though!


Matt Calnan - one other note, not sure what industry you are in that the birthdate is stored with the year or why it is needed, but best practice for PII is that the year should not be stored with the birthdate. One of those pieces that is sensitive if there is a data breach. Once converted delete or null out the field with the year.


Reply