Pushing Google Analytics Campaign Tracking into SiteCatalyst

13 Nov Pushing Google Analytics Campaign Tracking into SiteCatalyst

Share on FacebookShare on LinkedInTweet about this on TwitterEmail this to someone


This morning on the Yahoo Web Analytics forum a question was posted about best practices for campaign tracking when companies are using both Google Analytics and Omniture. This particular company was apparently switching from GA to Adobe Analytics, but I should note that many companies don’t only experience this challenge during a transition; many companies place both Omniture and Google Analytics code on their sites and keep them there for the long term.

I spent a good portion of the day devising a plan: how I would do it if I were in that situation. I should say that I’m a big fan of campaign tracking (obviously, seeing as I’ve built a company around tracking code preparation), and I love to push the limits of technology and squeeze as much juice out of its engine as possible. But, in the case of campaigns, I generally lean towards simplicity and automation, because anything you choose to do today, you have to keep doing tomorrow and the day after (if you want your campaign reports to mean anything).

My recommendation, at least during the transition phase, would be to mimic precisely the Google Analytics campaign reports within SiteCatalyst using Classifications, and the best news is that you can set it up to be entirely automatic! Just follow these three steps:

Step 1: Make Adobe Tags Capture GA Campaign Parameters

NOTE FROM THE FUTURE: Craig here: Later I realized that there’s a way to do this step without adding the plugin this article goes on to describe. In fact, it requires no re-implementation on your site at all. You can do it through Processing Rules in the Adobe Admin interface. I’ll outline those instructions in a separate blog post shortly. CS 11/12/14

I Googled something about Omniture plugins for GA campaigns, and quickly found one called “useGACampaign”. I tried it with the H-code I’m still running, and it works great–although I did have to make a few slight adjustments to the code to make it work with my overall strategy (see the Technical Notes at the end to see how and why).

The purpose is to take all of the different campaign-related parameters in Google Analytics (utm_source, utm_medium, etc.) and combine them into a single tracking code. Here is the code I used:

Let me quickly break down the parts of this function:

  • Order (required): determines the order of the campaign descriptors you’re pushing into your tracking code. You don’t have to include all five of these elements, but I wanted to as part of my strategy.
  • Delimiter (required): The character(s) which separate each element within your tracking code. The important thing here is to choose a delimiter that will never appear within any of your parameter values.
  • isLenient (optional): A strict teacher never gives partial credit (I always hated those teachers!). Setting this leniency value to false would not capture anything in the Omniture campaign variable unless all three standard components are found with values in the URL: source, medium and campaign. I set this to True so if any one of the five parameters is found, my code will still collect it in Omniture.
  • Prefix/Suffix (optional):I wanted each of my Google Analytics codes to start with “ga”. Partly I’m doing this so I can, in the future, add new codes that are Omniture specific. But this prefix will also help me in the Rule Builder, which I’ll show you later. Note that if I wanted a suffix instead of a prefix, I would start the string with a comma, like this: “,ga”
  • Force to Case (optional): I didn’t use this argument in my example, but a 1 will force the entire string to upper-case, and a -1 will force it to lower-case.

Step 2: Set up Classifications for Source, Medium, etc.

An Administrator of Adobe Reporting & Analytics will need to add the five GA reports as classifications within the campaigns variable. This is done in the Report Suite Manager, where the administrator will select the report suite, then under Edit Settings choose Conversion >> Conversion Classifications.

The campaigns variable should already be selected, and so you must choose whether or not to simply add the GA reports as new classifications, or clear out your existing classifications first. Note that deleting classifications won’t destroy any of the tracking codes that have landed on your site, but it will remove any information you had in the classification fields for those records.

Since this is a new implementation, I removed the out-of-the box Classifications that come installed for the campaign variable, and replaced them with the GA reports. Note that I can add other custom classifications to this list later without causing problems in what I’ve built here today.

Step 3: Auto-Classify using Rule Builder

This is my favorite part. Since I took pains to assemble the five components of my GA campaigns in a specific order that is consistently delimited, I can create a very simple rule set to parse these values into their corresponding classifications.

I’m terrible at Regular Expressions, but fortunately the Adobe Help files got me 90% of the way there. I settled on this Regex:


which breaks my code into six pipe-separated components, as shown here:

Now the only thing left to do is to duplicate this rule until I have all five components pointing to the correct classification report.

Once this is done (and tested!), I clicked on the Activate button, and it’s a done deal. Going forward all Google Analytics campaign tags are going to be automatically captured into Adobe Analytics and the Tracking Code reports will all be propagated automatically.

The Transition and Beyond

As I alluded to earlier, one of the advantages of switching to Adobe Analytics is that the campaign tracking is vastly more configurable than Google Analytics. You may find yourself wanting to report at more than just the five pre-defined levels provided for in your previous world. You can add classifications, and even your own types of codes and capture them directly into Omniture, even if they’re no longer piggy-backing their way through the GA implementation. And you can do this in conjunction with the GA plugin I’ve described in this post.

Notice the logic here in my doPlugins function: if the GA source parameter is in the URL, then the useGATracking plugin is used, otherwise it looks for the “cid” parameter in the URL to capture whatever other tracking codes you want to collect.

Of course it will be up to you to decide on the best system for generating your non-GA tracking codes, how they’ll be assembled, and how you’ll generate and classify them. If you don’t have a good system–take a look at the rest of this site, because that’s exactly what Tracking First provides!

Technical Notes

The useGATracking plugin required that I also have the getQueryParam plugin, and the split utility function. These are pretty common Omniture plugins, so I already had them both.

Also, I had to make some slight changes to the useGATracking plugin itself, because it was a little too fancy for my needs. It included some logic to skip GA elements if they weren’t in the URL. But for me to make my Rules entirely predictable, I needed the 6 sections of the Omniture tracking code to be included every time, even if the sections were missing or empty.

Below see the highlighted portions of the plugin that I had to remove to make this happen.

Craig Scribner
No Comments

Sorry, the comment form is closed at this time.