Screen Shot 2017-04-21 at 11.04.38 AM.png

UTM Code Tracking and Reporting for Third Parties

Level 8

Hi All - I wanted to share something I've developed in conjunction with one of our paid inbound vendors.

The Problem: GE Healthcare works with an ad agency who places our digital ads. We use Google Analytics tracking which we found had a tendency to differ from Marketo reports and last year we spent a great about of time trying to tie out reports.

Requirements: We needed to produce end-to-end reporting to show how many people visited the site, filled out a form and then went through our sales funnel all the way to the Opportunity stage. Leadership wanted to see how much was created in Opportunities and wanted all reporting in one package. We also needed a way to track multiple UTM code responses and store as history in a way we could see what happened historically and this all needed to be done in Marketo. We also wanted the ability to pass this ID to the cloud in Google Tag Manager so it could be added to Google Analytics reports

Constraint: Because the vendor is a third party, and international at that, sharing personal information needs to be restricted. We wanted a way that would allow us to send them information WITHOUT sending over any personal tracked info, like name, email, etc but to be able to tie it out internally if needed.

Solution:

What we came up with is a pretty simple, easy to deploy method that creates a unique identifier for a person that's not tied to any other system. Our first thought was to use Lead ID, but that's not generated quickly enough to tie to a form fill event that could be passed to GA to show a conversion. Also, we questioned whether we should be sending over any system IDs that could somehow be used maliciously.  Also, since there's no way to create n:1 tables in Marketo for historical tracking, like UTM history, we decided to create a process.

For UTMs:

We created a field in Marketo that aligns to each of the UTM parameters: utm_campaign, utm_content, utm_source, utm_term, utm_medium. I also created a field called utm_history.

Then I created a smart campaign that listens to any form fill where utm_campaign is not empty. In the Flow, utm_history has the following Change Data Value:

DateTime: {{system.datetime}} | Tracking ID: {{lead.flex field 1}} |  Campaign = {{lead.utm_campaign}}  |  Source = {{lead.utm_source}}  |  Medium = {{lead.utm_medium}} | Term = {{lead.utm_term}}  |  Content = {{lead.utm_content}}---- {{lead.utm_history}}

For the Tracking ID:

This was something we tried a few different times before agreeing on something we both liked.

On our webpage where we want this tracking method used, I put the following code in the header:

  <script>

  var leadId = Math.random().toString(36).substr(2, 5);

  document.cookie="_trkRndId="+leadId;

    dataLayer = [{

   'trackedId': leadId,

   'pageName': '<page name>'

}];

  </script>  

Here's what's hapening:

  var leadId = Math.random().toString(36).substr(2, 5); <!-- This creates a random 5 digit alpha-numeric string

  document.cookie="_trkRndId="+leadId; <!-- This writes a cookie called _trkRndId (track random ID) and stores the 5 digit alphanumeric created above

//This writes the data to the Data Layer is Google Tag Manager.  Please read up on it for an explanation.

    dataLayer = [{

   'trackedId': leadId,

   'pageName': '<page name>'

}];

Now, on the form on the page, I have the UTM fields hidden (prefilled disabled) with the values pulled from their appropriate URL parameters, and I use something called Flex Field 1 as a hidden field field with its value pulled from the cookie, _trkRndId:

Screen Shot 2017-04-21 at 11.04.38 AM.png

I use fields called Flex Fields as temporary, all purpose fields. When I want to set something on a temporary basis that's stored in a notes field, I use one of my 5 flex fields.

Finalizing

Now, my UTM history field has a continuous, chronological summary of interactions with UTM encoded links along with a unique identifier to the person for each form fill. I could decide to make the cookie more persistent, but since there's no guarantee that the end user will be on the same device each time they interact, there's no guaranteed value to having the random user ID always be the same.

I can now build out a smart list with utm_history + opportunity value and status fields and send that to my international third party without worrying about personal identifying tracking information being shared. I also know that the value in that field would be pretty difficult to use maliciously since it's never exposed in the code on the page and it doesn't link back to an ID field in any system.

Now, because Sanford might read this....

Yes, there is a small probability that the 5 character code could be repeated. Given the amount of interactions I'm expecting, I'll take this risk.  Yes, the way I store the utm_history field could be better formatted, but we currently have no other uses for it. Yes, some super-sophisticated Russian spy hacker 14 year old probably can expose a bug in this system. Can't win 'em all.

In the end, this gives me and my agency something we're comfortable sharing and reporting. Our agency can use the UTM data to identify exactly which ad is helping us generate the most revenue and then make adjustments to the spend on the fly.

6269
14
14 Comments

Hi Robb,

You should use a linebreak token to separate each entry in the history for the rest, I like it.

-Greg

Level 8

I actually do use them, just didn't want to delve into that topic.

Level 7 - Champion Alumni

Great Post Robb Barrett PRD​ .

How are you (if you don't mind diving into specifics a little bit) reporting on the UTM History field?

I'd love to learn how to leverage that.

Level 8

It's not very useful for true analytics work.  I know there are ways to format the data but we didn't have the need for properly formatted data since we don't intend to use real analytics on this.

Level 7 - Champion Alumni

oh ok, gotcha

Level 10 - Community Moderator

Yes, there is a small probability that the 5 character code could be repeated

I actually wasn't going to say anything about entropy!

But I was going to wonder why you don't save the cookie at the parent registered domain, since there might be a need to share it across multiple subdomains. And IMO making it a session cookie (even though you're right about multi-device environments) is depriving you of data that, when available, is valuable. I mean, I'm sure you haven't changed the Munchkin cookie to a session cookie, right?

Anonymous
Not applicable

What are the benefits of passing the id to GA? I've always wanted to try this but have been skeptical that our data will be meaningful as we don't use the paid version of GA.

Level 8

I just didn't want to fall into the trap of thinking a single ID was always the same person when a person might use multiple devices, clear their cookies, etc. And think of all the time I saved by not typing in an expiration date. Makes for much tighter code.

Level 8

In case you want to use it as a dimension in GA.  We haven't, but it was our first theory on how to solve the problem so I just left it in there in case we want to use it.

Hi Robb,

2 possibilities:

  • Add your random ID to lead activity log using the munchkin API. The idea behind int is that is the lead does not convert during the session, the ID will still be linked to it if he/she converts later. And if the lead converts on multiple devices with different ID's, you will still be able to reconcile it all, at least in an external BI tool, since all the random IDs that are trackable to the lead will be in the lead activity log
  • Send back the Marketo lead ID to GA on form fill out. That would have the same impact than the random lead ID and make it easier to reconcile.

-Greg