Unlocking the Potential of Program Member Custom Fields

Transcript

Hi, my name is Grace Brebner and today I’m going to be talking to you about one of the most game-changing new features in Marketo. But before we get too carried away here, I think it’s only appropriate that I give you a little bit of an introduction to myself so you know who you’re going to be listening to for the next half hour. I’m Grace Brebner. I’m the Senior Manager of Client Services for the APAC region at Digital Pi. I’m a Marketo-certified solutions architect, a three-time Marketo champion and FELIS50 alum. I co-run both the Auckland Marketo User Group and the Virtual APAC User Group. And I’m also one half of the Automation Geeks YouTube channel. While I lose track at this point, I’ve got about five years of experience in Marketo and seven in marketing automation across a range of industries, both in-house and agency side. And an important thing you should know about me before we get too much further in here is that I am an absolute GIF fiend. If a picture says a thousand words, I wholeheartedly believe that a GIF says 10,000. So there’s going to be a lot in this presentation. Just be prepared. But enough about me. To the topic at hand. Today I wanted to discuss a relatively new feature of Marketo that, based on my brief survey of a few people I know, seems to be underutilized and not terribly well understood in this region. It’s a feature that, in my opinion, is actually a bit of a game changer. Program member custom fields are one of the most impactful new pieces of technology added to Marketo recently. They may seem like just a new field type, but to refer to them as only that really doesn’t effectively convey the kind of far reaching impact that PMCFs can have on your instance if they’re applied with thoughtful consideration. So today I’m going to give you a quick explanation of what PMCFs are, run through a number of real world scenarios in which PMCFs could have meaningful impact on your business, and also give you some practical advice on key considerations you should be giving thought to when you go about setting them up in your instance. There will be a Q&A at the end of the session, so if you have questions along the way, please do submit them as we go. Fast up. Going by the book. Program member custom fields, or PMCFs as they’re more easily called, are custom fields that you can create in Marketo that collect information that’s specific to a program. They’re still associated with a single person, but their values aren’t visible or stored on the person object. They’re visible in the members tab of a program instead. They can be created at the field admin level as any number of different field types, and can be used in Marketo forms, smart list filters, triggers, and flow steps. The values on a PMCF field are associated with a program and can only be viewed in the members tab within that program, but they can be called from a smart list or a smart campaign outside that program. Cool? Clear as mud, right? Well, in reality, that’s kind of a dense download of information that doesn’t really do justice to what actually makes PMCFs interesting. To really understand what actually makes them interesting, we need to start by highlighting how data normally works in Marketo. Generally, in Marketo, fields basically have a one-to-one relationship with a person record. You collect a bunch of information about an individual person, and no matter where you look at it from, that data is the same. The field stores one value. It is what it is. And if the value changes over time, well, the previous value is going to be overwritten. It’s lost. That can be a challenge when you’re looking at data points that do change over time, because generally speaking, the fields represent a point-in-time snapshot of their current state at the present moment. Marketability status would tell you what someone’s marketability status is right now, but it doesn’t help you inherently answer any questions about their marketability status yesterday, or the day before, or at the point in time of some other important event. PMCFs change this. Program member custom fields don’t write data to the person record itself, but rather let you record information to a person’s membership record within a program. And because a person can theoretically exist in every single program in your instance, that’s a lot of data. So those values you have, which otherwise only represent a point-in-time value at the present moment, instead capture the point-in-time value at whatever moment you designate as relevant within the context of any given program, all while technically only using one field. Neat. That’s fun. But really, what are you actually supposed to do with that? Well, there’s a bunch of real-world applications for program member custom fields, so let’s look at a few. Well, here’s the first major use case. PMCFs are really useful when you’re collecting one-off data. Have you ever found yourself needing to collect one-off information that’s only relevant within the context of a single campaign? Are you sick and tired of creating a new field every time you need to collect someone’s t-shirt size or find out their dietary requirements? Is your instance stuffed full of fields that you’ve used once and never looked at again? Well have PMCFs got a deal for you? All jokes aside, PMCFs can actually solve this issue for you. Even if you started using burner fields instead, PMCFs are a much more efficient way of solving this problem by letting you store the data only at the program level. Some common scenarios for these one-off use cases can be things like questions for the speaker at an event, answers to a competition entry question, dietary requirements or food preferences, preferred time requests for events, clothing size preferences, and really like literally any information you’re collecting that’s unique and specific to one single individual program, PMCF it. And if I need to state the obvious of why it is that we like this, it’s because it’s tidy. It’s just so much cleaner. Instead of having to create individual single fields and having them clutter up your instance, or even having burner fields that, while a little more efficient, still require systems of management to ensure that they’re only used by one program at a time, wiped after use, etc, etc, PMCFs basically apply the philosophy of a burner field within a much tidier context, giving you a single field that can be used by any program for whatever given purpose, but unlike burner fields, they can be used by multiple programs at once, the values don’t interfere with each other, and they don’t have to be wiped. You end up with less mess, which should be a priority for every Marketo instance. Okay, great. So that’s pretty neat and tidy and satisfying, but really that application just makes a few things easier and will make most Marketo admins feel a bit better about their custom field perception. It’s not revolutionary, and it doesn’t actually have much impact on a business. But here’s where the potential applications get more interesting. The second key use case, snapshotting data at a point in time. Sounds harmless on the surface, but bear with me. Have you ever been asked to track the marketability of your database over time? This seemingly harmless question has driven its fair share of Marketo users to the border of insanity, because, well, it’s just not as simple a question to answer as it might seem. I mean, how would you go about trying to answer it? You might try pulling a person performance report to show all unmarketable people grouped by date of creation, which, 9 times out of 10 if graphed, would show your marketability increasing over time. But it would be wrong. Why? Well, if you dig a little further, you’ll probably find that it doesn’t align to your email performance, because it’s not a view of how the proportional marketability rate of your database trends month on month. It’s a view of how marketability trends based on the length of time someone has been in your database, and people who have been in your database for longer have had more time to unsubscribe. A go. It looks good. It paints a flattering picture. But it doesn’t paint an accurate one. You’re incorrectly inferring past performance from the current state of an inherently flexible and constantly changing field. It’s wrong. And it will lead you to draw false conclusions. But to add more complexity to that question, how do you actually answer it meaningfully? Don’t get me wrong. Having visibility over the marketability of your database and how it’s changing over time is great. But if you aren’t getting meaningful insight over which programs might be driving certain trends positively or negatively, it’s little more than a vanity metric. What you really want is insight that not only tells you how it’s changing, but also indicates steps you can take to push it in the right direction. Surprise, surprise. Program member custom fields are a game changer here. If you stamp the marketability status of a person to a PMCF when they touch a program, it gives you visibility over how their marketability is changing over time. But more importantly, if you do it right, it also gives you insight over why. For example, here’s a real life scenario in which PMCFs made an impact for a business. A business who will remain unnamed found that the number of marketable highly engaged leads in their database was dropping month on month. So they implemented PMCFs to help trace the cause of the problem, populating the month marketability status of a lead to a PMCF whenever they filled in a form associated with a program. A few months after implementing this, they discovered a trend. People who were previously explicitly opted into marketing were often changing to the status of implicitly opted out after engaging with a content download form. On investigating further, the company found that much like repetitively screaming at someone to love you, asking known people to constantly reaffirm their explicit opt-in every single time they fill in a form was inadvertently having the opposite effect, causing them to lose highly engaged leads. In discussion with their legal team, they clarified that their compliance environment didn’t actually require explicit re-consent with every engagement as long as a clear opt-out pathway was present in all necessary communications. So they changed their process, making the explicit opt-in field visible only if it hadn’t already been obtained and hey presto, disaster averted thanks to the insight provided by PMCFs. This has applications for many scenarios where you want to track a value that changes over time. What if you want to know at what point in a nurture program a person MQLs? Use nested default programs with an MQL true-false field. PMCF it? Done. If you want to track which programs are most engaging at different lead statuses, stamp the status of everyone when they enter or engage in a program to a sufficient degree, PMCF it? Done. Want to track the date at which something specific happens within a program? PMCF date field, stamp it? Done. Want to know what UTM drove someone to a specific program? PMCF field? Done. There are almost infinite applications, you just have to be creative. And that’s really just the tip of the iceberg. But before you go racing off to implement PMCFs in your instance, here’s a few things you should consider along the way. First up, be aware that you can only have 20 program member custom fields in your instance. No more. That might freak you out at first, but really if you approach it right, you shouldn’t run into the limit actually limiting you. Remember, every field can have a different value in every single program, so 20 actually does scale quite massively. So you can sigh a bit of a breath of relief on that one. But the main point to this is that you will want to be mindful of your strategic approach to creating and using the fields. The most common recommendation here, which I do agree with, is to approach them with a similar philosophy to what’s often referred to as burner fields or library fields. So burner or library fields are a strategic approach to custom field creation that many admins implement to reduce the impact of throwaway fields on their instance, fields that are created for a single use case for a single program and then never used again. You basically create a handful of fields across every field type, provide them with generic names like string field one, string field two, and Boolean field one and Boolean field two. And if you follow a similar approach to setting up your PMCFs, making sure you leave a few up your sleeve for future use cases, you should actually be fine with just 20. The important clarification to this approach though is it will be important to ensure you have clear documentation and guidelines on your preferred processes for using the fields, since it won’t be obvious from name alone what they’re for. Many people have found it really helpful to use the description box in the program name section to provide more insight on how PMCFs are being used in that program, and I would recommend implementing that process. As for actually using them, PMCFs can be used following the already existing member token structure in Marketo, and you can reference them across a bunch of different assets in the same way you’d use other tokens in emails, landing pages, SMSs, push notifications, and webhooks. They can also be used in task creation, interesting moments, and in change data flow steps too. But remember, for these applications, they must be used within the relevant program. PMCF tokens cannot be used in VelocityScript, in pre-headers, in date tokens, in wait steps, or in snippets. And it’s really important to highlight that if you want to use PMCF fields in a form, it must be a local form, i.e. in a program, in marketing activities, not a global form in Design Studio. This is a bit of a pain if you’re trying to discourage local form usage within your instance, which hot tip, if you’re not, you should. And to emphasize again, really that point applies to all Design Studio assets, forms, landing pages, emails. It must be local to pick up or populate a PMCF value within the program. But, really that isn’t too major. Most use cases for forms in particular can be resolved by writing the appropriate value to a PMCF through a smart campaign instead, even if in some edge cases it requires the temporary use of a burner field to transfer the info. You cannot currently sync PMCFs to Salesforce campaigns, it’s important to highlight, and you also cannot currently create score-type PMCFs. But, you can help make those functions available. If you’re interested in either of those functionalities, go find the ideas for them on the Marketo community and upvote them. Just don’t go drunk on that power. And again, another really important note, because PMCF data is stored on the program membership table, you will lose that data if you remove a person from the program. This is particularly important to note if you want to use them to collect information in engagement programs, but you’re removing people from those nurtures at a certain point in time. If you remove the person, the data has gone along with them. And finally, when it comes to viewing and reporting on PMCFs, it’s not perfect, but it is functional, and there’s a few important things to know. If you want to actually physically see the values associated with PMCFs in Marketo, at the moment there is only one place you will find them. It’s in the members tab of a program by adding PMCF fields as columns in the view. PMCF data is not available in Revenue Cycle Explorer, and this can make reporting across programs tricky, as you really need to do any of the number crunching outside of the system. For small analysis, you can manually export the data from the members tab of a program. And for larger scale, fortunately, you can both import to and export from the program member custom fields via API. This will be what you want to do for sure. So, here’s the key takeaways. One, PMCFs are a way of helping you track data points that are associated with someone’s membership in a program, instead of being directly associated with the person record. Two, they’re super handy if you want to use them to collect single-use, one-off information that’s only relevant to, and only ever really going to be used by one program. But three, they’re even more powerful when you use them to snapshot a point-in-time view of a person’s status. Four, you can have 20 in your instance, but just like Lego bricks, with careful planning, you’ll find they scale in all sorts of different ways. Five, yes, there are some limitations to their usage and visibility at the moment, but if you make good use of the API import and export functionality, you’ll find you’re able to make quick work of any bulk updates or major cross-program analysis. And in a nutshell, that’s PMCFs. I hope that’s given you a little bit more clarity on what program member custom fields are, how they can help you keep your instance tidy, how they can help you answer critical questions for your business that can help you continue to refine and improve your performance, and most importantly, I hope it’s given you some clear ideas on specific steps you can take to use them well. Now before we move on to Q&A, I do want to highlight some of the resources available to you as you start to put a plan in place for PMCFs, and also really any time you’re stuck with anything in your Marketo instance. First, obviously Marketo docs, the official documentation should always be your first port of call. Do not forget that it’s there for you. Marketo community is also an incredible resource. If you’re stuck on something, nine times out of 10, you are not the first person to encounter that scenario. You are likely to find a wealth of insightful info within the conversations that are happening in community, and if your question is not already there, ask it and you’re quite likely to have an answer on it pretty quickly. The always amazing Joe Reitz has a fantastic YouTube channel that is well known for his Marketo food series. Joe is an incredibly busy man, so while the channel hasn’t been updated recently, and while some of the UX and the videos might be a little different now, most of the info is just as accurate and just as valid as it always was. And finally, not to toot my own horn, but you can always swing by the Automation Geeks YouTube channel. Tag is run by myself and my dear friend Josh Pickles, who I also co-run the Auckland Marketo user group with. You’ll find live recordings from our user group, and a mix of stuff from short discussions about things like how to update your copyright year with tokens, to full blown rants about my favourite things about email templates and the email editor in Marketo. If you’re interested, you can find us at youtube.com forward slash the automation geeks. And otherwise, that’s PMCS. Now it’s time for your questions. Fantastic stuff, Grace. I tell you what, my GIF game has never felt more lacking. I’m sure you’ve all noticed though that unfortunately we’re still having a little bit of trouble with our Q&A functionality. So I’m going to jump in here as your MC to ask Grace a few questions I’m suspecting that some of you might have. So Grace, I’m really sorry we’re having a bit of problems with the Q&A, but selfishly I’m glad to have a chance to pick your brain. Always happy to be here to have my brain picked. So I might start off with a quick question around, can you embed a PMCF in an email to display like a normal token value? So really good question, actually this particular one. Yes, you can. It’s a confusing one that some people do get a little bit lost on because it wasn’t in the original functionality when PMCFs were first released. But it has been made available in a more recent update to the functionality. So yes, you can use a PMCF token in an email. I also will flag, I’ve had a direct line from the man himself while sitting here. I mentioned in the presentation that you cannot use PMCF fields in VelocityScript. Sanford Whiteman himself has actually just flicked me a message and said that’s no longer true. So it’s awesome functionality there that is also very much available. I however am not the expert on Velocity, so I will leave any specific questions anyone has about that to Sandy wherever they want to find them in the many places that they can. I love the community integrations and how interconnected you are there. I love that everyone’s always learning from one another. But good to see that there’s some updates that are always happening. So good answer and good insights from yourself and the community. I love it. So tying PMCFs into reporting. So can you tie PMCFs into Marketo reporting? At this stage that is not a functionality that is available to my knowledge. I’m sure that the Marketo team are working on that one because I know it is a common question. So that would definitely be another one that if that is a functionality that is of interest to you, do go find it in community and upvote the idea. You can get the data into third-party reporting tools like Power BI. Even if you’re so inclined you can export it into Excel and do some number crunching yourself. So there are definitely ways that you can go about getting that data visualized in different platforms but unfortunately at this stage it is not available as a native functionality within Marketo reporting. I love the upvote. In Adobe definitely the community speaks and when people ask for particular items and things like that and functionality within Marketo and other solutions we listen. Obviously we’ve brought in a couple of updates as you mentioned before which is good so I highly recommend everyone upvote this one as well. Maybe diving into this a little bit deeper as well, working yourself. What are some great tips maybe using? Obviously you’re not a fan of Excel. I personally love Excel by the way. If you are using different systems like Power BI or things like that what are some gotchas or some tips to get the best visibility from these reporting? I think one of the recommendations I would always make with these sorts of things is try to as best as you can as potentially someone who is not personally a developer understand what functionality is available there through the API, what you can get out of Marketo in a fairly automated fashion using API functionality. Personally through my career using Marketo I’ve found that almost every time someone asks me if the functionality is available and I say no it’s not I’m later proven wrong because there is always or at least there always seems to be some way of doing something. There is always where there’s a will there’s a way. There always seems to be a will and there always seems to be a way. I would highly recommend doing the best that you can to understand what functionality is available through the API export and definitely enlisting a developer in your team or making a case to your business of why would I need to invest in some of that functionality within your team, within your resource remit so that you can get those API usage functionalities out definitely. Now I love it and definitely a usable tip there and also linking into different teams to understand how they’re working too but it’s not just internal. You’ve touched on it a couple of times, utilizing the community. Was it automation geeks that people should sign on to? I’m sure you’ll have a couple of episodes coming up soon maybe around this. Oh there probably will be. So thank you but maybe another question that I had was what permissions maybe diving into different permissions what questions do you need to create PMCFs? Sure, that is a really good question because I think it’s really important to be mindful of the fact that there are only 20 of these available in your instance and in the same way I’m sure anyone who’s worked with custom fields before will be familiar with the fact that it can be difficult to delete or rename or make changes to fields once they’ve been created and especially once they’ve been used. So this is not functionality you want just anyone to have in your instance. It is available to anyone who currently has existing permissions to be able to create custom fields. I forget the specific name of that functionality. I think it’s field management permissions according to my notes if my notes are correct but it is probably not functionality you want everyone to have. So if program membership custom fields are something you think you might love to implement it’s probably also a good time to go and have a look at your role permissions. So see who in your instance has what role, what functionality that role has available to it. If that’s existing functionality that people do have the power over should they? Do you want to make a change there? Do you want to make that an admin only permission? Personally that would probably be my recommendation. It’s not functionality I would make available to generally everyone. There’s something you probably want to keep a fairly close rein on. But yes it is for anyone who can already create custom fields you will be able to create PMCS. I will note on that again like normal custom fields difficult to delete, difficult to rename once they’re in place and once they’re active. So do be thoughtful as you go through that process. I would probably while I mean I kind of have a love-hate relationship with Excel but I would recommend grabbing an Excel document together and probably putting together a bit of a strategy of what fields do you need, how are you going to use them, what are the names going to be. I would definitely recommend having a bit of a plan in place at first before you start digging into it. Perfect. Maybe diving into some of those permissions a little bit deeper like obviously with your experience at Digital Pi. I should get that right. Sounds like an inspector. So what are some of the tips on how you’ve been working throughout your career and utilising maybe permissions to get greater value out of Marketo as well? Sure. Excuse me, I’ve just drunk some of my water the wrong way around which is terrible. The joy of a live event so don’t worry. I should really know better than to like go and try to clog a bit of water right before I start to speak. Permissions. I think probably a few of the things that I do see, excuse me, oh that’s better. Some of the things I do see definitely is people having too many people with admin permissions, people who shouldn’t have admin permissions having admin permissions. So making sure that you’ve got a really clear idea of who should have what kind of specific role, how those roles break down, what those permissions are that those people with those roles have and making sure that you probably have a process in place where you’re going through and reviewing that sort of on a six month, 12 monthly basis depending on the scale of your business. If you have a rather large scale business you may have fairly high turnover in your user activity. You may have people who leave the business, who change a role, they’re using Marketo, they’re not using Marketo or they just sort of transition into a place where they’re not really using it as frequently as they once were. You want to be able to use those opportunities to go in and review people’s permissions, make sure people are still on the right permissions that they should have and removing or expiring permissions for anyone who should no longer have those kinds of permissions. I think the biggest mistake that I see is people who treat commissions as a one and done thing where it really shouldn’t be, it should be something that is actively considered and reviewed over time. Perfect, great answer and appreciate it. So I think we’ve got time for maybe one more question and it is, would you use PMCS for the five UTMs values or leave them on the person record? I think I’m going to come back with the answer that everyone always hates which is it depends. I know everyone really hates to have that be the answer but I do think and I mean I guess this is why consultants have jobs isn’t it because it depends. It depends on the specific case of your business, it depends on exactly how you want to report on things, it depends on how your business as a whole wants to report on things as well as how your marketing department or your MOPS department want to report on things. There are scenarios in which both options are appropriate and relevant. So I would definitely say that it’s something that you should probably have a thoughtful discussion with your business on what the purpose of collecting this information is and what the wider business impact of it is. So if for example you are attributing like a win to a particular source that happens at a certain point in time, that is something you probably still want to record at the person level so that you can report on that accurately. But if you’re in that kind of scenario that doesn’t mean you shouldn’t also or couldn’t also be collecting PMCS at the program level with that additional data where it’s not necessarily for a win attribution but it can be for general reporting on success of individual programs of what kind of pieces of, you know, whether LinkedIn tends to drive the highest conversion for ebook downloads versus Facebook or it still gives you those kinds of insights at the individual program level. So I do hate to give the classic like fallback lazy answer if it depends but it depends. Definitely not a lazy answer and completely understand there’s a lot of different, you know, variables within different businesses that can impact the way that someone would actually utilize it. So definitely not lazy. I try not to be. No, not at all. So thank you, Grace. It is very clear to see why you’re a three times my keto champion. You know, I’m so glad, we’re so glad that you could join us today and share so many of your insights. You know, I think everyone who’s watching has a deeper understanding of PMCS and I can just imagine how excited they are to get working with them.