Centralize a double-opt-in workflow

[Dan_Stevens_]

For any program that has a form within it, we include the necessary flow steps to populate the appropriate opt-in fields (opt-in, opt-in date, opt-in program, etc.) with the appropriate values.  One of these values is a local "Program Name" token.  Ideally this would be built once and any smart campaign that needs to use it, would simply request this single campaign.  But if we do this, we lose the local program token.  My thought was to use this local token with a hidden field of the form (a Marketo form that's embedded on our website).  But when I populate this custom/hidden form field, the value remains as {{my.program name}}.  Are local tokens not supported in Forms 2.0?

[Grégoire_Miche2]

Hi Dan,

I do not see how this could work.

I think you may post an Idea around "populate a hidden field with a token value", meaning that when the form JS is executed, it pulls the value from Marketo. I'll vote for it 🙂

-Greg

[John_Clark1]

Hi Dan,

Is the form you're using this token with sitting on a landing page that is a child asset of the Program where the token lives?

My.Tokens are only available to child assets of the Program or Campaign folder where those tokens have been created.

John

[Dan_Stevens_]

No, the form is a central form in Design Studio.  Forgot about that (I was thinking since the Program that's used to track behavior of this form - in this case, a contact-us page on our website - is local, that the tokens would work).  For those forms that reside locally within a program, this should work then, correct?  Are local my.tokens supported in Forms 2.0?

[John_Clark1]

Yes, they should work.  Remember that My Tokens can live in Campaign Folders as well.

[SanfordWhiteman]

The principal problem with your plan is the "embedded form" part.  If it were a Marketo LP, it's easy: render a token into the page (i.e. in an HTML block), then use the Forms 2.0 API to populate the value.

For embedded forms, though, you may be able to smuggle the token into the Thank You URL, which IIRC was recently fixed to restore the ability to include my.tokens.  If you can do that, then you can grab the token out of the URL, add the hidden field, then repost the form with the program name appended (silent post, so don't worry about the lead seeing anything).  This won't affect operation of your Thank You URL since you can strip out the data before the redirect (or just leave it in place if you consider it harmless for the person to see ?program=myname).

[Dan_Stevens_]

Thanks Sanford, but even this approach won't work since there is no TY URL.  A user then receives a confirmation email and are asked to click to double-opt-in.  I think I'll need to stick with local campaign flows like we're doing today.

[SanfordWhiteman]

You don't need to be using a TYURL, in fact it's easier if you're not. It's just leveraging the functionality awarded to TYURLs.

[Dan_Stevens_]

I realize that.  But since the desire was to execute most of this centrally, within a single campaign (and a single TY/confirmation email) to support an entire workspace, tokens will not work here.

[Dan_Stevens_]

BTW, what's a more accurate choice/behavior for us to key off of for changing the data value of "double opt-in" to TRUE: "Clicked Link in Email" or "Visited Landing Page"?  I realize this won't be foolproof - for example, if the user has activated their browser settings to not allow websites to track them.  This is only being activated in those countries where double opt-in is required - like Germany.