It has been far too long since I pub­lished some of the ques­tions I’ve been receiv­ing via Twit­ter, e-mail, blog com­ments, the Idea Exchange, and else­where. Last year at about this time, in prepa­ra­tion for Sum­mit 2010, I pub­lished a list of the top 10 things I enjoyed about Omni­ture Sum­mit 2009. My list for this year look­ing ahead a few weeks to Sum­mit looks like this:

Ben’s Top 10 Per­sonal High­lights from Sum­mit 2010

  1. Pre­sent­ing. This was absolutely nuts. When I began attend­ing Sum­mit in 2007, I never imag­ined I’d be up there pre­sent­ing some­day. It was a blast, and I think we (myself and my co-presenters, includ­ing the inim­itable Car­men Sut­ter) were able to give some great tips on advanced Site­Cat­a­lyst prac­tices. How­ever, the 2011 ver­sion of the ses­sion may never be topped.
  2. Meet­ing so many of you. 2009 was great because we had just launched the Omni­ture­Care on Twit­ter the pre­vi­ous Decem­ber. By March 2010, the num­ber of folks with whom I had inter­acted via social media had increased seem­ingly expo­nen­tially. You—the user community—are awe­some. As one Twit­ter user men­tioned just today, “#omni­ture com­mu­nity rocks!! ultra-responsive, diver­si­fied and just amaz­ing!” She’s right.
  3. The keynote speak­ers inspired me, and the qual­ity of the break­outs impressed and taught me things that have proven immensely valu­able to me over the past 12 months. A prover­bial tip of my cap to the many pre­sen­ters who put in hun­dreds of hours to pro­vide tremen­dous value to attendees.
  4. The venue. Grand Amer­ica and Lit­tle Amer­ica are top notch. They take great care of us. It’s a beau­ti­ful place to learn, net­work, eat, drink, and party. Being at Sum­mit there makes me feel like I’m at the cen­ter of the world.
  5. This video.
  6. Brett Error’s clos­ing ses­sion. Year after year, it always makes me proud to be asso­ci­ated with the Online Mar­ket­ing Suite.
  7. Going here with Rudi Shumpert dur­ing his first visit to Salt Lake City. What great mole.
  8. I stum­bled into a lunch at one point that had one of the great­est deserts I’ve ever eaten. It was some sort of a choco­late mousse half-sphere with pis­ta­chio mousse on the inside and a rich choco­late ganache on the out­side. I did, in fact, eat two of them. That hap­pens a lot at Summit.
  9. The enter­tain­ment. I’m still not sure whether I’m allowed to men­tion who it was, even a year after the fact, so you’ll for­give me if you weren’t there and haven’t heard who it was. They rocked.
  10. Poken.” Yep, 12 months later it’s still still fun to say.

Now, here are your ques­tions and my answers.

Q: So, will you be pre­sent­ing at Sum­mit 2011?

BG: Absolutely! My topic this year is imple­men­ta­tion health and gov­er­nance, so atten­dees will learn how to shore up their own imple­men­ta­tion process and man­age it despite the strug­gles and chal­lenges that many orga­ni­za­tions face when it comes to deploy­ing, man­ag­ing, and updat­ing tag-based solu­tions. The ses­sion will not be extremely tech­ni­cal; instead, dis­cus­sion will focus on process man­age­ment so that you can edu­cate your col­leagues and improve the qual­ity of your web ana­lyt­ics data gen­er­ally. We’ll also dis­cuss how an audit­ing solu­tion like Adobe Dig­i­talPulse can help ensure the integrity of your ana­lyt­ics data. I will be joined at the front of the room by David Hebel, Senior Con­sul­tant here at Adobe, and by Aaron Gra­ham, Senior Man­ager of Opti­miza­tion and Ana­lyt­ics at McAfee, Inc., and I am hon­ored and excited to be pre­sent­ing with them.

A link to the ses­sion info is here. Magic will be hap­pen­ing twice: 3:30 PM on Wednes­day (3÷9) and 11:00 AM Thurs­day (3÷10). See you there!

Q: I am look­ing at a Cus­tom Con­ver­sion report, show­ing the Instances met­ric and a Page Views cus­tom event met­ric. Why is Page Views higher than Instances? Shouldn’t they be the same?

BG: Site­Cat­a­lyst cus­tom events that occur on your site are asso­ci­ated with a Cus­tom Con­ver­sion (eVar) value as long as that value per­sists for the given vis­i­tor, whereas the Instances met­ric reports the num­ber of times that the eVar received a value. Let’s say your eVar expires at the end of the visit, and that this eVar gets pop­u­lated with a value of “New User” on the first page view of a cer­tain user’s visit, but does not get pop­u­lated there­after. You would see one Instance for the “New User” value in the asso­ci­ated Cus­tom Con­ver­sion report, but you would see a Page View for each of the page views that occurred after the value was set, but before the visit ended.

Keep in mind that Instances is NOT the same thing as Vis­its. You will see an Instance every time the eVar is set on the site. If you set the eVar on every page view, then you should expect Instances to equal a cor­rectly imple­mented Page Views cus­tom event. The Vis­its met­ric, on the other hand, will be counted once (and only once) per visit for each eVar value that gets set dur­ing the visit—even if that same eVar value is passed repeat­edly dur­ing the visit.

Q: Is IP Exclu­sion in Site­Cat­a­lyst company-specific, or report suite-specific?

BG: It is report suite-specific. If you exclude IP addresses by going to Admin > Exclude by IP in Site­Cat­a­lyst, be aware that it will apply only to the selected report suite. Make sure to add IP addresses (or ranges) for each report suite where you want to exclude data.

Q: Does IP Exclu­sion apply to Data Inser­tion API requests?

BG: Yes. IP Exclu­sion is applied after data has been col­lected, so what­ever the IP the request appears to be com­ing from will either be included or excluded regard­less of the data col­lec­tion method used. How­ever, keep in mind that with the Data Inser­tion API you have direct con­trol over the IP address that Site­Cat­a­lyst sees, using the <ipad­dress> ele­ment, which you do not have using JavaScript. What­ever you put in that <ipad­dress> ele­ment is what Site­Cat­a­lyst will see as the orig­i­nat­ing IP address for the server call, and exclusion/inclusion will be based on that address.

Q: What is the enter­tain­ment at Sum­mit going to be?

BG: Nice try.

Seri­ously, though, I don’t know.

Q: What options does Site­Cat­a­lyst give me for clas­si­fy­ing GeoSeg­men­ta­tion data for the United States accord­ing to my own needs?

BG: This led to a nice dis­cus­sion on Twit­ter this past week. In Site­Cat­a­lyst v14.9 we released a fea­ture that allows us to pop­u­late the s.zip vari­able auto­mat­i­cally, on our servers, after data has been col­lected. Using this fea­ture, you don’t need to use the s.zip vari­able in your imple­men­ta­tion if you don’t want to do so. You’ll see this data in the Vis­i­tor Pro­file > Vis­i­tor ZIP/Postal Code report. Then, once that has been set up by your Account Man­ager or Client­Care, you can clas­sify the var­i­ous zip codes into neigh­bor­hoods, cities/towns, coun­ties, regions, areas, DMAs, etc.—whatever you need, includ­ing cus­tom group­ings that align with your busi­ness goals/needs. This approach offers a num­ber of great com­ple­ments to the basic GeoSeg­men­ta­tion reports in SiteCatalyst:

  • Clas­si­fi­ca­tions
  • Con­ver­sion met­rics (such as Rev­enue, Orders, and all cus­tom events)
  • Sub­re­la­tions

There is no cost to use this fea­ture, and it doesn’t require any imple­men­ta­tion changes.

Q: We are work­ing on tag­ging an iPhone app. Should we put the data in the same report suite as our web site, or in a dif­fer­ent report suite?

BG: There are prob­a­bly pros and cons to each approach, and it may depend on the app. The first ques­tion that I asked myself is this: How dif­fer­ent is the app expe­ri­ence from your web expe­ri­ence? In the over­whelm­ing major­ity of cases, a mobile user is going to inter­act with your mobile app dif­fer­ently than they inter­act with your web site. Even if the app is just a front end for your web con­tent, does some­one on an iPhone or iPad or Evo or Galaxy Tab do the same things as a web user? Are you going to make the same changes to your site, based on your analy­sis, that you would make to your mobile app?

The odds are that you’re going to be inter­ested in dif­fer­ent things about your app. Cus­tom vari­ables will be used dif­fer­ently. Met­rics may be dif­fer­ent. Cer­tainly the same vis­i­tor acqui­si­tion chan­nels won’t apply to both. And I’m not sure I would want my mobile app traf­fic inflat­ing my site traf­fic (and vice versa). While it’s true that you can use seg­men­ta­tion in Dis­cover, Data Ware­house, and/or ASI to sep­a­rate out app traf­fic from site traf­fic (prob­a­bly using a Cus­tom Traf­fic vari­able to cap­ture the “app type”), per­son­ally I see much more value in using sep­a­rate report suites in the large major­ity of cases.

Q: Why does my cus­tom link track­ing use the 2o7​.net or omtrdc​.net data col­lec­tion domains even though the rest of my imple­men­ta­tion uses first-party cook­ies (e.g. met​rics​.mysite​.com)?

BG: First, some back­ground information.

When first-party cook­ies are in use, the data col­lec­tion domain is con­trolled by the s.trackingServer and s.trackingServerSecure vari­ables. These vari­ables are mem­bers of the ‘s’ object that gets cre­ated when the page loads, and they are usu­ally con­tained in the s_code.js include file, which means that they are loaded when the page loads. In most cases, when you imple­ment cus­tom link track­ing you include a piece that says

var s=s_gi('my_report_suite_id');

That report suite ID is usu­ally the same as the report suite ID in your s_account vari­able, but some­times it isn’t. When it isn’t, the result of the line of code shown above is the cre­ation of a new ‘s’ object, which doesn’t auto­mat­i­cally have s.trackingServer and s.trackingServerSecure defined.

So, in short, if you are using a dif­fer­ent report suite ID (or set of report suite IDs) when call­ing your link track­ing func­tions, you will want to make sure to define s.trackingServer (and, where applic­a­ble, s.trackingServerSecure) within your link track­ing func­tion call. In the exam­ple below, let’s assume that the s_account value in the s_code.js file was some­thing other than “gainesweblinks.”

function linkTracking(obj) {
var s=s_gi('gainesweblinks');
s.trackingServer='metrics.mysite.com';
s.trackingServerSecure='smetrics.mysite.com';

s.linkTrackVars='eVar1';
s.eVar1='some value';
s.tl(obj,'o','Custom Link');
}

And if you’re won­der­ing why this matters—why you should care if you’re using var­i­ous data col­lec­tion domains at dif­fer­ent times on your site—check out this post.

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.

0 comments