... add a custom field "Product X Subscribed Date" to go along with the boolean T/F.
But if you're not also updating the DateTime when someone flips to false, then there's no need for the Boolean. I'm talking about having only a DateTime, not both.
On the other hand, if the DateTime also is updated on the Unsubscribed Date -- functioning as the Last Product X Subscription Change Date as opposed to only the Last Product X Subscribed Date -- then you do need the 2 fields, since that can't be reflected with just the DateTime.
Thanks for following up because I read your blog post several times and realized I don't know near enough yet to proceed. So thank you for not abandoning me. This is an invaluable lesson and experience to add to my skill set.
But if you're not also updating the DateTime when someone flips to false, then there's no need for the Boolean.
I am actually. If Product X gets 'Canceled', it is System.Date stamped and 'Product X Subscribed' changes to False. The custom fields I created (again per Jay Jiang many months ago - I keep giving him credit because he went above and beyond to help me and he deserves it to be acknowledged for it) are:
Product X Subscribed (Boolean)
Product X Subscribed Date (System.Date)
Product X Canceled Date (System.Date)
Product X Nurture Completed (Boolean) - which is used to complete loop program and reset to re-enter later
I'm talking about having only a DateTime, not both.
Right. I see. It's not necessary as the system.date stamp (value) - if there is one - for Subscribed/Canceled lets you know the TorF status of each.
I feel like all of what I have is good news and we're still in business since we have this data in place already, right?
Based on the fields I have am I able to create more advanced Velocity code required to "welcome" those that became true during the past day? If so, how?
During the past 24 hours? Or during the current calendar day in your timezone? (Different things)
The past 24 hours because these 'statuses' change in the CRM and there's only a single daily sync to Marketo. Obviously causing all DateTime/system.dates to match for that day regardless of when it really took place. Therefore all 'Data Value Change' triggers fire at the sync - so I typically just batch all yesterdays data to take action today.
OK, then you'd need to use the DateTime math code from https://blog.teknkl.com/velocity-days-and-weeks/. It's too far afield for this post, you really need to know Velocity to support complex code like that in the long term.
In other words use only Product X Subscribed = "".
Will DateTime recognize system.date since that is the field I created? And the blog post touches on coding scenarios different than this particular one. The TimeZone one is closest but still not interchangeable.
Will DateTime recognize system.date since that is the field I created?
I don't understand the question...
And the blog post touches on coding scenarios different than this particular one. The TimeZone one is closest but still not interchangeable.
Actually all those recipes involve timezones -- because all Dates have timezones.
The difference in hours between 2 Dates follows the framework in Use Email Script Token to calculate number of years based on a date field (itself adapted from my main blog post) only you'd use getHours() instead of getYears(). Like:
#set( $calProductXSubscribed = $convert.toCalendar(
$convert.parseDate(
$lead.ProductXSubscribed,
$ISO8601,
$defaultLocale,
$defaultTimeZone
)
) )
#if( $date.difference($calNow,$calProductXSubscribed).getHours() >= -24 )
You subscribed to Product X within the past 24 hours.
#end
I don't understand the question...
In the 'Product X Subscribed Date' and 'Product X Canceled Date' custom fields I created I populated that value with {{system.date}} rather than {{system.dateTime}} and I was wondering if that mattered in this particular case.
only you'd use getHours() instead of getYears(). Like:
I have created and duplicated 8 times (specific to each product) this exact framework in the Email Script Token. I assume I need to have these 8 product specific blocks followed by the 8 false blocks like so:
#if( $lead.DMSSubscribed.equals("") )
Your DMS Subscribed is false.
#end
Am I missing anything or is this 100% completed and ready to go once I fill in the messaging?
In the 'Product X Subscribed Date' and 'Product X Canceled Date' custom fields I created I populated that value with {{system.date}} rather than {{system.dateTime}} and I was wondering if that mattered in this particular case.
Then you probably got midnight on that day stored in the DateTime, which certainly matters as it could be up to 23 hours and 59 minutes off.
I have created and duplicated 8 times (specific to each product) this exact framework in the Email Script Token. I assume I need to have these 8 product specific blocks followed by the 8 false blocks like so:#if( $lead.DMSSubscribed.equals("") )
Your DMS Subscribed is false.
#end
Yes. But you should also wrap the first set of conditions in a not-equals check, so you ensure that you don't try to convert an empty string to a Calendar (this will non-fatally fail but should be avoided).
#if( !$lead.ProductXSubscribed.isEmpty() )
#set( $calProductXSubscribed = $convert.toCalendar(
## etc., etc.
#end
Am I missing anything or is this 100% completed and ready to go once I fill in the messaging?
Sorry but I really can't sign off on your implementation, never having looked at it in reality. Once you put it through its paces, testing a representative set of cases, it's good to go.