<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.4" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Tracking With First-Party Cookies</title>
	<link>http://www.willeitner.org/2008/08/21/tracking-with-first-party-cookies/?tid=commentsrss2feed</link>
	<description>Internet Marketing Insights</description>
	<pubDate>Thu, 09 Sep 2010 10:27:26 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>by: Kevin</title>
		<link>http://www.willeitner.org/2008/08/21/tracking-with-first-party-cookies/#comment-7158?tid=commentsrss2feed</link>
		<pubDate>Fri, 22 Aug 2008 19:10:35 +0000</pubDate>
		<guid>http://www.willeitner.org/2008/08/21/tracking-with-first-party-cookies/#comment-7158?tid=commentsrss2feed</guid>
					<description>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.</description>
		<content:encoded><![CDATA[<p>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&#8217;t have a global suite or you don&#8217;t care about looking at a visitor across sites or spending the money for the SSL certificate for each domain isn&#8217;t a problem then going with a first-party cookie is the way to go.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Ted McDonald</title>
		<link>http://www.willeitner.org/2008/08/21/tracking-with-first-party-cookies/#comment-7157?tid=commentsrss2feed</link>
		<pubDate>Fri, 22 Aug 2008 17:40:55 +0000</pubDate>
		<guid>http://www.willeitner.org/2008/08/21/tracking-with-first-party-cookies/#comment-7157?tid=commentsrss2feed</guid>
					<description>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.</description>
		<content:encoded><![CDATA[<p>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&#8217;s knowledge base the other day:</p>
<p>Friendly Third-Party Cookies for Multi-Suite Tagging Implementations</p>
<p>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 &#8220;metrics collection subdomain&#8221; that has a friendly name.</p>
<p>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.</p>
<p>We use multi-suite tagging and multiple domains (okay&#8230;dozens), so I&#8217;m now waiting to hear back from Omniture Support on next steps to take.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
