It’s been a while, but it is finally time for another mail­bag. I wish I could blame my lack of activ­ity as a blog­ger on the book that I’m writ­ing, as my hero, Bill Sim­mons, did for months in 2008. The actual rea­sons (help­ing to build the next ver­sions of Site­Cat­a­lyst and Dig­i­talPulse) may not be quite as sexy, but they are prob­a­bly more impor­tant. When­ever pos­si­ble, though, I have been busy gath­er­ing ques­tions and research­ing answers for you. As always, each of these ques­tions comes from an actual Online Mar­ket­ing Suite client.

Q: What’s the deal with Google Instant Search? Should I be con­cerned about its impact on my Site­Cat­a­lyst Traf­fic Sources reports or the Mar­ket­ing Chan­nels reports?

BG: As many of you have heard, Google recently debuted a new fea­ture which pop­u­lates the search results as you are typ­ing your query into the search field. The full details on Google Instant are avail­able here. From an ana­lyt­ics per­spec­tive, have no fear; Site­Cat­a­lyst will con­tinue to cap­ture the key­word for which Google returned results at the time the user clicked.

For exam­ple, let’s say I am look­ing for a link to the Adobe Pho­to­shop page on adobe​.com. Using Google Instant, I type “Adobe Pho­tosh” into the search field, and Google—knowing that I am likely to be search­ing for Photoshop—immediately returns the results for the “Adobe Pho­to­shop” keyphrase at that point. There are two rel­e­vant pieces of data:

  1. The keyphrase that Google detected, and returned results for (“Adobe Photoshop”)
  2. The keyphrase that I actu­ally entered (“Adobe Photosh”)

Site­Cat­a­lyst will con­tinue to cap­ture #1 above, and you will see the keyword/phrase that was behind the actual search results in your Site­Cat­a­lyst reports, includ­ing the Traf­fic Sources reports and the Mar­ket­ing Chan­nels reports. If you want to cap­ture #2—whatever the user actu­ally typed before get­ting the results that he or she used—it isn’t dif­fi­cult to do.* In most cases, Google passes the typed value to the land­ing page in the query string of the refer­rer, which means that Site­Cat­a­lyst can grab it using JavaScript. A small piece of code placed per­haps in the s_code.js file or on the pages of your site will cap­ture this for you and pass it into a Cus­tom Traf­fic vari­able. For exam­ple, this would do the trick, pro­vided you’ve got the get­Query­Param 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 deny­ing that oq= is what it appears to be. Regard­less, the point is that you can cap­ture any­thing Google sends to the land­ing page in the refer­rer using a lit­tle JavaScript and the get­Query­Param plug-in. But it may be wise to take into account that Google has not con­firmed that oq= is what it appears to be.

Q: How long does the cookie set by the get­NewRe­peat plug-in last?

BG: It depends on the ver­sion of the plug-in that you are using. If you are on get­NewRe­peat v1.0 (look at the plug-in code; the ver­sion num­ber will be in the com­mented area at the top of the code), then it is a 30-day sta­tic cookie, mean­ing that the cookie will expire 30 days from the user’s first visit. If you are using the lat­est update to the plug-in, v1.2 (which is now avail­able in the Knowl­edge Base), then you can choose the cookie expi­ra­tion by set­ting the first argu­ment in the func­tion call to the num­ber of days after which the cookie should expire. (The default is still 30 days.) For example,

s.prop1=s.getNewRepeat(60);

would per­sist the cookie for 60 days. Also note that it is now a rolling expi­ra­tion, so if the vis­i­tor comes back to your site, the cookie is “renewed” for 30 days (or what­ever cus­tom period you specify).

Q: Why are there “traf­fic vari­ables” and “con­ver­sion vari­ables?” Why aren’t they the same?

BG: This answer involves a short his­tory les­son. Basi­cally, the rea­son why the two vari­able types are not the same is that they were not cre­ated at the same time. Cus­tom Traf­fic (s.prop) vari­ables, with their lack of per­sis­tence but pathing and mul­ti­ple unique vis­i­tor met­rics, were intro­duced into Site­Cat­a­lyst first, before Site­Cat­a­lyst was even called Site­Cat­a­lyst. (“Super­Stats,” any­one?) As the prod­uct pro­gressed and grew in sophis­ti­ca­tion, it became clear to Prod­uct Man­age­ment that our cus­tomers needed a per­sis­tent cus­tom vari­able type which would allow them to tie con­ver­sion met­rics back to val­ues that occurred ear­lier in a visit (or in a pre­vi­ous visit). Thus, the Cus­tom Con­ver­sion (s.eVar) vari­able was born.

So, why not just take all of the s.prop vari­ables and make them behave like s.eVar vari­ables? A few rea­sons. By han­dling the two vari­able types dif­fer­ently, we made it pos­si­ble for cer­tain fea­tures to be avail­able for each type of report. Now, we largely solved that prob­lem with the Dis­cover plat­form, where the line between Cus­tom Traf­fic reports and Cus­tom Con­ver­sion reports is fairly thin. But this was a decade ago, and Dis­cover did not exist yet.

You’re prob­a­bly think­ing, “Okay, so why hasn’t Adobe/Omniture merged the two vari­able types now that there is a plat­form that allows inter­ac­tion between them?” The answer, I think, is that it would take a tremen­dous effort on the plat­form side to turn props into eVars (which is always the direc­tion that peo­ple request us to go). For exam­ple, pathing would need to carry over, so a pathing mech­a­nism would need to be cre­ated for all eVars. Same deal with par­tic­i­pa­tion met­rics. There is a lot to con­sider. This isn’t to say that it isn’t possible—or desirable—but we have focused on adding func­tion­al­ity to other areas. Along those lines, I think the real ques­tion behind the orig­i­nal ques­tion is, “Why can I only have 50 eVars?” The good news is that we are work­ing on adding addi­tional eVars at this very moment, so while your props may not become eVars, you will have more con­ver­sion vari­ables 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 set­tings for Cus­tom Con­ver­sion vari­ables and Cus­tom Traf­fic vari­ables that can­not be enabled in the Admin Console?

BG: Some set­tings, such as pathing on Cus­tom Traf­fic vari­ables and full sub­re­la­tions on Cus­tom Con­ver­sion vari­ables, his­tor­i­cally have had a pro­cess­ing cost asso­ci­ated with them, and so they are typ­i­cally lim­ited in Site­Cat­a­lyst v14 (although not in Dis­cover). There­fore, we haven’t exposed those set­tings so that they are not enabled wan­tonly and with­out the nec­es­sary prepa­ra­tion on our side in terms of req­ui­site hard­ware. That said, we are def­i­nitely con­sid­er­ing ideas like this one to expose these set­tings with built-in, company-specific lim­i­ta­tions to give you as much con­trol as pos­si­ble. We’re not quite there yet, so you should still talk to your Account Man­ager to get these more advanced set­tings turned on.

Q: In Data Ware­house, I show 500 Page Views for a cer­tain page when view­ing the Exit Pages col­umn. I take this to mean that the page was an exit page 500 times. But, in Site­Cat­a­lyst, I run a Pages report and show the Exits met­ric, and I only get 100 Exits for this same page. Why?

BG: These reports are actu­ally telling you slightly dif­fer­ent things. In the Pages report in Site­Cat­a­lyst, the num­ber of Exits for a page sim­ply shows the num­ber of times that the given page was the last one in a visit. Noth­ing that hap­pened pre­vi­ously in the visit has any bear­ing what­so­ever on that met­ric. In Data Ware­house, “Exit Pages” is a breakdown—not a metric—and that is an impor­tant dis­tinc­tion. Data Ware­house cal­cu­lates the exit page for a visit and ties what­ever occurred dur­ing that visit to the exit page. So, when you view that break­down with the Page Views met­ric in Data Ware­house, what you are really say­ing is, “Show me all of the Page Views for vis­its where page X was the exit page.” All page views dur­ing the visit lead­ing up to the exit page are also included in that total. Hence, you will get a dif­fer­ent num­ber in Data Ware­house because the request itself is fun­da­men­tally different.

Q: I find it hard to man­age my SAINT clas­si­fi­ca­tions. It would be great if there were some way for me to know when cer­tain records were last updated. I can get SAINT upload infor­ma­tion from the logs in the Admin Con­sole, but they don’t give any insight into spe­cific rows/keys. Is there a rec­om­mended way for me to keep track of this?

BG: Chiefly, this solu­tion should address—at least as a workaround—one of the con­cerns regard­ing clas­si­fi­ca­tion man­age­ment that I have heard as I have been out vis­it­ing our cus­tomers: How do I know when my SAINT rows were last edited/updated, either by me or by some­one on my team?

Here’s the solution:

Just add a col­umn called “Last Update” to your clas­si­fi­ca­tion struc­ture on any of your variables.

SAINT classification structure including 'Last Update' column

Make it a text-based clas­si­fi­ca­tion (rather than a date-enabled clas­si­fi­ca­tion) in spite of its title. When you are cre­at­ing your SAINT file for upload, you are going to put the cur­rent date in this col­umn. It might look some­thing like this:

SAINT template with 'Last Update' values filled in

(The next thing you should do, in most cases, is let any­one else who might touch SAINT—other admins on your account—know what you’re doing. You don’t want them get­ting con­fused by this new col­umn in the SAINT tem­plate that doesn’t have a cor­re­spond­ing report in your Site­Cat­a­lyst UI.)

What this is going to give you is a sort of a time­stamp in your SAINT exports indi­cat­ing when each row was last touched so that you can make updates armed with infor­ma­tion about the age of var­i­ous rows. If you can get other mem­bers of your orga­ni­za­tion to use this col­umn appro­pri­ately and con­sis­tently, then it will let any­one know which rows have gone years with­out prun­ing, and which were just updated last week. That might be eas­ier said than done, but in some cases it is def­i­nitely worth considering.

As always, if you have any ques­tions about any­thing in this post, or about any­thing else related to the Adobe Online Mar­ket­ing Suite, please leave a com­ment here or con­tact me on Twit­ter and I’ll do my best to get you the infor­ma­tion that you need.

6 comments
Strony
Strony

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