Skip navigation
All Places > Marketo Whisperer: Implementation Tips > 2015 > November
2015

I’ve gathered some Marketo best practices and suggestions by the community to write this post for the first-time email preference center builder.

 

The reasons you’d want a preference center are to allow subscribers control over which emails they receive and prevent subscribers from subscribing completely (hopefully.) I’m sure you’ve all seen an example – Google “preference center examples” now if you want a refresher.

 

Here’s a step by step to build a basic email preference center, with more details behind each step below:

 

BUILD AN EMAIL PREFERENCE CENTER IN 10 STEPS

 

  1. Determine your preference center strategy – goals, audience, resources.
  2. Create custom boolean fields for preferences.
  3. Create a preference center form, within a global preference center program.
  4. Create a preference center page and preference center confirmation page(s), then edit the form to direct completions to the confirmation page(s).
  5. Create all the required batch and trigger campaigns to update subscriber preferences.
  6. Edit your unsubscribe footer to direct subscribers to the preference center.
  7. Test your email footer, forms, landing pages, and campaigns.
  8. Batch update preferences for existing leads and activate trigger for all new leads.
  9. Develop a process to include preferences in all your email sends.
  10. Monitor and QA for for several weeks.

 

Screen Shot 2015-11-22 at 10.28.48 PM

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

DETAILS:

 

1. Determine your preference center strategy – goals, audience, resources.

 

Ask why you want a preference center and how this will benefit your subscribers.

 

For example:

  • Do you target different personas who may have different email preferences (roles-based or topical)?
  • Do they want to stay connected, but receive less email (frequency)?
  • Is there an opportunity to roll up content into a weekly or monthly newsletter (and do you have the resources execute?)

 

2. Create custom boolean fields for preferences.

 

Once you’ve defined your strategy and outlined your preference center set up, create custom fields for each preference. For example, it could be based on roles, topics, frequency, or some combination thereof.If you integrate with CRM, decide if you want this data on your customer records or not – some prefer this in Marketo only, some prefer both in CRM and Marketo. Create in CRM first if you choose the latter. The benefit of having it in CRM is if you ever migrate off of Marketo (gasp!), the data is still on the customer record. The downside is more clutter.I like to use a common naming convention for all custom preference center fields, like this:

 

Marketo Preference Center Checkboxes

 

 

 

 

 

 

 

3. Create a preference center form, within a global preference center program.

 

Your form can live under a Global Forms folder in Design Studio or as part of a global preference center program – I prefer it in the latter.

 

Add the following fields: email address, preference center fields, and the standard Marketo Unsubscribe field.Change the field labels and add rich text with extra spaces:

Marketo Preference Center Form

Form pre-fill is enabled by default in your admin section, but you can double-check each field to make sure it’s enabled so that subscribers can see what they are already subscribed to.

 

Form Prefill

Note: If you’re using a Marketo form embed code on your website, form pre-fill is not an option. Use an iFrame instead. See Marketo Forms: Which application is right for you?)

 

Ideally, you want the form to automatically uncheck preference center fields if a subscriber checks Unsubscribe. This can only be done right now with Javascript. Search in the community (there isn’t anything I could find as of this posting) or contact services@marketo.com to scope out a project to do this. You can also get creative with Visibility Rules.

 

4. Create a preference center page and preference center confirmation page(s), then edit the form to direct completions to the confirmation page(s).

 

Now you have to put the form somewhere and send form completions to a confirmation page.You can either:

 

  • Put the preference center form on your website, and send completions to a confirmation page on your website. Preferred method is to use iframe code so you preserve Marketo form pre-fill functionality. First, put the form on a blank Marketo landing page. Then, give your web developer the page URL so he/she can create an iframe for it.
  • Put the preference center on a Marketo landing page, and send completions to a Marketo confirmation page.

 

Go back to the form to direct completions to the confirmation page. If you want, you can create two different confirmation pages depending on if the subscriber updates preferences or unsubscribes completely. In the Form, go to Form Settings > Settings, and choose Add Choice.

 

Marketo Form SettingsMarketo Add Choice

 

5. Create all the required batch and trigger campaigns to update subscriber preferences.

 

At a minimum, I create these three campaigns:

Campaigns

Warning: This should go without saying but you’ll want to activate and test first, adding a filter to each campaign smart list for your test list.

 

01-Update Preferences (Batch-Existing): Decide what you’ll do with existing records in your database. Who will you subscribe to all preferences as a default? At a MINIMUM, make sure to exclude those who are have Unsubscribed, Email Invalid, Blacklisted checked as true.

Screen Shot 2015-11-21 at 10.15.07 PM

Screen Shot 2015-11-21 at 10.17.23 PM

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

02-Update Preferences (Trigger-New): Likewise, decide how you’ll opt-in new subscribers to preferences. How do new subscribers currently opt-in? Do you include implicit opt-ins such as any form fill out? Do opt-ins get automatically added to all preferences at the outset? Make sure to include privacy and anti-spam regulations in your considerations.

Screen Shot 2015-11-21 at 10.18.29 PMScreen Shot 2015-11-21 at 10.17.23 PM

03-Unsubscribe from all Preferences: A global unsubscribe campaign will uncheck all preferences if a subscriber chooses to unsubscribe. Optional: Include an auto-responder confirmation email and flow step here.

Screen Shot 2015-11-21 at 10.19.39 PMScreen Shot 2015-11-21 at 10.19.49 PM

 

If your preference center includes frequency preferences, you can do this in a few ways but none are as straightforward:

  • Create a newsletter roll-up by frequency and subscribe these subscribers to it – this involves creating more content!
  • Use a wait step - change unsubscribe to true, wait X period, then change unsubscribe back to false
  • Use an engagement program and set the cadence accordingly.

 

6. Edit your unsubscribe footer to direct subscribers to the preference center.

 

Now, customize your email footer so you send subscribers to a preference center, in addition to OR in place of an unsubscribe page. Go to Admin - Email and edit the Unsubscribe HTML and Text. You can just add your preference center messaging and URL. If you prefer to replace the unsubscribe page completely then do change the part below in bold, and remove the part in italics.

%mkt_opt_out_prefix%YourUnsubscribePageLink.html?mkt_unsubscribe=1&mkt_tok=##MKT_TOK##

 

More instructions here on our Docs site: Edit the Unsubscribe Message.

 

Screen Shot 2015-11-21 at 10.22.44 PM

7. Test your email footer, forms, landing pages, and campaigns.

 

Add test email addresses to all smart campaign filters. You’ll want to check that any qualifying existing and new subscribers have their preferences marked to true, and any subscribers who unsubscribe have their preferences changed to false.Screen Shot 2015-11-21 at 10.23.42 PM

 

8. Batch update preferences for existing leads and activate trigger for all new leads.

 

Once testing is completed, you are ready to go live! Run your batch campaign to update preferences for all existing records. Then, activate all trigger campaigns for incoming subscribers.

 

9. Develop a process to include preferences in all your email sends.

 

Now you’re ready to USE email preferences. Document this process, include it in all program template smart lists that will be cloned, and socialize across your team. You have to remember to include email preferences (is true) in future email sends, including those in engagement programs.

 

10. Monitor and QA for several weeks.

 

Be sure to monitor the results tab for active trigger campaigns. I also like to have smart lists in my preference center program for quick and ongoing reference.

Screen Shot 2015-11-21 at 10.24.27 PM

 

 

 

 

 

 

 

 

 

 

 

EXAMPLE: MARKETO’S EMAIL PREFERENCE CENTER

 

Need some more ideas? There are plenty of examples if you Google “preference center examples.” Below is Marketo’s: http://pages2.marketo.com/emailsubscription.html.

 

Screen Shot 2015-11-21 at 10.25.23 PM

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ADDITIONAL RESOURCES

Sometimes it's difficult to know which version of a Field Name that you need to use in a given place, so here's a quick reference for which source uses the SOAP or REST version of a field name:

 

WhereWhich
Munchkin APISOAP
Forms 2 APISOAP
List Import(UI)SOAP
List Import(REST API)REST
Webhooks Response MappingsSOAP
SOAP APISOAP
REST APIREST

 

Are there other places where you're confused about which field name you should use?  Let us know in the comments and we can help you out.

Whenever I have someone new working in Marketo, I like to give them a checklist of things to validate before they launch a campaign. It makes me think of those studies that show that if a doctor simply follows a checklist, (s)he is way less likely to make simple mistakes. And there are so many simple mistakes we can make in Marketo accidentally. Here's a basic checklist to get you started, though obviously you need to customize it with things specific to your organization and I've left off validation of the assets themselves.

 

Program Setup

  • The program name follows the naming convention.
  • Confirm you have categorized your marketing activity in the right channel.
  • The required tags have been populated correctly.
  • The appropriate optional tags have been added.
  • The period cost has been added.
  • Folders have been created for assets and campaigns and items are in the appropriate folder.
  • Tokens set up on the program level have been updated, if appropriate.

List

  • The list of leads includes only marketable leads.
  • The list of leads does not include any leads that are on master suppression lists.
  • Do a “sanity check” on the leads that will qualify for this program by looking at the Qualified Leads list from the Schedule tab of the send campaign to ensure it matches the original list.

Smart Campaigns

  • The smart campaign names follows the naming conventions.
  • A smart campaign exists to change program status for each status in the channel.
  • A smart campaign has been created and run to test the email send.
  • The qualification rules have been updated if leads are allowed to run through more than once.
  • The checkbox has been selected to honor Communication Limits.
  • Employees have been excluded from running through program status campaigns.
  • If a form fill-out should trigger an auto-response email, this email send is included in the Flow step.
  • The number of qualified leads in the send email campaigns matches the number of leads in the original target list and is the expected count.
  • The schedule (and reoccurrence) matches your expectations.

Screen Shot 2015-08-24 at 11.15.34 AM.png

 

There is some confusion over what happens when leads are merged manually in CRM, SFDC, or Marketo. This guide provides some explanation and clarification on that topic... and some useful pointers to documentation in the product.

 

To summarize...

  • If two duplicate Leads or Contacts are synched to SFDC, if you Merge them in SalesForce, they are merged in Marketo
  • If two duplicate Leads or Contacts are synched to CRM, if you Merge them in Dynamics, they are merged in Marketo
  • if two duplicate Leads or Contacts are synched to Salesforce.. and you merge them in Marketo.. they are merged in Salesforce
  • if two duplicate Leads or Contacts are synched to Microsoft Dynamics, the leads cannot be merged in Marketo. They would have to be merged in Dynamics.

 

Documentation:

Merging a Lead in Salesforce

Merging a Lead in Marketo

     SFDC Effect:

          Leads

          Contacts

datepicker2.jpg

We often get questions on DateTime fields in the SOAP api, and how Marketo handles them (yes, this applies only to SOAP).

 

So, rule #1. Always use W3c formatted dates. What's that, you ask? I'm glad you asked.. here are the details on Date and Time Formats

     Timezone (U.S. Pacific): 2015-11-09T16:19:52-07:00

     No Timezone: 2015-11-09T16:19:52

 

So the issue here is how DateTimes are handled when the timezone is not specified.

  • For a custom object the timezone is assumed to be the same as the instance into which the request is sent. That's configurable in the admin section.
  • For a lead, the time is assumed to be US Central Time (GMT-0600)

 

To avoid this, simply specify the DateTime.

This is the third in a multi-part series on precautions you can take when building and testing directly in production. The first part on instance-wide restrictions can be found here. The second part on program-specific restrictions can be found here. Now let's delve into some testing approaches.

Email Programs

 

  • Clone the email program to create a new version for testing. Rename this very clearly; for example, you might choose to prefix this with TEST in the name.

 

  • Immediately switch the Audience to your list of test leads.

 

  • Click on the refresh button to see the new count of leads to validate that it matches the number of test leads:


  • Click on the hyperlinked number to view the full list of leads that will be impacted if you run the campaign.

 

  • Once you are confident the program will only impact your test leads, schedule your program for at least 15 minutes from the current time. This allows you extra time to unapprove the program if you discover some mistake.


  • Approve the program.


Engagement (Nurture) Programs

  • Test emails through Send Sample Email first.

  • Choose an example lead to see what the email would look like with personalized and/or dynamic content for that specific individual but always send to your own email address:

  • Use the test stream functionality to mimic a cast to just one specific test lead:

  • Add additional filters on smart campaigns that you know will exclude your audience from qualifying until you are ready to remove them. The two most common choices are a reference to the specific email address of the tester and a reference to a seed list (a smart list of email addresses or a static list):

 

OR

Event and Default Programs

  • Test emails through Send Sample Email first.

  • Choose an example lead to see what the email would look like with personalized and/or dynamic content for that specific individual but always send to your own email address:

  • Add additional filters on smart campaigns that you know will exclude your audience from qualifying until you are ready to remove them. The two most common choices are a reference to the specific email address of the tester and a reference to a seed list (a smart list of email addresses or a static list):

OR

  • Delete test leads after you finish testing to minimize reporting impact.

This is the second in a multi-part series on precautions you can take when building and testing directly in production. The first part on instance-wide restrictions can be found here. Now let's delve into some program-specific approaches.

 

In addition to the built-in functionality across the entire instance, certain precautions can be taken depending on the kind of program you are working on.

 

Email Programs

 

  • Do not select a schedule or choose a schedule at least a week away.

 

  • Do not select the Approve Program button until you are ready to send out the email.



Engagement (Nurture) Programs

  • Turn off the program in the Setup tab. This prevents any emails or activities from being triggered by the engagement program.



  • Deactivate the programs within the engagement streams.



  • Do not add members to the engagement program streams.


Event and Default Programs

  • Add additional filters on smart campaigns that you know will exclude your audience from qualifying until you are ready to remove them. The two most common choices are a reference to the specific email address of the builder and a reference to a seed list (only one choice is necessary):


OR

  • Leave assets unapproved for as long as possible while building. Keep in mind that assets must be approved in order to be added to a flow step or smart list filter/trigger.

 

  • Do not activate trigger campaigns other than those using Campaign is Requested triggers.

 

  • Do not schedule or run batch campaigns.

This post originally appears on the Marketo Developer's blog, here.

Read Part 1 here

For the most part, errors received back from the Marketo REST API will not be automatically recoverable.  However, there are a handful of cases where you can recover automatically, or ensure you never see a certain type of error.

Request-Size Errors

As we looked at in the last post of this series, Marketo will emit HTTP Status code 414 if your URI exceeds 8KiB in length, or 413 if your request body exceeds 1MB, or 10MB for Import Lead.  Though 414s will be rare, you might see them if you’re using Get Leads By Filter type to request records based on 300 separate GUIDs or similar criteria.  Say you have the following request:

https://AAA-BBB-CCC.mktorest.com/rest/v1/leads.json?filterType=customGUID&fields=email,company…firstName,lastName

When you submit the request, Marketo returns a status of 414 because the URI exceeds 8KiB.  To handle this, we need to alter the pattern of this request, and submit a POST instead of a GET, append ‘_method=GET’ to the URI, and pass the querystring in the request body as a x-www-form-urlencoded request instead:

URI:

https://AAA-BBB-CCC.mktorest.com/rest/v1/leads.json?_method=GET

Request Body:

filterType=customGUID&fields=email,company…firstName,lastName

Instead of catching this exception from the HTTP response, however, we can just check the total length of the request at runtime, and deploy this alternative pattern if the URI exceeds 8k.  Alternatively, you could use the POST Method in all cases for batch retrievals of records.

For 413s, we can follow a similar pattern, checking the length of the request body when adding records during the serialization step, and splitting the request into multiple parts if this limit would be exceeded.

Authentication Errors

Our next class of recoverable errors is related to authentication.  When a formerly valid access token is used after its expires_in period has elapsed, the first usage will return an error code of 602, “Access token expired.”  After this, using the same token will return a 601, “Access token invalid.”  Any other usage of a string which is not a valid access token for the target subscription will result in a 601.  In both cases, this error can be recovered from by reauthenticating and passing the new access token with a retry of the failed request.

Timeouts

In very rare circumstances, a call may return a 604, “Request timed out,” after the 30 second timeout period has elapsed.  For batched requests, such as Create/Update Leads, the request can be split up into smaller batches and retried until success is returned (if the batch is split to less than 100 records and the request is still timing out, you should probably file a support case).  The most common other case is with asset approval calls, where a lock may be held on the current approved record by another user or service, such as the case of an Email or Email Template.  In these cases, exponential backoff should be used for retries to allow for any existing locks to be resolved.

Check back in the coming weeks for the final part of the series where we’ll take a closer look at some specific, non-recoverable errors.