When I was at the Omniture training class a few weeks back, the instructor mentioned that an advantage of storing the internal search terms in a s.prop was that you could get pathing enabled on the s.prop and you would then be able to see not only what your visitors were searching on, but how they refined their search.
Note: After you choose which s.prop you are going to use to store/capture the data in, you will need to contact Omniture Client Care to get pathing enabled for that s.prop

In a previous post, I went over how we capture the search terms from the Google Mini. So when I returned from the training, I contacted client care and had then enable pathing on the s.prop and “Shazam!”. We now have pathing on the internal search terms.
This has been working great, and I’ve been really pleased with being able to see exactly how visitors refine their searches. Recently, I had the opportunity to chat with Susan Fariss, at the American Chemical Society (@soozantf) about search analytics and the questions came up on do we know where the user was on the site when they initiated the search and then what search result did they click on.. if any? Well… I did not have those answers, but I sure wanted to.
So the question was could the following be accomplished:
- Detect/capture where visitor was on the web site when the search was initiated
- Modify the google mini xslt to tag all of the search results so that the result clicked could be captured
- Would this provide the full search pathing expected
Detect/capture where visitor was on the web site when the search was initiated:
This was the easy part of the adventure for sure. I already had a JavaScript function handling the initial search, so I added another function call in that
function recordInternalSearchOmniture(){ var s = s_gi(s_account); s.linkTrackVars="prop1"; s.prop1 = s.pageName; s.tl(document.location.href,'o','InternalSearch'); s.linkTrackVars=""; }
This code snippet simply pulls the s.pageName and puts it into the same s.prop used to store the actual search terms, creating the “entry point” of our search path.
Modify the google mini xslt to tag all of the search results so that the result clicked could be captured:
This proved to be the pesky part of the adventure. The challenge was to be able to add the jQuery function to tag the search results someplace where the Google xslt could access it. After a few missteps I added the jQuery to a main .js file (not the s_code.js) that I was able to link to inside the xslt. But first I needed to add a div with a specific Id to the xslt so that I would be able to tag the results with the tracking codes. So inside the xslt I did the following.
<!-- ********************************************************************** Search results (do not customize) ********************************************************************** --> . . . <div id="googleSearch"> <!-- *** Customer's own result page header *** --> . . <!-- *** HTML footer *** --> </div>
So find the section that says “Search results (do not customize)” 😉 – I viewed this as more of a suggestion than a hard rule. Inside this section, wrap the header/footer items with a new div with the id of “googleSearch” (or some other id of your choosing). This is needed so that the jQuery function can find the elements that need the new tags. Once that div is in place add a jQuery function to find all results in that div and tag them. The first function below binds a function call to the a href tags in the search results. The second function does pulls in the location of the search results and records where the user clicked. This provides the “exit point” to our path.
$(document).ready(function(){ $('#googleSearch a').each(function(i) { var hrefval = $(this).attr('href'); $(this).bind('click',function (event){ omniGoogleSearchResultClicked('Search Result Clicked',hrefval) }); }); . . function omniGoogleSearchResultClicked(propTitle,hrefVal){ var s = s_gi(s_account); s.linkTrackVars="prop1"; s.prop1 = hrefVal; s.tl(document.location.href,'o',propTitle); s.linkTrackVars=""; }
Would this provide the full search pathing expected:
Yes! This does indeed provide a full search path.

Ok.. so maybe I changed the actual values, but this is the type of search pathing you can achieve with tracking the entry and exit points in the same s.prop as the search terms and having pathing enabled on that s.prop.
-Rudi
4 thoughts on “Pathing: Internal Search Analysis. (not just for page views)”
Nice post, Rudi.
Thanks Jon! I hope it was helpful.
Hi Rudy,
Nice coding.
I do something similar, but call the prop “detailed clickpath”. For most pages, I pass in the page name. However for some pages (like search), I would pass in more granular descriptions (like search terms). I also label campaign visits at the start of the visit and pass in key ‘clicks’ on the site. All this is then pathed and leads to a powerful datastream.
Jim,
That sounds cool. I like the idea of picking out some custom pages to make a click path.
-Rudi