Tokens use cases and best practices

Wprunier
Level 1

Tokens use cases and best practices

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

Marketo Ninja
Tags (2)
2 REPLIES 2
Beth_Massura
Level 4 - Champion

Re: Tokens use cases and best practices

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
Champion Moderator

Re: Tokens use cases and best practices

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:

Screen Shot 2020-06-17 at 11.58.17 AM.png

 

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. 

Screen Shot 2020-06-17 at 11.59.54 AM.png

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

Screen Shot 2020-06-17 at 12.00.30 PM.png

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.