Skip navigation
All Places > Champion Program > Blog > Authors Jeff Shearer

Champion Program

3 Posts authored by: Jeff Shearer

Chicken or fish?

It’s as if every program or event has some random, custom field requirement. Dietary restrictions at an event, questions for a webinar, or a time slot for an in-person consultation. Fields aren’t exactly hard to create in Marketo, but they live on forever once they’re created, and can lead to a ton of confusion later. Avoid the temptation to add new fields in every scenario. There’s a much better way to deal with this, and I’ll show you how.

Instead of creating a new field for every random request, create a small handful of temporary “burner fields” that you can use over and over again. Just remember these aren’t to be used for data you want to hold on to. Nothing critical like contact info, lead profile info, etc. Just single or temporary-use data.

In fact, for truly temporary data, it’s a bad idea to keep this sort of data around permanently – if you ever run a similar program again in the future, you run the risk of referencing old data in the new program. Not to mention it creates a complete mess when trying to find the proper fields to use.

To start, you’ll want to create at least one string field, but you may want a few of these. Give it distinct names like Temporary Text Field 1, Temporary Text Field 2, etc.

Burner fields on a Marketo form

Add your temporary field to a form – here’s an example of a multi-location event registration form.

Once you add one of these fields to a form, you’ll need a way to record the temporary value, and then clear the field so it can be used again later.

Set up a smart campaign that triggers when your form is submitted (this may already exist for something like an event registration action), with specific actions for dealing with the value just stored in your burner field. And your method here may vary a bit depending on the data you’re capturing.

For example, if you’re running a multi-location roadshow, and you want to use one registration form for the entire series, you might want to use your temporary field to display a selection of all the events in the series.

In the smart campaign that triggers on the form submission, use the value in that field to add the lead to the appropriate sub-program, or static list.

Then, follow up with a data value change of the temporary field, and set a new value of “NULL”. This will clear the field of it’s value for that particular lead.

Temporary fields in a Marketo smart campaign

Here’s the same roadshow example on the smart campaign. Marketo sorts through the temporary field values, assigns to the proper program, and then clears the value out.

Alternatively, if the data is something more open-ended like dietary restrictions or webinar questions, consider setting up an email alert that fires when the form is submitted, which will essentially stamp that value in an email for future reference, even if it no longer exists on the lead. If email alerts won’t work, you could also opt to add all the leads to a static list, and subscribe to it. Then set a timed smart campaign to clear out the field of any values after your event or whenever the data will be used.

Now you have a field for every occasion, and you’ll probably discover new use cases for them all the time. If you ever have concerns about the use of a field overlapping across programs, you just add another temporary field, or better yet, assign your burner fields by use case or region to avoid any accidental crossover.

This post originally appeared on www.jeffrshearer.com

List imports are scary stuff.

 

There are a lot of things that can go wrong with pushing a file of leads into your database. Duplicates. Overwritten values. Bad data. List imports open you up to a lot of risk to your Marketo database all at once.

 

But you can set up a line of defense for your more sensitive fields using what I call “proxy fields”, which help you intelligently manage how data is overwritten.

 

List imports are a daily task for us, and so we’ve gotten pretty strict on the data requirements for new leads, particularly with the lead status field. When we upload, we need to be able to distinguish between suspects/inquiries and truly qualified leads.

 

We block field updates for the lead status field, meaning it only accepts the first value from a list import, and won’t be changed by future imports. This helps us ensure a lead that’s already an MQL cannot move backwards and become a suspect from a later list import.

 

This is handy, but field blocking is a double edged sword. Suppose a lead was originally imported as a suspect, but is now on an import list where we’ve marked them as an MQL. In that case, we actually want them to become an MQL, but since that field blocking is in place, that lead’s status won’t be changed, and we’d be forced to fix it manually.

 

To work around this, we created a proxy field, called “Import Lead Status.” It replaces the standard lead status field on our import lists, and more intelligently manages the data, making sure leads can move forward in status, but not backwards.

 

Here’s how to set it up in about 10 minutes:

 

  • Create a new text field with a name distinct from the original field (this should be a marketo-only field), such as “Import Lead Status.” Ensure no field updates are blocked. You may also want to set a few list import aliases for this field, as this is the field you’ll want all your list imports to map to in the future.
  • Create a smart campaign set to run every time a lead qualifies, with two triggers: one for anytime your new field’s value changes, and another for when the lead is created (since data value change triggers won’t fire for new leads). You’ll also want to include two filters:
    • A filter to exclude any lead statuses you do not want to change. You need to include this so your import lead status doesn’t move any leads backwards inadvertently. I decided that anything Marketing Qualified or beyond (SAL, SQL, etc) shouldn’t be changed.
    • A filter the specifies that the import lead status field isn’t empty (for the aforementioned “lead is created” trigger)
  • For your new Smart Campaign’s flow, you just need one step, “Change Data Value” that sets the lead status by grabbing the value from the proxy field, using a field token.

2JB0jINxxi.gif?w=1107

The nice thing about this process is it’s invisible to your other Marketo users. We have a standard import template that we require for any list uploads, and I have “lead status” and variations of it mapped to this proxy field as a safeguard, so to anyone importing lists, this is no different to how they managed the process before. Since implementing this process, it’s had a big impact on efficiency and accuracy for us.

 

Obviously this is just one example of a proxy field – you could do something similar for geographic fields, company names, phone numbers, and much more. If you’re doing something similar, I’d love to hear about it!

 

This post originally appeared on www.jeffrshearer.com

ring.gifI 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.png

And 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


variables-screencap.pngIf 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.

 

If 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!

clap.gif