Curious how users are looking to utilize or implement Program Member Custom Fields.
What are some suggestions on how to best put this new custom object to work?
Solved! Go to Solution.
I've started implementing point-in-time values, which would be similar to the use-case for querystring capture, but I'm doing it more from a lifecycle stamp period. For instance, what programs did someone attend as a Prospect (or MQL) vs. as a Customer. You can start to get a feel for resonance of content and down the line, even a program-specific lifcecyle map.
In today's environment, you can query whether someone is an MQL or Customer, for instance, but not what they were when they performed a certain action; with PMCF you can tag that info to the program member.
I created a program that used these fields for measuring the level of interest someone had with a content item. High/Medium/Low was assigned based on how long they spent reading the PDF. By using a PMCF, you can set up the exact same process for every content item if you want without having dozens (hundreds?) of fields to store this data.
I'm new to Marketo, just setting up our instance now, the way I'm planning to utilize the Program Member Custom Fields is to store the "conversion's" data and get rid of burner fields, so I created these fields with PM (Product Member) at the beginning of their name to differentiate them:
The main element is missing however, which is syncing those fields with SFDC campaign fields so when we in Marketing send a lead to Sales, we can not only tell them you have an MQL who just downloaded an eBook but we can also mention which eBook and what they searched on Google for when they got the eBook...etc.
However, so far, I believe my current usage above will save me from creating tons of programs so I can create one program per channel or one program per Magnet (content) , I'm still thinking of which way would be best though.
it's always been my experience that anyone who starts only with what they need, they usually end up coming back and re-doing it. I've attempted keeping SFDC at the broader channel acquisition before, and generally always come back to an asset-based level. It's a bit more work, but answers most of the questions you'll end up getting from your teams for ROI.
Other than that, though, your justification here is spot on.
Yea exactly, I've been spending a lot of time planning on the best approach trying to avoid getting back and redoing things.
I set up the asset-level programs and I'll get them synced today and the channel-level can be complementary or probably another way to look at conversions. I wonder if I can get a Smart Campaign in Program A to assign the person to Program B as well, this way say a lead becomes a member of eBook Downloads can also become of LinkedIn Ads Downloads program at the same time if the PM Conversion Medium = Paid Social - LinkedIn or something like that?
The main element is missing however, which is syncing those fields with SFDC campaign fields
Marketo cannot write to custom SFDC Campaign fields directly, but it can write to Lead/Contact fields (obviously). And you can set up your Salesforce to copy lead fields into campaign fields, if that's what you want.
Then create a Smart Campaign that writes values from your Program Fields into synced Salesforce fields. Would look like this:
Change Data Value for synced field - say - "Sales Brief": {{member.PM Conversion Medium}}, {{member.PM Conversion Request}}, {{member.PM Conversion Magnet}}
Change Data Value for synced field - say - "Sales Brief": {{member.PM Conversion Medium}}, {{member.PM Conversion Request}}, {{member.PM Conversion Magnet}}
That's a great idea! I'll check with our Salesforce manager on how to copy lead/contact fields into Campaign's fields but I definitely think it's a good solution. Thank you @Michael_Florin
I think the true value of program member fields will come if/when MKTO allows us to sync these fields to campaigns in SFDC. It would help us solve so many of our problems if we could write information directly to campaign member fields
FYI, In the Summit Roadmap session, it was mentioned that they are targeting to release the sync as Beta in Q3 2022. https://business.adobe.com/summit/2022/sessions/na-2022-roadmap-and-innovations-sneak-peek-for-ado-s...
I think the true value of program member fields will come if/when MKTO allows us to sync these fields to campaigns in SFDC.
Working on an integration project to do just that. Unidirectional (Mkto → SFDC) only though. We'll see how it goes.
Hey @SanfordWhiteman
Same question here, how's it going with this project? It'll be amazing to start utilizing the Program Member Customer Fields directly into Salesforce.
Hey Sandford, how is this project going, with unidirectional sync Mkto -> SFDC for the PMCF?
I've started implementing point-in-time values, which would be similar to the use-case for querystring capture, but I'm doing it more from a lifecycle stamp period. For instance, what programs did someone attend as a Prospect (or MQL) vs. as a Customer. You can start to get a feel for resonance of content and down the line, even a program-specific lifcecyle map.
In today's environment, you can query whether someone is an MQL or Customer, for instance, but not what they were when they performed a certain action; with PMCF you can tag that info to the program member.
Now that's an approach I hadn't heard yet. Great tip!
I haven't played with it yet, but I think it's a great option for webinars and events as a replacement for "burner fields". For example:
- Questions asked on a webinar registration form, such as "What are you interested in learning about today?"
- Questions asked on an event registration form, such as t-shirt size or dietary restrictions
From what I understand so far, these fields can be a replacement for "burner" or "flex" fields you usually have to create in your database to store very specific form information. E.g. a second opt in box which asks for a specific permission. Now you can save that information on program level instead of saving it in a custom database field.
Also, URL parameters might go into these fields.
I just learned that these program member custom fields will also be available for specific tokens which I think is a necessary addition.
I find a little odd that these fields have to be created in "Field Management" aka with admin privilege and there's a cap at 20 fields per instance. I would have thought a more logical place would be to create them on program level, and the cap would be per program and not per Marketo instance.
But let's see...