Ben Gaines mailbag #4

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:

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.

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:

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