It has been far too long since I published some of the questions I’ve been receiving via Twitter, e-mail, blog comments, the Idea Exchange, and elsewhere. Last year at about this time, in preparation for Summit 2010, I published a list of the top 10 things I enjoyed about Omniture Summit 2009. My list for this year looking ahead a few weeks to Summit looks like this:

Ben’s Top 10 Personal Highlights from Summit 2010

  1. Presenting. This was absolutely nuts. When I began attending Summit in 2007, I never imagined I’d be up there presenting someday. It was a blast, and I think we (myself and my co-presenters, including the inimitable Carmen Sutter) were able to give some great tips on advanced SiteCatalyst practices. However, the 2011 version of the session may never be topped.
  2. Meeting so many of you. 2009 was great because we had just launched the OmnitureCare on Twitter the previous December. By March 2010, the number of folks with whom I had interacted via social media had increased seemingly exponentially. You—the user community—are awesome. As one Twitter user mentioned just today, “#omniture community rocks!! ultra-responsive, diversified and just amazing!” She’s right.
  3. The keynote speakers inspired me, and the quality of the breakouts impressed and taught me things that have proven immensely valuable to me over the past 12 months. A proverbial tip of my cap to the many presenters who put in hundreds of hours to provide tremendous value to attendees.
  4. The venue. Grand America and Little America are top notch. They take great care of us. It’s a beautiful place to learn, network, eat, drink, and party. Being at Summit there makes me feel like I’m at the center of the world.
  5. This video.
  6. Brett Error’s closing session. Year after year, it always makes me proud to be associated with the Online Marketing Suite.
  7. Going here with Rudi Shumpert during his first visit to Salt Lake City. What great mole.
  8. I stumbled into a lunch at one point that had one of the greatest deserts I’ve ever eaten. It was some sort of a chocolate mousse half-sphere with pistachio mousse on the inside and a rich chocolate ganache on the outside. I did, in fact, eat two of them. That happens a lot at Summit.
  9. The entertainment. I’m still not sure whether I’m allowed to mention who it was, even a year after the fact, so you’ll forgive 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 questions and my answers.

Q: So, will you be presenting at Summit 2011?

BG: Absolutely! My topic this year is implementation health and governance, so attendees will learn how to shore up their own implementation process and manage it despite the struggles and challenges that many organizations face when it comes to deploying, managing, and updating tag-based solutions. The session will not be extremely technical; instead, discussion will focus on process management so that you can educate your colleagues and improve the quality of your web analytics data generally. We’ll also discuss how an auditing solution like Adobe DigitalPulse can help ensure the integrity of your analytics data. I will be joined at the front of the room by David Hebel, Senior Consultant here at Adobe, and by Aaron Graham, Senior Manager of Optimization and Analytics at McAfee, Inc., and I am honored and excited to be presenting with them.

A link to the session info is here. Magic will be happening twice: 3:30 PM on Wednesday (3/9) and 11:00 AM Thursday (3/10). See you there!

Q: I am looking at a Custom Conversion report, showing the Instances metric and a Page Views custom event metric. Why is Page Views higher than Instances? Shouldn’t they be the same?

BG: SiteCatalyst custom events that occur on your site are associated with a Custom Conversion (eVar) value as long as that value persists for the given visitor, whereas the Instances metric reports the number 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 populated with a value of “New User” on the first page view of a certain user’s visit, but does not get populated thereafter. You would see one Instance for the “New User” value in the associated Custom Conversion 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 Visits. 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 correctly implemented Page Views custom event. The Visits metric, on the other hand, will be counted once (and only once) per visit for each eVar value that gets set during the visit—even if that same eVar value is passed repeatedly during the visit.

Q: Is IP Exclusion in SiteCatalyst 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 SiteCatalyst, 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 Exclusion apply to Data Insertion API requests?

BG: Yes. IP Exclusion is applied after data has been collected, so whatever the IP the request appears to be coming from will either be included or excluded regardless of the data collection method used. However, keep in mind that with the Data Insertion API you have direct control over the IP address that SiteCatalyst sees, using the <ipaddress> element, which you do not have using JavaScript. Whatever you put in that <ipaddress> element is what SiteCatalyst will see as the originating IP address for the server call, and exclusion/inclusion will be based on that address.

Q: What is the entertainment at Summit going to be?

BG: Nice try.

Seriously, though, I don’t know.

Q: What options does SiteCatalyst give me for classifying GeoSegmentation data for the United States according to my own needs?

BG: This led to a nice discussion on Twitter this past week. In SiteCatalyst v14.9 we released a feature that allows us to populate the s.zip variable automatically, on our servers, after data has been collected. Using this feature, you don’t need to use the s.zip variable in your implementation if you don’t want to do so. You’ll see this data in the Visitor Profile > Visitor ZIP/Postal Code report. Then, once that has been set up by your Account Manager or ClientCare, you can classify the various zip codes into neighborhoods, cities/towns, counties, regions, areas, DMAs, etc.—whatever you need, including custom groupings that align with your business goals/needs. This approach offers a number of great complements to the basic GeoSegmentation reports in SiteCatalyst:

  • Classifications
  • Conversion metrics (such as Revenue, Orders, and all custom events)
  • Subrelations

There is no cost to use this feature, and it doesn’t require any implementation changes.

Q: We are working on tagging an iPhone app. Should we put the data in the same report suite as our web site, or in a different report suite?

BG: There are probably pros and cons to each approach, and it may depend on the app. The first question that I asked myself is this: How different is the app experience from your web experience? In the overwhelming majority of cases, a mobile user is going to interact with your mobile app differently than they interact with your web site. Even if the app is just a front end for your web content, does someone 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 analysis, that you would make to your mobile app?

The odds are that you’re going to be interested in different things about your app. Custom variables will be used differently. Metrics may be different. Certainly the same visitor acquisition channels won’t apply to both. And I’m not sure I would want my mobile app traffic inflating my site traffic (and vice versa). While it’s true that you can use segmentation in Discover, Data Warehouse, and/or ASI to separate out app traffic from site traffic (probably using a Custom Traffic variable to capture the “app type”), personally I see much more value in using separate report suites in the large majority of cases.

Q: Why does my custom link tracking use the 2o7.net or omtrdc.net data collection domains even though the rest of my implementation uses first-party cookies (e.g. metrics.mysite.com)?

BG: First, some background information.

When first-party cookies are in use, the data collection domain is controlled by the s.trackingServer and s.trackingServerSecure variables. These variables are members of the ‘s’ object that gets created when the page loads, and they are usually contained in the s_code.js include file, which means that they are loaded when the page loads. In most cases, when you implement custom link tracking you include a piece that says

var s=s_gi('my_report_suite_id');

That report suite ID is usually the same as the report suite ID in your s_account variable, but sometimes it isn’t. When it isn’t, the result of the line of code shown above is the creation of a new ‘s’ object, which doesn’t automatically have s.trackingServer and s.trackingServerSecure defined.

So, in short, if you are using a different report suite ID (or set of report suite IDs) when calling your link tracking functions, you will want to make sure to define s.trackingServer (and, where applicable, s.trackingServerSecure) within your link tracking function call. In the example below, let’s assume that the s_account value in the s_code.js file was something 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 wondering why this matters—why you should care if you’re using various data collection domains at different times on your site—check out this post.

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.

0 comments