yes, this actually is a blog post.
So one thing that has been plaguing me lately is the way I did some of my Omniture implementation a few years back. Hindsight is always 20/20, but I made quite a few mistakes. I did it waaaaay too quickly and because of our infrastructure at the time of implementation, we had to do some very obtuse things to make it all work. So I am going through some exercises to remedy some of my decisions.
One such bad decision was the way I artificially siloed our sites into report suites. For the most part all the country data goes to a country-specific report suite. In theory, that is a decent way to do it. The problem is there are applications that are actually shared across multiple countries, so where does that data go? That was the case with our eSupport site where I created a separate report suite just for that since all countries pointed to the same one and I didn’t really have a way to distinguish country at all. Wasn’t in the url, meta, etc. It always bothered me because it created holes in my pathing reports and weird entry points within our metrics as people left the “public” report suite and entered the “esupport” report suite based on the s_account values I had created.
So fast forward to today where I was browsing the Omniture Knowledgebase and found a plug-in I hadn’t really considered before called getPreviousValue. I think I never saw it before because it was formerly called getPreviousPage, which I couldn’t think of a great purpose for. But with getPreviousValue I found something interesting in that I could actually capture a value for a variable from a previous page and pass to the next page’s Omniture code. All of a sudden I had a way to pass the country identifier along in subsequent pages. So for instance someone is on the Lenovo UK homepage and clicks ‘Support and Downloads’ I can now carry over the ‘UK’ in a variables such as an s.prop and bring it into the code of the ‘Support and Downloads’ page which is shared by all countries. I can now artificially say it belongs to the UK and send it the corresponding country-specific report suite by manipulating the logic for assigning the s_account value.
I plan on throwing this out there soon to see if it solves my problem. And thought I’d share the idea to others that have run into implementation problems where some their site is shared with other entities or countries within their report suite architecture. Hopefully this helps someone or spurs on other thoughts.