Centralized multi-touch channel attribution model, based on UTM fields

[ggerla]

Hello there,

so my question is one of a series related to improving our program performances, based on the various program membership touchpoints. I know this topic has been already dealt with, but I like to see another perspective.

Let's assume that we want to have a multi-touchpoint channel attribution, so based on any single program, instead of having just the single Person, MQL, SAL, etc. channel attribution.

What I am doing right now, for every single program, is having a flow that evaluates and records (in several custom program member fields) UTMs of a submission/page view once these actions trigger the membership of a program.

Then, I'm evaluating these UTM parameters for attributing the right channel to the member of the program.

 

Obviously, this way of flowing is not sustainable and manageable on a larger scale, because it means replicating every single step for each single program. What I am looking for, is a centralized (also by partition is fine) way to do the same exact thing.

As I know, I cannot use tokens in the "Change program member data value" flow step (eg.: referring to {{lead.Last Marketo campaign ID}}). Indeed, something like the following smart campaign is not working at all.

Maybe I'm missing some knowledge points trying to understand which is the best practice to roll out an out-of-the-box multi-touch attribution model (Bizible? Marketo Measure?).

Thanks for your support.

[Chris_Willis1 · Accepted solution]

Hi @ggerla thanks for your post.  Within the UI, this is what I would expect to do but hear your concern.  Do you have access to any API workflow tools?  

You can call, via a Self-Service flow action or a webhook, a routine that can pass the utm values and the program IDs to an API routine that can populate these values.  This is a way that you could make this process more sustainable.  

[ggerla]

Hi @Chris_Willis1,

I'm exploring your idea. I was thinking something like the following:

• Having a webhook (maybe Zapier) that has been triggered by a status change potentially / fills out a form
• this webhook is calling an endpoint that is the starting point for a flow which:
  • retrieve the latest updated UTM parameters by /rest/v1/lead/{leadID}.json
  • retrieve the latest program which the user is member by /rest/v1/leads/{leadId}/programMembership.json
  • update the UTM fields data by the /rest/v1/programs/{programID}/members.json

This could be eventually an option but obviously could create some inconsistency, but it's better than nothing.

For sure having something directly in Marketo is def. better.

[SanfordWhiteman]

3 API calls for a single end user activity is gonna be rough. That doesn’t seem necessary and adds risk.

The last set of UTMs can easily be persisted to a lead field.

The last program can be persisted using a trigger campaign and {{trigger.name}}. Make sure you include the Program ID in the name, as is a good naming convention.

Then you send those fields in the webhook and it’s only one API call to update the PMCFs.

[ggerla]

Thanks @SanfordWhiteman,

this makes complete sense, I wasn't aware of the {{trigger.Name}}.

I think anyway a double-check on the program name will be helpful (due to an old heritage that we are bringing back), but this is something to evaluate.

Even if this could be a good workaround, I see the potential of Custo Fields and hope their functionality will be extended further.

[Chris_Willis1]

Thanks Sanford.  @ggerla one thing you should always keep in mind is to manage your workflows so you can bulk your API calls as much as possible to avoid using up calls and (of course) potential conflicts.