Big Marketo, Pt 2: Use static lists instead of creating fields

[Robb_Barrett]

Here's a piece I recently wrote up to share with some colleagues who felt that they needed to add a lot of custom fields to our Marketo DB for one particular product line in one particular region.  The problem here is that we have so many product lines in so many regions that giving this access to one opens up the floodgates to all.  The problem is that I'm not a fan of sparsely populated data fields - fields that have only a small records who will have something other than the default value.

If the field can't work for everyone everywhere, I'm not interested in adding it to the database.  With that, here's my justification for using static lists instead of custom fields.

Using Flex Fields and Static Lists to act as custom fields

This document will show how to use temporary fields, “Flex Fields”, on forms in place of creating custom fields and then store the data in either Static Lists of note fields for permanent, long term storage and usage.

Flex Fields: We allow four flex fields available for use by all Marketo users. These are called Flex Field 1, Flex Field 2, Flex Field 3 and Flex Field 4. These can be used to store any type of information temporarily – for a half hour – which is enough time to move the data to either a Note field or a Static List for segmentation purposes.

Types of Data: there are 3 main types of questions and data:

• Finite Choices: These are questions that have a limited number of answers such as Yes / No or Multiple Choice
• Scalar Data: These are data that use a number to represent a scale. Examples would be number of users, ratings, etc. If this information can be grouped – such as “From 1 to 100” or “Less than 100” or “More than 9000” it can be stored in lists for those ranges: 1-100, 101-500, 501-1000, etc. These ranges can be unique for each form and product line.
• Free Form Text: This is data that the form respondent supplies by typing in an answer. This data is not standardized, may contain typing errors and cannot be used for reporting.

Fields vs. Lists:

Fields are points of data that exist on every record in every region in the database. Fields tend to be limited to data points applicable to every lead in every region or at least enough leads to compromise a significant amount, or are used by numerous product lines and regions.  While information like Name, Email Address, Phone Number, Company Name and the like are applicable to every lead some information like Number of Operating Theaters, Number of Births, Number of Doctors, Number of Beds in ICU are not used by all product lines but are used by several product lines in several regions.

Static Lists are lists to which we can add records to indicate having a response to a custom question. If we have a question that cannot be answered by an existing field, and that answer is multiple choice or Yes / No, we can write that record to a list to show interest.

Most of the existing roles can create static lists and add or remove members from the list. In combination with the Flex Fields, thousands of points of data can be collected without adding a custom field.

If the data is more free-form in nature, that is to say it’s information that the customer provides that is not their personal contact information, or it’s information that then needs to be passed to SalesForce, that information can be written to a note field.

Presentation on Forms:

When creating a form, add the custom field and then change the label to have the field appear like a custom question. Below is an example of a form used by Healthcare Digital for collecting specific product interest by using a Flex Field and assigning a couple of choices the form respondent can pick from.

Both of these questions below tie to Flex Fields (Values shown for example)

Storing in Static Lists:

Within Marketo, there is a Smart Campaign flow step called “Add to List.” Within the flow step, there is a button on the Top Right called “Add Choice” which acts as IF/THEN type of logic. Putting in multiple choices in a single step means that Marketo will look for the first time the conditions are true and then abandon the rest of the choices. Alternatively, you can add multiple flow steps.  The example below is from the Product Preference project in place for Europe, where information that maps to a single, temporary Marketo fields needs to be stored permanently. The information is delivered with multiple values at once, which then need to be separated into lists.  It’s worth noting that almost 100 static lists are used to track interest in products for Core Imaging alone.

Here is an example of using a Flex Field to drive a product interest into a Static List:

Storing in Notes:

When the information needs to be passed to SalesForce, the only mechanism is to either put in a pre-existing field or into a note field. This also works for data that cannot be used for segmentation, such as self-entered information.  An example I like to use is the number of says someone could type in “Saint Joseph’s Hospital”: St. Joseph, St Joseph’s, St. Joe’s, SJHC, etc. All of these appear as completely discrete values to a computer which would have no way to group them. This self-entered information is best put into a note field.

Example: In this Smart Campaign, we build a Form Lead Note.  We’ve standardized how we use the Flex Fields on these forms.

Since the entire new value isn’t visible, here are the New Values:

Flex Field 1 is always used for Product Interest on certain Healthcare Digital forms:

Lead Notes: {{lead.contact question}}; Facility Type: {{lead.Facility Type}}; Product interest: {{lead.Flex Field 1}}

Flex Field 4 is always used for miscellaneous purposes on Healthcare Digital forms:

Lead Notes: {{lead.contact question}}; Facility Type: {{lead.Facility Type}}; Product interest: {{lead.Flex Field 1}}; {{lead.Flex Field 4}}

These values then carry over to SFDC where they appear in the Notes field.

Flex Fields used in scoring campaigns

Sometimes for product specific scoring, we want to ask questions that are very unique to an individual product. An example here is for our Cardiology product line, which asks which kinds of labs the hospital has. We store this information in Flex Field 3 from the form. When the form is filled out, this scoring workflow is triggered:

This scoring program will only start if the person indicates they have one of the above mentioned Cardiology Lab environments, which is asked on the form.

Using Static Lists for Segmentation

Now that you’ve seen examples how to translate form questions to Static Lists, the next step is to show you how those lists can be used like custom fields.

A Best Practice for segmentation lists is to create a program in an Operational Programs folder. This is an Operational Type program used only to house your lists.  These can also be stored in the Lead Database, but to make things simple we’ll show how these create what we in Healthcare Digital call “Core Lists.”

Here you’ll see the Core Lists we use for Cardiology. In here are two types of lists: Static Lists and Smart Lists. A static list is basically a list of names that you decide who is on or off.  A Smart List is more like a query: you use logic to determine if someone should be a member or not.

Static Lists give you ultimate control over who is on the lists but need to have Smart Campaigns – workflows – to add or remove names.

Smart Lists constantly update themselves as records qualify or disqualify. Smart lists can use static lists as inclusion or exclusion criteria.

In this example, we have created lists for our various Cardiology products. Lists marked as “IB” are current customers. CCE is one version of our product, CCI, CCW and DMS are other versions. Because this product line is very volatile – new products are constantly added, product names are subject to change and product lines can be retired – having these products as unique fields is not scalable. While the product is called DMS today it could be called ABC or something completely different tomorrow. Once a field is created in Marketo and is populated with data you cannot change the field name. It is also very labor intensive to remove fields.

Building a Segment

In this next graphic, you’ll see how a Smart List uses several Static Lists for segmentation. The purpose of this list is to dynamically build a list of people at hospitals who own our product, who would be interested in hearing about our Perinatal product line.

We know that hospitals have numerous specialties that are of no interest to each other. If we were to generate a list of all hospitals who owned a product and then sent to all records working at that hospital our Unsubscribe numbers would quickly elevate. Why would a neurosurgeon or a proctologist care about Perinatal software? Likewise, as a software company, we know that executives, business analysts and IT personel will sign up for information on this product line while they are evaluating or installing the product but they have no interest in communications meant for the end users.

This Smart List combines all people we know who are listed as being tied to one of the 12 Perinatal products and then filters them by job title. Here were are looking for 107 values that we feel are unique to people who work in women’s health: maternity, labor and delivery, infant care, obstetrics or gynecology, etc.

If these product interests were separate fields we would have to create a very complex list saying (1 or 2 or 3 or 4 or 5 or 6 or 7 or 8 or 9 or 10 or 11 or 12 or 13) and 14 and 15 and 16 and 17 as each product would be a separate line. From experience, the concept of “OR” and parenthesis is hard to explain to an average Marketo user while just putting all of the lists into a single box is much easier. Every time we add in a product line we would have to add it to this list and then manually rewrite the Advanced Filters as points 14-17 would need to be incremented by the number of new fields added in parentheses.

Living From Experience:

Prior to 2015, Healthcare Digital had our own instance of Marketo which had been in place since 2011. When it started, the thought was that unique fields would be used as needed and every product interest could have a unique field to show interest.

Over 5 years, that ended up created 121 fields. Many of these are for products that never ended up being real – we prepared for them but they were canceled. Many of these product ended up being retired. Others had their names changed and we were stuck referring to them by an old name. We also made fields to show is someone owned the product or was merely interested in it. This has been difficult to work with.

REST API Name
AreyouanexisitingCPNcustomer	CBS-BusinessETM	CBS-PracticeManagement	SS-Periop-AnesthesiaInteractionChecking	SS_PACSIW_Services
areyouanexistingC360customer	CBS-BusinessEWS	CBS-PracticeManagement-VAR	SS-Periop-BedManager	SS_PACS_Services
AreyouanexistingCBcustomer	CBS-BusinessHPA	CBS-PracticeSolution	SS-Periop-BusinessContinuity	SS_Periop_Analytics
AreyouanexistingCCAcustomer	CBS-BusinessInformatics	CBS-PracticeSolution-VAR	SS-Periop-BusinessObjectsReporting	SS_Periop_ePREOP
areyouanexistingCentricitycustomer	CBS-BusinessMCA	CBSCEServices	SS-Periop-ClinicalInformationViewer	SS_Periop_Services
AreyouanexistingCPACScustomer	CBS-BusinessPatientProtocolManager	CBSPopHealthManagement	SS-Periop-CPAandCPM	SS_RISIC_Services
AreyouanexistingCPScustomer	CBS-BusinessPOL	CBSVARServices	SS-Periop-NursingDocumentation
AreyouanexistingCVITcustomer	CBS-EDIServices	CBS_Business_FRM	SS-Periop-PACUDocumentation
areyouanexistingDPcustomer	CBS-EMR	CBS_Business_Services	SS-Periop-PATClinic
areyouanexistingEMRcustomer	CBS-EMR-VAR	CBS_GroupManagement_Services	SS-Periop-Perioperative
AreyouanexistingGEPACSIWcustomer	CBS-EMRClinicalContent	CBS_Practice_Services	SS-Periop-PerioperativeAnesthesia
AreyouanexistingGERIScustomer	CBS-EMRDocumentManagement	SS-Analytics	SS-Periop-PerioperativeManager
AreyouanexistingGMcustomer	CBS-EMReRX	SS-CentricityClinicalArchive	SS-Periop-PerioperativeTracker
AreyouanexistingPeriopcustomer	CBS-EMRPatientPortal	SS-CPN-Analytics	SS-Periop-Scanning
areyouanexistingPopHealthcustomer	CBS-EMRSecureMessaging	SS-CPN-Connect	SS-Periop-SterileProcessingManager
AreyouanexistingUniversalViewercustomer	CBS-GroupManagement	SS-CPN-IB	SS-Periop-SupplyChain
AreyouanexistingVARcustomer	CBS-GroupManagementAnalyzer	SS-CPN-Interoperability	SS-Periop-Weblink
Are_you_an_existing_CE_customer	CBS-GroupManagementDocumentMgmt	SS-CPN-LandD	SS-RIS-IC
CBS-Business	CBS-GroupManagementEligibility	SS-CPN-NICU	SS-UniversalViewer-CPACS
CBS-BusinessAdvancedWeb	CBS-GroupManagementHostedClaimsManager	SS-CPN-Services	SS-UniversalViewer-IW
CBS-BusinessAnesthesia_Radiation	CBS-GroupManagementPatientPortal	SS-CPN-WebAccess	SS-ZFP
CBS-BusinessASP	CBS-Hardware	SS-CVIS	SSC360CaseArchive
CBS-BusinessBAR	CBS-HealthCheck	SS-CVPACS	SSC360CaseExchange
CBS-BusinessBundledCareManager	CBS-Lab-Laboratory	SS-Integration	SSCCAVAR
CBS-BusinessCBO	CBS-Mobile	SS-MobileAccess	SSCVITUV
CBS-BusinessClinicalConnectivity	CBS-Pharm-Administration	SS-Omnyx	SSGEHealthCloud
CBS-BusinessConsulting	CBS-Pharm-Pharmacy	SS-OneView	SS_AW
CBS-BusinessEDIServices	CBS-PracticeAnalytics	SS-PACS	SS_CCA_Services
CBS-PracticeDocumentManagement	SS-PACSIW	SS_CVIT_Services

When we migrated to the Global instance we made a decision to never make this mistake again. This wasn’t scalable, was hard to support and very hard to train when product names change or retire. All of these issues go away by using lists.

Conclusion

It is my experience that there are very few reasons for adding in new fields, especially product specific or region specific fields. Having given this much thought, testing and experience and conferring with other Marketo Experts, Champions and Consultants, the consensus is that static lists work very well for preserving information that is Boolean in nature, such as a product interest.

As a Marketo admin, my goal isn’t to reject all requests but to work with the regional users and show them how results can be achieved without disrupting the database by adding fields. Along with the other admins we carefully consider and discuss proposals for new fields and judge it on the following criteria:

• Can the same results be achieved in any other way?
• Would the requested field serve any other region or product line?
• Is the field name going to persist for years?
• Is the field relevant to a large portion of the database? (At least 15%)

If we can achieve results without adding a new field and if data is only relevant to one product line or region then we are not likely to add in the new field.

The reason for not adding new fields is simply scale. If we do it for one product in one region we have to offer the same opportunity for every other product in every region. This is not scalable and would be very difficult to administer. There are too many products in too many regions and in the end only a very small number of records would utilize the field.