Tracking With First-Party Cookies
I just updated by SiteCatalyst tracking so that the image request is under a first-party cookie. Fortunately my hosting provider made it very simple to apply the CNAME. If you look at the image request you will see that the domain is k.willeitner.org rather than the kwilleitner namespace I had on the 2o7.net cookie. The request is still being sent to 2o7.net but under the friendly alias of k.willeitner.org.
Why switch to a first-party cookie?
First-party cookies are more accepted than a third-party cookie. This is because it is under the same domain as the site that you requested rather than a possibly unfamiliar domain. Also, the 2o7.net cookie is a known tracking cookie which makes it more suseptable to being nuked by security software that you might have on your computer. Additionaly, if you start getting too many cookies on the 2o7.net domain then cookie bumbing or cookie size could become an issue.
In the end, first-party cookies are the way to go. For me it was free because I don’t have any tracking on secure pages but if you did need tracking on secure pages you can buy an SSL Certificate that Omniture can upload to it’s servers. This is done so that the request is secure and there aren’t any security popups in the browser. These usually cost a couple hundred to a thousand bucks and can be bought from a certificate authority like VeriSign, NetworkSolutions, Thawte or others.
digg 
del.icio.us
RSS
FeedBurner
August 22nd, 2008 at 10:40 am
Indeed - I have consultants from both Omniture and other companies tell us to move to a first-party cookie. The wheels were in motion until I found this tidbit in Omniture’s knowledge base the other day:
Friendly Third-Party Cookies for Multi-Suite Tagging Implementations
In certain situations, you may have a report suite that spans several of your domains. In this situation, Omniture recommends using a friendly third-party approach. The friendly third-party approach calls for a cookie that is set on a single “metrics collection subdomain” that has a friendly name.
Consider the scenario in which a hypothetical media conglomerate named NewsNow, Inc. owns ten different domains. To ensure accurate data collection, NewsNow would set its friendly third-party cookie to omn.newsnow.com. The benefit to this approach is that NewsNow could continue to have insight into the global view of all of their domains (e.g. de-duplicated visits, de-duplicated visitors, cross-domain campaign tracking, et cetera) by utilizing the cross-domain functionality that third-party cookies satisfy.
We use multi-suite tagging and multiple domains (okay…dozens), so I’m now waiting to hear back from Omniture Support on next steps to take.
August 22nd, 2008 at 12:10 pm
You bring up a good point about friendly third-party cookies. If you just have a single domain then you will almost always want to go with first-party cookies because of the higher acceptance rate. However, if you have multiple domains and you want to share a common visitor id then friendly third-party cookies are very useful. They are friendly because they are likely not a well known tracking domain and if the user is familiar with your other sites then then they may welcome it. With a friendly third-party cookie you can have all of your individual domains combine into a global report suite and the visitor id will be consistent for a visitor even if they move across domains. If you don’t have a global suite or you don’t care about looking at a visitor across sites or spending the money for the SSL certificate for each domain isn’t a problem then going with a first-party cookie is the way to go.