New Keystone Blog Post- Omniture Campaign Best Practices
Head on over to the Keystone Community Blog for my latest post, with Tips and Tricks for Campaign Tracking in Omniture:
The standard Omniture Campaign reporting offering, based solely on a query string/tracking code pair, is pretty solid: campaign reports and all the possible classifications, paid/natural search detection and reporting, and marketing channel reporting, managed from right there in the SiteCatalyst admin console. But over time we’ve found some tips and tricks that can maximize the value of your campaign tracking efforts.
- Custom Campaign Click-throughs
- Granular, Classified Tracking Codes with a Marketing Channel prefix
- Campaign Landing Page Pathing
- Campaign Cross-Visit Participation
Head over and take a look!
Pathing Quickwins
This is post 3 in my series on quickwins.
Pathing Reports have been covered over and over. Adam Greco summed them up beautifully back in 2008. He has since contributed quite a few more gems about pathing, so I'll try not to reinvent the wheel here.
So what WILL I cover?
First: pathing reports. I know you have them. They're out of the box. Use them. Play with them. Pat their heads and tell them you love them. Take 30 minutes to just play around with each of them. Think about other variables you might want to see pathing for that would require nothing more than enabling pathing on an existing variable; common ones include Internal Search Terms, Site Sections, and Page Type.
Then take it a step further and do some minimal implementation to give you more pathing reports to love.
Note: To have pathing enabled for any prop, you must contact ClientCare.
Easy Pathing Reports you could get with one line of code
Campaign Landing Pages
With one pathing-enabled prop (propX in this example) and one snippet of code in the s_code.js, you can see where your campaign landing pages are leading people. The code looks like this (placed in the s_doPlugins section of your s_code, somewhere after your s.campaign variable):
This code says: if a campaign tracking code has been set, pre-append it to the pageName. Otherwise, just capture pageName. This can give you a report that looks like this, where the page on the far left is a campaign landing:
I can see of the 24 users who came in off a certain campaign yesterday, 5 exited my site, 2 immediately converted (in yellow), 2 moved on to another offer (hmmm, maybe I can use that in my next campaign), and 2 went on to find out more about my brand. If I were just looking at a campaigns report, I would see 4 Form Submits, and would assume the other 20 users were "unsuccessful", at least in the short term. But now I know that campaign met some other success, just not the success I had predicted.
You can also use this to build a great Fallout report if your campaigns lead to a multi-step process.
Internal Search Page Paths
By simply enabling pathing on your Internal Search prop, you can see the the series of keywords a user might go through in one visit (what, not tracking Internal Search? For shame! See how easy it is?). But let's face it, without context it's hard to know what to do with that data. Users could be searching, adding to cart, then searching some more and adding more to cart- which is fantastic! Or, they could be searching, and searching, and searching, then jumping off a cliff. Not so good. Which search terms are frequently revised without leading to success? In other words, what are users searching for but aren't finding?
With one line of code and one more pathing prop, you can take that a step further and see how often users search, think they found what they want, go to a piece of content, then end up searching again; this gives you actionable data about possible interface problems, ways to improve your search engine, or promote content.
Here comes the code. Let's say your internal search prop is propY and your new "Internal Search Page Pathing" prop (with pathing enabled) is propZ:
This could create a path like this for a user trying to find the right Wug for their home
:
Search: Wugs
>product detail page
>Search: blue wugs
>product detail page
>Search: blue radioactive wugs
>product detail page
>cart addition
If this were just one user, this would be "so what?" information. But if a significant number of your users had searches like this, you could now know that your radioactive wugs might make a nice internal promotion- if users are looking for them, let them find them!
Internal Search Conversion Paths
A slightly different approach to the same idea- let's see how searches lead to conversions (this would also be a great case for using a cross-visit participation eVar).
This could show you a user path like this:
Search: red wugs > Search: red wug > Search: blue wug > Conversion:Purchase
Or, on the other hand, it could show a series of searches that did NOT lead to a conversion.
Search: red wugs > Search: red wug > Search: blue wug > Search: radioactive wugs > exited site
Note: None of the above custom pathing variables will make a ton of sense as a traditional traffic report, at least, not without some filters. But you can easily do a search on "Search:" to filter out the non-search pages.
Also, be aware of how many unique values you might be getting into any of these variables. If you have over 50,000 unique search terms combined with pagenames in a given month, it would have serious implications for any pathing reports.
If nothing else, I hope this post has gotten you thinking about new ways to use pathing reports. I don't think you have to look far to find value in them.


