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

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

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. 


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. 


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.  


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. 


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


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.