Marketo Analytics Tips: How to restate historical data when FT and MT program reports are telling lies

Jessica_Kao3
Level 10 - Champion Alumni
Level 10 - Champion Alumni

Are your Marketo First Touch and Multi Touch reports lying to you? The answer depends on what you did --- or didn’t do weeks or months ago when you setup and ran your marketing programs.  Getting Marketo First Touch and Multi-Touch attribution right depends on getting the right values in these Marketo native fields:  

  • Acquisition Program
  • Acquisition Date
  • Success (status within the program)
  • Success Date

I see many Marketo users discover that sins of the past – setting up and running programs incorrectly – come back to bite them when it’s reporting time. The truth is, even the most diligent Marketo user will now and then miss setting up one or more of these fields correctly to get the right value. So, it’s important that you know how to restate the data when you need to get your reports dialed. 

First Touch attribution helps you address the question what programs brought new names into the database that directly impacted pipeline and revenue.  Multi-touch attribution addresses what programs influenced and played a role in generating pipeline and revenue.

Let's look at how these fields impact attribution and how to restate the data. 

FT Attribution - Acquisition Program and Acquisition Date

FT credit is given based on the acquisition program.  As a marketer I want to get all the credit I rightfully deserve.  In order to get FT attribution all records should have an acquisition program. (Note:  For the people that are created from sales, set their acquisition program to a specific sales generated program and make that program operational.)  This will make it easier to identify any gaps. 

Setting the acquisition program isn't enough.  The date of acquisition matters and will affect whether you get FT pipeline credit. Therefore, in some cases you will also need to restate the acquisition date. 

Use Case #1

The person was given an acquisition program upon entry into the database.  However, it was not the correct acquisition program. 

Fix: 

Change the acquisition program.  The acquisition date does not have to be changed because the date is not linked to the specific program.  

Use Case #2

The person never had an acquisition program and entered your database sometime in the past. 

Fix:

Change the acquisition program date and set the acquisition program.  If you set the person’s acquisition program today, the acquisition date will also be set for today.  For an accurate picture of program influence on FT pipeline for historic data, then you will also have to restate acquisition date as best you can.  With a little bit of detective work and depending on your record keeping in the past, you will be able to.  If you are in a smart list and using a single flow action, change the acquisition date first, then change the acquisition program.  The reason for this is presumably in your smart list, one of your criteria is acquisition program is empty.  Once you assign people to an acquisition program, they are no longer empty.  I know this sounds obvious, but there have been  many times where I have said “oh S@!t.” Now I have to go and find them to change the date.  

MT Attribution - Success and Success Date 

After you have assigned people the correct acquisition program, you should go back and check to make sure that they are in the correct progression status.  Depending on whether the progression status is a success step will impact whether this program   will get MT credit for pipeline and revenue.  The same thing goes for the success date as well.  Depending on when that person reached success in relation to the opportunity created date, will impact whether that program gets credit for MT pipeline.

If placing the person in the acquisition program automatically puts them at a success step, then the success date is also set for the day that success step was reached (probably today). If you are backfilling historical data, you will need to also change the success date.  Unlike the acquisition date, changing the success date can only happen in a smart campaign since it has to be associated with a specific program.  You can not change the success date using a single flow action in a smart list.  Here is a quick chart showing what fields can be changed via which method.

Screen Shot 2016-09-08 at 8.12.11 AM.png

Use Case #1

Change someone’s progression status to a success status and you need to change their success date and they are not in the program already.   You will encounter this scenario if you are backfilling programs (i.e. tradeshow or events, etc) that happened in the past.  

Fix: 

You will need to set up two smart campaigns.  The first smart campaign is a batch campaign where it sets the acquisition program, acquisition date, and program status.  If this is a success step, then you will need a second smart campaign that is requested to set the success date.  Because setting the success date can only happen after a person is a member of the program,  use a request campaign flow step.   You cannot do this in a single smart campaign with multiple flow steps.  I tried this even with adding wait steps and it didn’t  work. 

Use Case #2

You know a group of people were acquired or obtained a success by filling out a specific form, but someone forgot to put them in a program for the past year, so what acquisition date and/or success date should I use for this group of people? How do accomplish this in the most efficient way possible. 

Fix:

First you need to decide how granular you want the data to be and that will change depending on how far back this specific activity happened.  Meaning, do I care that Joe Smith filled out a form in 2012 or April 2012 or April 7 2012?  Most likely, if an opportunity was created from Joe and it happened in 2013, MT credit will be assigned as long as the success date was sometime after 2012.  Plus if it’s not 100% accurate, I’m ok with that being so far in the past.  So for any filled out form activity that happened in 2012, I am ok with assigning the success date to be Dec 31, 2012.  At least I can compare year to year.  

As you get to more recent activity, you might want to be able to get to a more granular view.  So for activity in the past 12-18 months I might want to state successes in the month that it happened in.  So for any activity deemed a success for a particular program, I will set the success date for the last day of the month.  For example, I want to restate people who filled out a form to download content X.  For people that performed this activity between 1/1/2016 and 1/31/2016, I will set the success date to be 1/31/2016.  In a single flow step, choose the change success flow action and use add choice, you can either go by created date if you know for certain that the date will correlate with the success activity.  Or create a smart list for each of the specific actions happening in the time frame i.e. Filled out form Jan, Filled out Form Feb etc and use a flow step add choice where if member of smart list is in Filled out form Jan, set success date to 1/31/2016.

Screen Shot 2016-08-26 at 5.09.02 PM.png

Screen Shot 2016-08-26 at 5.08.51 PM.png

Summary:

When restating data, make sure you have accounted for what goes into each of these four fields:

Acquisition Program

Acquisition Date

Success (status within the program)

Success Date

. . . and your FT and MT attribution reports will make you look like a hero. 

Since you have spent the time restating this data, you probably never want to go through that again, so how do you set up programs to ensure that this data is being captured the right way in the first place.  Well, stay tuned for part II.  In the mean time, if you have any questions, just shoot me line.   

5101
8
8 Comments
Anonymous
Not applicable

Wow, Jessica, An absolutely fantastic article that I think will help a lot of folks. Going through a lot of this myself, I know how much work it is. Thanks for documenting.

What have you found useful for legacy data that existed before Marketo existed? Do you assign to some legacy program (like your Sales Program)? Leave blank? Or assign to the first Marketo program someone engages with? 

Jessica_Kao3
Level 10 - Champion Alumni

Thanks Jeff.  I've done a few migrations from Hubspot to Marketo and when I have some pieces of information i.e. they were from a tradeshow and was created in 2014, I will create legacy programs in the appropriate channel. 

2014 Tradeshow Unknown

2015 Tradeshow Unknown

2015 Paid Search Google

Colin_Mann
Level 5

Really insightful thanks. We've been looking at this very issue because in our case we had (for historic reasons) only really tracked first touch but we discovered that opportunities we had influenced weren't being captured in our CRM reports and we've had to do a lot of work to address that.

Keith_Nyberg2
Level 9 - Champion Alumni

Great post Jessica! Quick question... if you change members of a program that have not reached a program status that is defined as success yet, to Success=True, does that automatically progress their program status to a status that equals success?

Example would be a lead that was invited to an event and has a program status of Invited (which is not success in the channel). If you change their success in the program to True, will it update their program status to Attended (which is success for that channel)? Or leave them with a status Invited but show they reached success in the program?

Just curious if anyone has tested that....

Jessica_Kao3
Level 10 - Champion Alumni

Hi Keith, 

I was playing around with a couple of scenarios around changing program status vs using the flow step to change success status from true to false and false to true.  Here's what I have tested thus far.

Use Case: 

Members in a program have reached a success step.  However, I changed my mind and I just want them to be members but not successes.  IE move them "backwards" to a member not success status.

We know we can't move people backwards. So I tried running a flow step success = false.  That failed makes sense because how does marketo know which status I want to put them into.  But then, what is a use case where you would use the flow step to toggle success TRUE/FALSE  because they have essentially decoupled member program status from success.   I can't think of any.  When could you actually use that flow step.  Is it when program status only has two statuses to choose from (a binary decision) one being true and one being false?  I'm still testing this out. 

FIX: 

Add members to a static list.  Remove members from the program, and put them back in at the program status that is not a success.  (I still have to check if doing this will wipe out the success and success date but I'm pretty sure it does)

Keith_Nyberg2
Level 9 - Champion Alumni

Hey Jessica,

Thanks for sharing your additional testing. Couldn't think of a use case either but sometimes use cases present themselves after feasibility. Your recommended fix is really helpful for people trying to revert a group's program status "backwards".

Thanks!

Keith Nyberg

Danni_Holleran
Level 3

Yes, thanks Jessica, i'm bookmarking this to reference again later. Great piece!

Lynn_Ray_Pardo
Level 5

What a God Send, Jessica! I'm in this exact situation. We're a media company where the previous interest was only on the "success" of the assets, vis-a-vie open and click reports, not the people. So we've got a whole year's worth of 3 weekly newsletters and 2 monthly newsletters that have not been tracking the success of the members.

I'm in this exact situation. We're a media company where the previous interest was only on the performance "success" of the assets, not the people. So we've got a whole year's worth of 3 weekly newsletters and 2 monthly newsletters that have not been tracking the success  of the members.

Now, I've got to backfill all of that data and this sounds like a great road map!