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 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:

  1. The keyphrase that Google detected, and returned results for (“Adobe Photoshop”)
  2. 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('') > -1 && document.referrer.indexOf('oq=') > -1) {

(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,


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:

See? eVar51 and prop51 are not vaporware

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.

SAINT classification structure including 'Last Update' column

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:

SAINT template with 'Last Update' values filled in

(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.


Thank you for making sense of this subject matter. I was getting confused with other information I was finding. You write in an intelligent way.

Randy Zwitch
Randy Zwitch

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...

Randy Zwitch
Randy Zwitch

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?

Steve Fernandez
Steve Fernandez

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.

Ben Gaines
Ben Gaines

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?

Ben Gaines
Ben Gaines

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