Blog Post: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:
  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('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: 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.
Author: Date Created:September 20, 2010 Date Published: Headline:Ben Gaines mailbag #4 Social Counts: Keywords: Publisher:Adobe Image:https://blogs.adobe.com/digitalmarketing/wp-content/uploads/no-image/no-image.jpg

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:

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

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.