Observing and unexpected behavior with {{my. tokens

[Grégoire_Miche2]

Hi all,

We have observed an unexpected Marketo behavior today, but someone may have the official Marketo line on this :

A Gated content program is set up with "PDFURL" token that contains the link to the downloadable document.

In order to send this URL to the lead, an email is created IN THE DESIGN STUDIO, so not in the program itself. The CTA in the email uses the {{my.PDFURL}} token from the program.

The program contains a "fills out form" smart campaign that sends this design studio email.

In my understanding, as the email is not in the program, the token should not be populated.

And yet, it works...

-Greg

[Dan_Stevens_]

That's been my understanding as well.  If the asset (email, landing page, form) is not physically contained within the local program, my.tokens would not populate.  I just experienced this last week when using forms that are contained within Design Studio: Centralize a double-opt-in workflow

[Anonymous]

Actually, I think it's always worked like that. There's other things you can use program tokens in that aren't actually in programs, like webhooks. They still resolve as long as they are called from within a program.

[Dan_Stevens_]

If that's the case, Kristen, shouldn't it work consistently across all three types of assets (emails, landing pages and forms)?

[John_Clark1]

Hi Dan,

Landing pages and forms that live in the Design Studio don't have any association with the Program in Marketing activities where the My.Token lives, so they aren't able to populate at all.

John

[John_Clark1]

Hi Greg,

I actually did some extensive testing on this a while back.  As long as the My.Token matches a token that lives in the program the email is being sent from it will work.

My test included two Programs with one token each.  The tokens were named the same thing, and when I placed that token name in my test email it would populate with either Program 1 or Program 2 depending on which program I sent it from.  Of course it was a smart campaign which was a child asset of each program that was actually doing the sending, but the token always looks at the parent asset to find its value.

I don't believe this same method would work for landing pages or forms in the design studios.  Emails are a bit of a special case.

John

[Josh_Hill13]

Greg,

Curious why you are leaving the email in Design Studio? You can put/clone them in a Program so everything is right there in one place. There are no restrictions on calling an email in a program from another program.

Dan - if you are building a opt in or sub management system, it should all be inside a Program for all sorts of reasons: token use, organization, clarity.

[Dan_Stevens_]

Josh Hill - that's what we ended up doing.  In fact, we built a single global program in the default workspace to listen for this across all 23 country workspaces.  The only thing that we won't be able to do is capture the "program name" (we had hoped to do this using a local program token) and place this in the "opt-in program" field.  This is another layer of protection should we ever receive complaints or get audited.

[Kenny_Elkington]

Context for my tokens in emails is pulled from the parent folder/program of the campaign sending it, not necessarily from the parent of the email.  However, that said, it is usually a potential source of confusion, and you should place the email as a child of the program ffrom which it is being sent whenever possible.