Best practice for multilingual marketing activities?

[Daniel_Koch]

Hi,

Our core business is located in DACH (Germany, Austria, Switzerland) but a couple of weeks ago we started to attract English speaking user's attention. Additional to our marketing activities in German we're planning to set up marketing activities in English.

My questions are:

1. What are your good or bad experiences concerning setting up multilingual marketing activities?

2. For newsletters: Would you recommend multilingual programs or one program for each language? (I know this depends on the target of the campaign, but I think both ways have some advantages and disadvantages)

3. What are your experiences with segmentation?

Looking forward to discussing and sharing thoughts with you.

Greetings,

Daniel

[Iryna_Zhuravel4]

We localize in 8 different languages, use segmentation and dynamic content extensively, but I am currently rebuilding the whole thing.

I would strongly recommend using language preference field in conjunction with country/region and not to assume that people want to receive content in certain language just because they are from a specific country, we had a lot of issues with that.

I used to be a big fan of dynamic content, but recently I saw the light and we are now moving to scripted tokens   imho they are much-much more scalable and convenient

[Victor_Herrero]

Hi @Iryna_Zhuravel4 , 

Could you maybe share an example of how scripted tokens make things more scalable or an example use case? 

I think tokens can be intimidating for a lot of people using Marketo, and script tokens even more so. 

The way I understand it is: 

Instead of making emails dynamic you use a static version of them and all text blocks are a script tokens? 

How do you handle common "tokens" like dates and times ? Do you reference the field directly from the code? Because you can't put tokens inside tokens (sadly).

And the blocks... do they look at some translation file for each email to show based on some "preferred language" field on the record? Or maybe you are using localized tokens? 

Also @SanfordWhiteman did that infographic ever see the day of light? Or maybe a blog post? 🙂 

Thanks! 

[SanfordWhiteman]

---

Instead of making emails dynamic you use a static version of them and all text blocks are a script tokens? 

---

I prefer to call it "a different type of dynamic" as opposed to static.

A Velocity-powered email can be way more dynamically personalized than "Dynamic Content" allows - for example, using the intersection of multiple fields + multiple segments at the same time to determine final content.

---

Do you reference the field directly from the code? Because you can't put tokens inside tokens (sadly).

---

Well, you can reference Velocity variables set in one {{my.token}} from other Velocity {{my.tokens}}. So it is a form of tokens inside tokens.

---

Also @SanfordWhiteman did that infographic ever see the day of light? Or maybe a blog post?

---

We never did it, but maybe I'll reach out to Frank... been awhile since this post!

[Victor_Herrero]

Sorry for taking this long, I was expecting an email notification. 

A Velocity-powered email can be way more dynamically personalized than "Dynamic Content" allows - for example, using the intersection of multiple fields + multiple segments at the same time to determine final content.

With regard to this, I think I see what you mean. In a dynamic email you can basically use one segmentation, like say language. But if you had content A and B in each language, you couldn't reach that depth, and you would need a more complex segmentation combining both language and somehow also A and B contents. So I take it that this would be achieved making use of your "tokenception"? 

Have contents A and B in a script and have one version of this per language, then reference that token based on language segmentation (for instance) and let the script token give your lead A or B based on whatever rule in the script? 

Maybe even ditch the segmentation altogether and use a script token (or several) for the email body that changes based on your country field. 

Is there an example of tokens referenced in tokens that you can show me? Even a simple one? Maybe in your blog? 

Do they have to be on the same folder (scope) ? 

This is perhaps what you mean https://nation.marketo.com/t5/Product-Discussions/Referencing-local-tokens-in-an-email-Velocity-emai...

[SanfordWhiteman]

Yes, that thread has examples of what I mean. 

You can also use #define in {{my.token1}}:

#define( $en_US )
Choose your favorite color.
#end
#define( $en_UK )
Choose your favourite colour.
#end

And access those as $en_US and $en_UK in {{my.token2}} (if you include {{my.token1}} in the email first of course).

[Victor_Herrero]

That looks really interesting! Thank you for sharing 🙂

That would mean you can create a token where you define variables, then include it inside the email (even if it doesn't really output anything, just contains variables) and start referencing when appropriate. 

For instance: 

{{my.contentVariations}} - contains &varA_EN, &varB_EN, &varA_ES and &varB_ES of the content (probably also a default value).

{{my.emailBody_EN}} - contains {{my.contentVariations}} and a code that based on some criteria references &varA_EN or $varB_EN

{{my.emailBody_ES}} - contains {{my.contentVariations}} and a code that based on some criteria references &varA_ES or $varB_ES

...

Then you would need an email containing {{my.contentVariations}} whose body is another script, similar to a switch in javascript, where the cases are your preferred language, and for each case you serve a different {{my.emailBody_**}}. Is that more or less the direction? What you meant with adding levels of dynamism by referencing tokens inside tokens? 

[SanfordWhiteman]

---

{{my.contentVariations}} - contains &varA_EN, &varB_EN, &varA_ES and &varB_ES of the content (probably also a default value).

{{my.emailBody_EN}} - contains {{my.contentVariations}} and a code that based on some criteria references &varA_EN or $varB_EN

{{my.emailBody_ES}} - contains {{my.contentVariations}} and a code that based on some criteria references &varA_ES or $varB_ES

...

Then you would need an email containing {{my.contentVariations}} whose body is another script, similar to a switch in javascript, where the cases are your preferred language, and for each case you serve a different {{my.emailBody_**}}. Is that more or less the direction? What you meant with adding levels of dynamism by referencing tokens inside tokens? 

---

You don't put the {{my.token}} itself inside another token.

It's the variables that are shared across tokens. 

So you include the {{my.tokens}} one after the other, and then each subsequent token can access all the vars defined in earlier tokens.

When done properly you end up with 

1. {{my.Global Config}} (this top-level token is for global settings, not "data" per se but things like field mappings & friendly names)
2. {{my.Local Config}} (lower Program-level token, where you may overwrite the Global settings if necessary)
3. {{my.Localized Content}} (defines the locale-specific content, no output}}
4. {{my.Content Chooser}} (the code that determines which content to output}}

[Justin_Norris1]

No matter how you slice it, localization and multi-language stuff is a significant extra effort. Uni-lingual companies don't know how easy they've got it .

We've built out some fairly complex programs for clients using a single multi-lingual program template, with all assets made dynamic with a language segmentation, and then tokenizing the whole thing so you skip the editors completely (never touching the editors is key for making this efficient).

We have kept all the tokens at the main program level, still keeping common tokens universal but having localized versions for everything that requires it. If you have a very clear naming convention, it is quite manageable and fast to deploy.  

I really like the idea of nesting the email programs to be able to re-use all token names (as in Frank's approach), but seems like this only works for batch and blast. We also try to reduce the number of smart campaigns etc. that need to be activated. Basically the fewer things you need to touch and change, the faster it is and the less risk of error.

Iryna Zhuravel​ I would be interested to hear more about your experiences, pain points, and the benefits you're hoping to gain with scripted tokens vs. dynamic content.

The ability to "segment" by multiple variables using the velocity tokens I am aware of and it is a benefit for sure.

[Daniel_Koch]

Thank you very much Frank for your answer. Sounds really good to me! 🙂

[Josh_Hill13]

I would use a Language Preference or Country field with a Segmentation and Dynamic Content. Frank is right that there are pros and cons to each approach.

This is pretty well documented if you do a search on the community here along with Dynamic Content and Segmentations in docs.

[Frank_Breen2]

People will have many different solutions here, but here's how we do it for a Single Workspace setup:

1. What are your good or bad experiences concerning setting up multilingual marketing activities?

Our focus language is English but most of our Global Campaigns are in German, Spanish, Italian and French, to do this we create the master program in the main language and then nest the translated communication in Emails Send program, like this:

Our content is tokenised so this structure works well, as we create our main language content in the Main Program, then we can override every token in each nested email program, this makes it quick and easy to change the content plus we can reuse common tokens through all sends without doing any extra work.

Also note having everything 100% translated in language for that market works better and you'll see a bigger pickup in your marketing activities than only communicating in your local language, i.e. English language people may not know German and vice versa.

2. For newsletters: Would you recommend multilingual programs or one program for each language? (I know this depends on the target of the campaign, but I think both ways have some advantages and disadvantages)

We use the above setup.

3. What are your experiences with segmentation?

Language segmentation works well and is a solution I have deployed before, one drawback is that if you use language as a segmentation you can't then do further segmentation on that down the line as people can only be in one segment at a time, i.e. if you wanted to send an email to people in Education and in English, then you will have to be in one or the other.

[SanfordWhiteman]

And also Iryna Zhuravel​ and Frank Breen​ maybe we should collaborate on an infographic/explainer blog post together about this! I don't think there's a spot where the options for multilingual emails are laid out in a matrix, with checkboxes for which features are supported by each approach 'n' such. Interested at all?

[Frank_Breen2]

Sanford Whiteman I'd also be happy to help on that.

[SanfordWhiteman]

Great ​​​Frank Breen​Iryna Zhuravel​! Send me an email when you're ready so we can coordinate. I have so many blog drafts to publish, but maybe this'll get in ahead of those with the peer pressure.

[Iryna_Zhuravel4]

Sanford Whiteman that's a really great idea, I would love to, I am on a biz trip to China at the moment, will be back to the US on November 5th, let's jump on a call sometime after that.

[SanfordWhiteman]

if you wanted to send an email to people in Education and in English, then you will have to be in one or the other.

If those are segments within the same segmentation, they could only be in one at any given point in time, but why would those 2 terms be under the same segmentation?

I think you mean that they can be in Industry/Education and Language/English simultaneously, but the same dynamic snippet can't have a many-to-many matrix of variations. Which is true, but it's one of the reasons that Iryna and I like Velocity scripts instead, since you can mix-and-match any segmentations you want that way.