Jeff Shearer

Tag: Tokens

  • One Landing Page Template to Rule Them All

    One Landing Page Template to Rule Them All

    This post originally appeared on the Champion Blog of the Marketo Community on August 10, 2015

    ringI hate repeating work in Marketo. Yet landing page templates seem to be an area that requires a lot of repeat work. It seems natural to just build a new template when you have some new use case, channel, or brand to contend with. But the problem with this approach shows up later, when changes are needed at a global level. Suddenly you’re stuck with all sorts of versions to update. The end result is a bunch of legacy templates with outdated code, and maybe one or two templates that actually remain current.

    So instead of building new templates each time some minor new change is needed, I try to think about the process backwards-identify the elements I might need to customize on my landing pages, and then build a flexible template that will let me control those changes in the future.

    This approach is made more viable with the new guided landing page templates, which add an awesome new functionality called Variables. These, plus some creative applications of program/folder {{my.Tokens}}, allow you to build a template that works for nearly any situation. Here are a few ideas to try:

    Branding: logo swaps, color palate changes, fonts, etc

    Logo and style changes are some of the more common edits you might be making to a template. You may need different looks for an SEM page vs an event registration page, or for a parent and sub brand. At a minimum, you should wrap key brand elements like a logo within a “mktEditable” div. The magic of this class allows the content within it to be directly editable within the landing page editor.

    You can get even more control with variables, for scenarios like:

    • Toggling between two main logos (boolean variable)
    • Changing the accent color used on your pages (color variable)
    • Setting the URL of an element like a banner image (string variable)

    CSS TokensAnd when you need finer tuned control and the ability to overhaul CSS on the fly, program {{my.Tokens}} are what you’ll want to use. Consider putting a few placeholder tokens in <style> </style> tags in your header for any program or folder-specific CSS editing you might want to do.

    Tokens are great in that you can choose whether or not you want to assign them a value, so it’s always worth adding a few to your templates should you need them later. They’re especially handy when you’re testing a new form design, or need to make broader layout changes. It’s as simple as pasting the new CSS snippet into a token, and the pages within that folder or program will instantly reflect the new code–no draft approval required.

    Placement and visibility of elements

    Landing Page VariablesIf you check out the documentation on variables, you’ll see a few mentions of manipulating the visibility of elements in your page, such as making your footer shown or hidden. But you can take this idea a lot further, and build variables that allow you to display a form or secondary call to action with the flip of a switch. You can use this sort of idea in tandem with other variables that control the width of different elements (especially when using a responsive, grid-based framework like Bootstrap). This allows you to use the same template for both your landing pages with forms and form-free confirmation pages.

    Scripts and tags

    It’s common to see separate landing page templates when specific tracking scripts are needed, such as a confirmation page to track goal conversions in Google Analytics, or on a specific landing page used to fire a remarketing script. This can get clunky to manage across multiple templates, and a few tokens will serve you well here.

    Just as with CSS tokens, you can set a few dedicated javascript tokens in your template which can be referenced as needed. Then, if you have a specific program or set of programs that you need to call a script for, just put in a value for one of your script tokens, and you’ll be set. Note: if you’re really clever, you’ll put programs that use common scripts in the same folder, such as those used for Search Engine Marketing. Then you can just set the token in one place–at the folder level, and all the programs within it will automatically inherit that value.

    Better yet,  you can solve a lot of this with Google Tag Manager. It’s a wonderful tool that allows you to fire different scripts based on different scenarios: a specific page view, a click, or another event you configure there. This will probably keep your PPC manager or agency happy, because they don’t have to fuss with different landing pages to get the configuration needed.

    Localization and miscellaneous meta info

    For global brands with page localization needs, there are meta properties such as HTML language type and CSS text direction (for languages like Hebrew that read right to left). You can set these sorts of items as variables in your template too, allowing you to quickly swap between localization preferences.

    There’s a few other miscellaneous use cases too:

    • Copyright year – this changes every year, so think about setting a token for it in your footer if you display one. This will save you hours of work fixing landing pages on January 1st.
    • Footer links – For social icons, privacy and T&C links, make that area a token that you can change globally. This stuff does sometimes change, and with a token it takes just seconds to update.
    • Open Graph tags – Do you ever wonder how people get their posts to display well on social networks with full sized images? Chances are they’re using open graph tags to specify post meta content. So you can place this data in your templates and set via tokens for quick updates.

    clapIf you were to implement every one of these ideas, you’d have a lot of tokens and variables to contend with. So the key word here is moderation–just because you can make everything a token or a variable doesn’t always mean you should. This is doubly important for variables, which require hard coding into the templates, so tweaking these all the time isn’t really ideal.

    These ideas just scratch the surface of what some of you have already come up with–so please share any clever template ideas you’re using in the comments!

  • {{my.Favorite Feature of Marketo}}

    {{my.Favorite Feature of Marketo}}

    I’m amazed at how many people are using Marketo like a plain-jane email marketing tool. Maybe it’s just my nature to seek out the more efficient, scalable way of doing things, or maybe the true automation functionality in Marketo is simply not well understood by many users.

    If you’ve ever pulled me into a conversation about marketing automation, you’re likely to have heard me mention “tokens”–and quite often. This is one of the areas where I believe some of the real, tangible value of an automation tool like Marketo starts to pay off, yet I also know it’s not well utilized or understood by the majority of organizations & users of Marketo.

    Tokens are a piece of functionality that can not only save time for those creating campaigns and programs in Marketo–they actually help produce better, more consistent campaigns in the process.

    Tokens, defined

    Marketo tokensTerminology and naming conventions are always tricky with marketing technologies, and the term “token” can mean a few things, particularly in Marketo.

    A lot of CRMs and email providers use the term token to basically define a mail merge field. Tokens are something pulled from a field in a database to appear in a piece of creative-most often, an email.

    This is an accurate definition in Marketo. You can personalize emails with salutations, lead owner details, you name it, with all the data pulled from your CRM or wherever. For lack of a consistent, descriptive name, I call these Field Tokens.

    But this sort of usage of a token is pretty duh. It’s not new, and most marketers have been using it for years.

    There’s another type of token, though, that’s actually pretty special.  I call them Program Tokens, though their usage can extend beyond programs in certain situations.

    But for the purposes of this explanation,  program tokens are something you set within a Marketo program. It’s not a piece of data unique to a lead (like a field token is). It’s a piece of data unique to a program.

    A practical example

    Think about a webinar as an example.  If you’re like most marketers, a typical webinar’s list of assets looks something like this:

    1. Invite Email
    2. Registration Page
    3. Reminder Email
    4. Follow Up Email (Thanks for Coming/Sorry We Missed You)
    5. On-Demand Webinar Page (for watching the recording later)

    While each of these are separate assets, and each serves a different purpose, they actually all contain a lot of the same information:

    1. Title of the webinar
    2. Date and time
    3. Event description
    4. Branding elements: banners, buttons, speaker photos, etc

    If you’re the person building out the webinar, think of the amount of times you need to re-enter all of these pieces of info. It’s time-consuming, and it’s where most mistakes happen. The wrong date gets entered, the wrong link to a landing page is posted, the list goes on, and for a webinar especially, a small error can actually be pretty disastrous.

    So the benefit of a program token is that you can set a token for something like the date and time of your webinar in one place, and have it automatically used in every area you reference it. Here’s how it works:

    1. On your webinar program, create a token with a unique name, in this example, let’s call it Webinar Date.
    2. Set what you want your token’s value to be: March 3, 2014
    3. Go  into each of your assets that references the date of the webinar, and instead of writing the actual date in each, use the token instead. So instead of saying “Join us on March 3, 2014,”, say “Join us on {{my.Webinar Date}}”.
    4. Once you’ve done this for all your tokens and all your assets, preview and test each asset. They should automatically populate with the information you set at the token level.

    So why does this all matter? For a single webinar, you may not exactly be saving much time by creating all these tokens. But suppose you’ve got the date wrong on one reminder email. If you miss it in your QA processes, you’ve got a big problem when your campaign launches.

    And then consider the implications if you’re running a webinar every month. Chances are, you’re following the same format for each webinar.  If you set tokens for all the event-specific stuff, you can simply clone the first webinar program you created, and just go in and change the tokens to match the new event details. If you do it right, you may not even need to go into the email and landing page editors at all. It can literally take your event production in Marketo down from a few hours to 20-30 minutes.

    I’ve been using webinars as the example here, but the concept of tokens can be used in limitless situations in Marketo.

    There’s also other, more out of the box ways to use tokens, including things like: graphical elements, embedded videos, hidden form data, and even straight HTML, CSS, and javascript.

    Hope this helps!