Tokens use cases and best practices

[Wprunier]

Hi there,

We are rebuilding our tokens structure at a global level to ease program creation, standardization, and quality. In the past we were using tokens very basically (to populate email from address/name, CTA verbiage, dates, some basic email content, program name, content URL etc..) and we didn't take much the opportunity to play with token in parent folders / program-based tokens / overiddens ones. 

Does anyone have great use case, best practice of the use of tokens? How deep have you been using tokens? Have you made mistakes when you structured your tokens?

We are using 5 - 10 tokens per program templates, and we are looking to tokenise much more! What tokens changed your Marketo daily life? 

Looking forward your responses! 

William

[Beth_Massura]

Hi William,

Folder-level tokens are great for providing consistency across programs - in usage and/or values. 

Since the tokens will be inherited in all the programs inside the folder, a campaign creator doesn't need to think about creating each necessary token from scratch on a new program, but merely updating the token values. You can use a placeholder value to prompt the campaign creator to update the token value and follow any guidelines. For example, if your organization's analytics needs require that each program has a unique tracking code appended onto all link urls, you could create a folder-level Text token with the value "enter the tracking code in the format xyz".

Consistency in the names of the tokens - because they're inherited from the folder- can make it easier to document and understand how they're used. If program tokens (not just system or person tokens) are leveraged in the email templates or snippets, the exact naming is critical - the token will not work if it says {{my.awesometoken}} in the template and {{my.supertoken}} in the program.

Sometimes the format of system tokens doesn't quite meet your needs, and you can use top-level folder tokens as a workaround. For example, if you want an auto-updating copyright year, the system token has only the full date. On the top-level folder, use an Email Script token type with this value (and then do not edit the value on the program - just leave the inherited value):

## replace "CST" with your timezone to capture exact New Year's Day changes!
#set( $timeZoneObject = $date.getCalendar().getTimeZone() )
#set( $currentYear = $date.format("yyyy", $date.getDate(), $date.getLocale(), $timeZoneObject.getTimeZone("CST") ) )
${currentYear}

When a token is inherited, you can change the value on the original (e.g. folder-level) token and the new value will flow down to the programs. Keep in mind that once you override or delete an inherited token, you can't re-inherit it. This means that any updates to the value of the original (higher-level) token will no longer flow down to it, even if you recreate the token with the value it had originally inherited.

While (inherited or local) tokens can exist on a program without actually being used/referenced within the email asset, I would caution against adding too many inherited tokens. It could create confusion about the use cases and be messy to manage.

Hope this gives you some ideas!

[Amy_Goldfine]

I love tokens! Here's my game-changer: number your tokens. That way you can group similar tokens together in sections, and you can control the order in which they appear in the token view.

Here's an example if they're not numbered, because "e" comes before "s"

{{my.End Time}}

{{my.Start Time}}

I guarantee if you're copying values from a campaign brief or even just typing in, you'll end up mixing these up, because in your head "start" comes before "end."

If you number them, they look like this

{{my.01 Start Time}}

{{my.02 End Time}}

Ta-da!

Here's a look at our webinar tokens for inspiration:

Another thing that I started for engagement programs is tokenizing the sender info. We have two engagement programs, and each is managed by a different DG Manager. Each sends the emails "from" themselves. The engagement program has tokens with their name, email, photo, etc. 

The "shell" emails in my default content program templates have those same tokens, which get inherited from the engagement program.

This means

- Faster setup: the DG Manager doesn't have to spend time on the sender info or the signature

- Easy switchout: If that DG Manger changes roles, or we decide to change the sender of the nurtures, I only have to change in one place.  

[Anni]

Hello Amy,

I believe I love tokens just as much as you do, fantastic! I definitely use them extensively across most channels.

One thing I struggle with is tokenizing email fields such as "From", and "Subject". I used to tokenize those fields as well, until I came across some of the sent emails in Salesforce's Sales Insight. And at least for the subject line, it quite literally showed the token name, not the value I placed in it. Sales certainly cannot use that information.

Have you come across this issue by any chance?

Thanks!

Anni

[Darshil_Shah1 · Accepted solution]

Hi @Anni,

This is a known issue! Token values are not rendered through to the MSI plugin. They just appear as tokens e.g. {{lead.First Name}}, {{my.custom token}} in the MSI tab in SFDC. However, if you click on the subject line of the respective email in the MSI tab, you can preview the email with the custom {{my.custom tokens}} values populated.

[Anni]

Hello Darshil,

Thank you so much for your prompt reply, muchappreciate! I love such valuable insights. Truth be told, I never actually clicked on the emails in MSI, otherwise I would have probably come to the same conclusion you just presented me with. 😄

I shall test this out soon and see what results come in on the Salesforce side.

Cheerio!

Anni

[Darshil_Shah1]

For sure! Glad that I could shed some light on this.

Let us know how it goes. 🙂