Program Member Custom Fields - Suggestions | Community
Skip to main content
M
mzzee
New Participant
June 16, 2020
Solved

Program Member Custom Fields - Suggestions

  • June 16, 2020
  • 6 replies
  • 10518 views

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?

    Best answer by JDNelson1

    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.

    6 replies

    EllenSchwier
    EllenSchwier
    New Participant
    March 17, 2022

    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.

    MaenHadid
    MaenHadid
    New Participant
    August 30, 2021

    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:

    1. PM Conversion Medium: where did the lead come from when they filled that form?
    2. PM Conversion Request: what's the main request here? Quote? Demo? Content Download? Webinar Registration?
    3. PM Conversion Magnet: what attracted the lead? a specific product? name of content like XYZ eBook? name of Webinar?
    4. All 5 standard UTM parameters for future reporting, to know where did the conversions in a program come from? Which channel? creative? Keyword? Content?...etc.
      1. PM UTM_Medium
      2. PM UTM_Source
      3. PM UTM_Campaign
      4. PM UTM_Content
      5. PM UTM_Source

    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.

    1. A program per channel can show me all the conversions that came from LinkedIn Ads for example, I would know who converted and what content they downloaded and from which ad they came, however, this way would mean I'll have only the latest conversion on LinkedIn Ads for a specific lead (meaning, if a lead converted twice from LinkedIn Ads the second conversion data would overwrite the first one).

     

    1. A program per Magnet however, would allow me to know where did my conversions come from, across all channels, paid and otherwise which is helpful to decide on our media budget spend and optimization. The drawback here however, is I need to create multiple programs for Magnets-Requests combinations, for example:
      1. Program for Quote Requests for Product A
      2. Program for Quote Requests for Product B
      3. Program for eBook A downloads
      4. Program for eBook B downloads
        This way I won't lose previous conversions (a bucket for all eBooks would make me lose conversions from previous eBooks if a lead downloaded more than one).

     

    Michael_Florin-2
    Michael_Florin-2
    New Participant
    August 30, 2021
    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}}

      MaenHadid
      MaenHadid
      New Participant
      August 30, 2021
      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-2 

      M
      mzzeeAuthor
      New Participant
      March 30, 2021

      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 

        SanfordWhiteman
        SanfordWhiteman
        New Participant
        March 31, 2021
        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.

          Marlaine_Hudgin
          Marlaine_Hudgin
          New Participant
          June 14, 2021

          Hey Sandford, how is this project going, with unidirectional sync Mkto -> SFDC for the PMCF? 

          J
          JDNelson1Accepted solution
          Community Manager
          June 17, 2020

          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.

            Katja_Keesom
            Katja_Keesom
            Community Manager
            March 31, 2021

            Now that's an approach I hadn't heard yet. Great tip!

              Amy_Goldfine
              Amy_Goldfine
              New Participant
              June 17, 2020

              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

               

              Amy GoldfineMarketo Champion & Adobe Community Advisor
                Michael_Florin-2
                Michael_Florin-2
                New Participant
                June 17, 2020

                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...

                  Terms & ConditionsAccessibility statement

                  Loading footer...