S-Tag email help for TeamRaiser communications

Options
We participate in 50+ third party events (Rock 'n' Rolls, Tough Mudders, etc). When people register for one of these events they can either guarantee their race entry upon registration by completing the DSP form - or they can just start fundraising and get entry as long as they reach their minimum by the fundraising deadline associated for that particular event. 


We're trying to automate communication as much as possible. One specific example is I'd like to have messaging that says "you have XX many days left to reach your $$$ fundraising minimum". Ideally the fundraising minimum (which is a different amount than the user determined fundraising goal) and fundraising deadline would be stored and retrievable via the S48 tag. If you agree this would be a useful feature you can vote for this idea and this idea.


While waiting to see if the ideas move forward, I'm trying to build a work around. I tried a few things but with some of the email specific restrictions with s-tags I've only come up with a less than ideal solution. I'm wondering if anyone (*cough* Noah Cooper....*cough* Brian Mucha) can think up of something better. 

 

What I've tried so far...


- Using U0/S80 tags which works in all test environments and a lot of real world cases - but at times can produce incorrect information for an individual participant which we found out the hard way. According to support, these tags aren't officially supported for emails. 


- Storing this information in a different field in the TR setup but S47 isn't support on email at all, and S42 doesn't support bracket format in email, only XML.  Using the XML version to get a S42 date into a S98 parameter just yields an error message. 



Where I've landed is using PageBuilder pages to do the S42 logic in XML format to output things like fundraising date and event classification and then use S51 in bracket format to pull that information back into other places. This seems to work, but it's a bit of a convoluted process - especially when I need to use both S42 and S48, since S42 supports using 0 for the TR-ID but S48 doesn't and a blueprint push only works if the logic is being done in the email itself and not when I'm directing this logic back to a pagebuilder page. So I need another pagebuilder page to output the correct TR-ID from S42 which then can be used for S48. 


So I think this is all possible going this route, but I'm hoping some of the brilliant minds out there can come up with a simpler solution. 


Thanks!


Jon

 
Tagged:

Comments

  • Hi Jon! I went ahead and moved this to the TeamRaiser discussion area. :) I'll do my best to find someone who can help you out.
  • Assuming S48 works in broadcast email...I think it does.

    S48 renders Participant Information, including how they answered registration questions. You could add two hidden registration questions to store this information.


    I'd test this idea first by adding a couple of (visible) registration questions, setting their values manually on a test registration and trying to read them in an email. If you can get them to work, then the rest is details. (This does mean the goal and date are stored on each registration, so any deadline changes would not be retroactive.)



    The big trick is getting those fields populated. The registration questions are on a different page than the participant type selection. But, I think that since registration is not yet complete you can't yet retrieve that selected part type using an S-Tag. Maybe I'm wrong there, but the only thing I can think of here will involve some JS.


    You could attach listeners on the part type inputs, and then onClick you set sessionVars to store the selected PartTypeId. Those can then be easily read on the next page and used to set the registration question values without the user needing to even know. (LuminateExtend has a method to set sessionVars from your script.)


    With 50+ events you will need some way to configure all of this. I could see doing that in a JSON file. Have the PartType ID be the key, and date and goal be associated values. Then all you do is read the selected PartType from the sessionVar, and lookup the date and goal from your JSON, and set the two fields (now hidden with CSS) with those values. 


    {

    "12345": { "goal": "200", "date": "2017-09-11" },

    "67890": { "goal": "400", "date": "2017-10-11" },

    }


    Edit: Then once you have the values stored you can access them easily: 


    [[S48:1234:question:Deadline Date?]]
  • I'de interested to hear what problems you had with U0/S80 in email. I do that all the time. You do have to set the tag higher in the DOM than where you consume it. So you can't set it in the body of the email and read it in the stationary masthead. Other than that I haven't run into a problem before.
  • Brian Mucha:

    I'de interested to hear what problems you had with U0/S80 in email. I do that all the time. You do have to set the tag higher in the DOM than where you consume it. So you can't set it in the body of the email and read it in the stationary masthead. Other than that I haven't run into a problem before.



    We used a reusale pagebuilder page to set appropriate U0 tags to set things like the fundraising deadline and minimum. We used this on pagebuilder pages, autoresponders and emails blasts so we could write out conditionals once and use it in a lot of different places. For large email blasts, we also included another reusable to check what TR events a person was registered for and set a tag for the TRID of the event that was coming up next  - this allowed us to communicate with people in all these events without having to go into each individual TR event and send out coaching emails. 


    Great in theory and for the most part in practice, until an email went out and told some people a different fundraising minimum than what they had signed up for. When sending test emails as those same people, the content was correct and the minimums show what they should have received and not what they actually did on the real send. So there was really no way for us to troubleshoot this because it worked correctly in all test enviornments. Tried doing real sends to a small group of staff participants and the code all worked as it should for most but not all and no reason that we could find. Support said U0 and S80 isn't supported for email and we shouldn't use those. 


    So I'd be cautious about using those tags since the preview and testing tools aren't guaranteed to show you what people will receive, which really is the bigger concern with this situation. As far as I can tell, it only affected a small number of people, but there's really no way for us to know. 

Categories