global variables vs. tokens?

It's a question of who and where the value should be maintained.

If email authors need to set the value, it can't be a token.

If email authors need not set it, or must be prohibited from mangling it, and it applies to all emails under a certain level of the program hierarchy, it should be a token.

I'll add also that token will work for things in Marketing Activities, but not for things in Design Studio.

Also, my biggest beef with tokens is that they don't render in the editor experience (it'll show the {{my.TokenName}} instead of the contents of the token) so you've got to go into Preview mode to try and understand what's going on in the page. This isn't too bad when it's used for a headline, but when entire sections of content are loaded via tokens, it's harder to "see" and therefore harder to edit with the editor. On the other hand, global variables will show up in the editor.

Another distinction might be that tokens can be set differently from program-to-program at a high-level (and across assets, email & LPs), but a global variable lives within the context of the template, so that applies more to "this asset" than "all the assets". EX. if you were to change the global variable for a background color in an email, it'd update that particular email asset, but not all the emails in that program (whereas a token would update them all at once... in preview mode). In general, I think about Global Variables applying to "all similar things on this template" (i.e. all module background colors, or headline font sizes) and Tokens as things that apply to an even higher level of category, or "all similar things on all assets" like an Asset's Title, CTA url, Dates/Times (things you'd see in both emails and LPs, for example).

Hi Suzanne,

You can event use a variable which default value will be a token. We often do this when we need to combine the advantages of tokens with the flexibility to et assets editors change a value in one of the assets in the program.

-Greg