Categories
- Channel Analytics
- Inside Discover
- Marketing Integration
- Migration
- Omniture Business
- Online Marketing
- Online Merchandising
- Search Engine Marketing
- SEO
- Site Search
- Social Media
- Testing and Targeting
- Web 2.0
- Web Analytics
Authors
- Aseem Chandra (1)
- Adam Greco (46)
- Alex Hill
- Adam Justis (1)
- Brent Dykes (20)
- Ben Gaines (42)
- Brig Graff (4)
- Bret Gundersen (1)
- Brian Hawkins (4)
- Brent Hieggelke (6)
- Bill Mungovan (16)
- Ben Robison (7)
- Brent Watson (3)
- Cameron Cowan (2)
- Chad Greenleaf (2)
- Chris Knoch (4)
- Christopher Parkin (15)
- Christian Ridge (2)
- Customer Success (2)
- Chris Zaharias (6)
- David Kirschner (5)
- Ed Hewett (18)
- Jeremy Anderson (1)
- John Broady (10)
- Josh James (1)
- Jordan LeBaron (5)
- Jim McTiernan (2)
- Jeff Minich (9)
- Jose Santa Ana (2)
- Kiran Kairab Ferrandino (8)
- Kevin Lindsay (5)
- Kevin Willeitner (3)
- Laura MacTaggart (5)
- Matt Belkin (35)
- Mikel Chertudi (12)
- Michael Halbrook (5)
- Michael Klein (4)
- Matt Langie (5)
- Pearce Aurigemma (17)
- Siddharth Chaudhary (1)
- Steve Gustavson (3)
- Tim Lott
- Tim Waddell (1)
- Wes Funk (4)
Pages
Recent posts
- Meet the new DigitalPulse Debugger
- Oh Bring us Some Figi Pudding
- Online florist improves conversion rate 180% and gains 340% return on ad spend over three years using Adobe Solutions
- Reporting vs. Analysis: What’s the Difference?
- Mobile Solutions Series: Mobile Vs Non-Mobile [Advanced Solutions]
- Code version H.22.1 released
- Time Based Analysis, part 2
- Time Based Analysis, part 1
- When Apps Go Underground: Announcing Offline Support for Mobile
- Five Times to Test: 4 - When you spot an opportunity in your analytics
Recent comments
- susan: Hi, Adam. I have two…
- Victor Forman: Thanks for sh…
- Rudi: Nice work. A huge imp…
- Henrik Schack: Looks really …
- Yuhui: I don't know if it wa…
- Steve Fernandez: @Eric - I w…
- Ben Gaines: Hi Craig, I don…
- Randy Zwitch: Yes it does Be…
- Craig: Ben, is the only thin…
- Roop Kumar: Hi Adam, We w…
Links
- DigitalAlex
- eMetrics (Jim Sterne)
- Forrester Research (John Lovett)
- Future Now’s grokdotcom
- immeria
- June Dershewitz on Web Analytics
- Lies, Damned Lies
- LunaMetrics
- Mine That Data
- Occam’s Razor
- Rich Page Ramblings
- SemAngel
- The Analytics Guru
- The Omni Man
- Web Analysis, Behavioral Targeting and Advertising
- Web Analytics World
Archives
Ben Gaines mailbag #4
It’s been a while, but it is finally time for another mailbag. I wish I could blame my lack of activity as a blogger on the book that I’m writing, as my hero, Bill Simmons, did for months in 2008. The actual reasons (helping to build the next versions of SiteCatalyst and DigitalPulse) may not be quite as sexy, but they are probably more important. Whenever possible, though, I have been busy gathering questions and researching answers for you. As always, each of these questions comes from an actual Online Marketing Suite client.
Q: What’s the deal with Google Instant Search? Should I be concerned about its impact on my SiteCatalyst Traffic Sources reports or the Marketing Channels reports?
BG: As many of you have heard, Google recently debuted a new feature which populates the search results as you are typing your query into the search field. The full details on Google Instant are available here. From an analytics perspective, have no fear; SiteCatalyst will continue to capture the keyword for which Google returned results at the time the user clicked.
For example, let’s say I am looking for a link to the Adobe Photoshop page on adobe.com. Using Google Instant, I type “Adobe Photosh” into the search field, and Google—knowing that I am likely to be searching for Photoshop—immediately returns the results for the “Adobe Photoshop” keyphrase at that point. There are two relevant pieces of data:
- The keyphrase that Google detected, and returned results for (”Adobe Photoshop”)
- The keyphrase that I actually entered (”Adobe Photosh”)
SiteCatalyst will continue to capture #1 above, and you will see the keyword/phrase that was behind the actual search results in your SiteCatalyst reports, including the Traffic Sources reports and the Marketing Channels reports. If you want to capture #2—whatever the user actually typed before getting the results that he or she used—it isn’t difficult to do.* In most cases, Google passes the typed value to the landing page in the query string of the referrer, which means that SiteCatalyst can grab it using JavaScript. A small piece of code placed perhaps in the s_code.js file or on the pages of your site will capture this for you and pass it into a Custom Traffic variable. For example, this would do the trick, provided you’ve got the getQueryParam plug-in installed:
if(document.referrer.indexOf('google.com') > -1 && document.referrer.indexOf('oq=') > -1) {
s.propX=s.getQueryParam('oq',,document.referrer);
}
(NOTE: You could likely do the same thing using VISTA.)
* - A wise reader pointed me to this post by Google denying that oq= is what it appears to be. Regardless, the point is that you can capture anything Google sends to the landing page in the referrer using a little JavaScript and the getQueryParam plug-in. But it may be wise to take into account that Google has not confirmed that oq= is what it appears to be.
Q: How long does the cookie set by the getNewRepeat plug-in last?
BG: It depends on the version of the plug-in that you are using. If you are on getNewRepeat v1.0 (look at the plug-in code; the version number will be in the commented area at the top of the code), then it is a 30-day static cookie, meaning that the cookie will expire 30 days from the user’s first visit. If you are using the latest update to the plug-in, v1.2 (which is now available in the Knowledge Base), then you can choose the cookie expiration by setting the first argument in the function call to the number of days after which the cookie should expire. (The default is still 30 days.) For example,
s.prop1=s.getNewRepeat(60);
would persist the cookie for 60 days. Also note that it is now a rolling expiration, so if the visitor comes back to your site, the cookie is “renewed” for 30 days (or whatever custom period you specify).
Q: Why are there “traffic variables” and “conversion variables?” Why aren’t they the same?
BG: This answer involves a short history lesson. Basically, the reason why the two variable types are not the same is that they were not created at the same time. Custom Traffic (s.prop) variables, with their lack of persistence but pathing and multiple unique visitor metrics, were introduced into SiteCatalyst first, before SiteCatalyst was even called SiteCatalyst. (”SuperStats,” anyone?) As the product progressed and grew in sophistication, it became clear to Product Management that our customers needed a persistent custom variable type which would allow them to tie conversion metrics back to values that occurred earlier in a visit (or in a previous visit). Thus, the Custom Conversion (s.eVar) variable was born.
So, why not just take all of the s.prop variables and make them behave like s.eVar variables? A few reasons. By handling the two variable types differently, we made it possible for certain features to be available for each type of report. Now, we largely solved that problem with the Discover platform, where the line between Custom Traffic reports and Custom Conversion reports is fairly thin. But this was a decade ago, and Discover did not exist yet.
You’re probably thinking, “Okay, so why hasn’t Adobe/Omniture merged the two variable types now that there is a platform that allows interaction between them?” The answer, I think, is that it would take a tremendous effort on the platform side to turn props into eVars (which is always the direction that people request us to go). For example, pathing would need to carry over, so a pathing mechanism would need to be created for all eVars. Same deal with participation metrics. There is a lot to consider. This isn’t to say that it isn’t possible—or desirable—but we have focused on adding functionality to other areas. Along those lines, I think the real question behind the original question is, “Why can I only have 50 eVars?” The good news is that we are working on adding additional eVars at this very moment, so while your props may not become eVars, you will have more conversion variables to work with. And more props, too, for that matter.
Oh, and on that note, here’s a teaser:
Q: Why are there settings for Custom Conversion variables and Custom Traffic variables that cannot be enabled in the Admin Console?
BG: Some settings, such as pathing on Custom Traffic variables and full subrelations on Custom Conversion variables, historically have had a processing cost associated with them, and so they are typically limited in SiteCatalyst v14 (although not in Discover). Therefore, we haven’t exposed those settings so that they are not enabled wantonly and without the necessary preparation on our side in terms of requisite hardware. That said, we are definitely considering ideas like this one to expose these settings with built-in, company-specific limitations to give you as much control as possible. We’re not quite there yet, so you should still talk to your Account Manager to get these more advanced settings turned on.
Q: In Data Warehouse, I show 500 Page Views for a certain page when viewing the Exit Pages column. I take this to mean that the page was an exit page 500 times. But, in SiteCatalyst, I run a Pages report and show the Exits metric, and I only get 100 Exits for this same page. Why?
BG: These reports are actually telling you slightly different things. In the Pages report in SiteCatalyst, the number of Exits for a page simply shows the number of times that the given page was the last one in a visit. Nothing that happened previously in the visit has any bearing whatsoever on that metric. In Data Warehouse, “Exit Pages” is a breakdown—not a metric—and that is an important distinction. Data Warehouse calculates the exit page for a visit and ties whatever occurred during that visit to the exit page. So, when you view that breakdown with the Page Views metric in Data Warehouse, what you are really saying is, “Show me all of the Page Views for visits where page X was the exit page.” All page views during the visit leading up to the exit page are also included in that total. Hence, you will get a different number in Data Warehouse because the request itself is fundamentally different.
Q: I find it hard to manage my SAINT classifications. It would be great if there were some way for me to know when certain records were last updated. I can get SAINT upload information from the logs in the Admin Console, but they don’t give any insight into specific rows/keys. Is there a recommended way for me to keep track of this?
BG: Chiefly, this solution should address—at least as a workaround—one of the concerns regarding classification management that I have heard as I have been out visiting our customers: How do I know when my SAINT rows were last edited/updated, either by me or by someone on my team?
Here’s the solution:
Just add a column called “Last Update” to your classification structure on any of your variables.
Make it a text-based classification (rather than a date-enabled classification) in spite of its title. When you are creating your SAINT file for upload, you are going to put the current date in this column. It might look something like this:
(The next thing you should do, in most cases, is let anyone else who might touch SAINT—other admins on your account—know what you’re doing. You don’t want them getting confused by this new column in the SAINT template that doesn’t have a corresponding report in your SiteCatalyst UI.)
What this is going to give you is a sort of a timestamp in your SAINT exports indicating when each row was last touched so that you can make updates armed with information about the age of various rows. If you can get other members of your organization to use this column appropriately and consistently, then it will let anyone know which rows have gone years without pruning, and which were just updated last week. That might be easier said than done, but in some cases it is definitely worth considering.
As always, if you have any questions about anything in this post, or about anything else related to the Adobe Online Marketing Suite, please leave a comment here or contact me on Twitter and I’ll do my best to get you the information that you need.

I would like to add to the Exit Page in Data Warehouse bit. It is possible to yield the same result as the SiteCatalyst report by setting your segmentation to the right criteria. In this case, use a Page View container and set Exit Page to equal the desired Page Name.
I will reinforce the concept of what the Data Warehouse really does is answer the question of: “Show me all of the data related to the sessions where XXX is true.” This make defining the question clearly more important than what you may be used to in SiteCatalyst.
Nice bit on adding the date stamp on the SAINT file. Great idea especially if you’ve got a script doing the heavy lifting.
Steve,
That’s a great point—thank you for sharing that insight. You are absolutely right—you can get the same data out of Data Warehouse with a bit of segmentation.
Ben
Ben -
In the getNewRepeat plugin documentation v1.2, there are references to setting multiple cookie expirations into different s.props. Do you have any guidance on how many to set (30,60,90,365 days), or why an analyst would want to measure New vs. Repeat on multiple cookie expirations?
Randy: This is a great question, and one that I’ve had to think quite a bit about, frankly. One possible use case is breaking down different eVar variables that have various expiration settings. For example, if you have one eVar that expires after 30 days and another that expires after 90 days, you may want different new/repeat settings so you can be consistent in your breakdowns. You may also have various circumstances that require a different view into when someone may have returned to your site. For example, if you’re segmenting by “Visitors who returned to the site within 90 days,” that’s a different segment than “Visitors who returned to the site within 30 days.” Does that help clarify?
Yes it does Ben, thanks! I haven’t really dug into the New/Repeat plugin too much, but you’ve sparked a few analyses to put on my to-do list…