<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Karmængine &#187; tracking</title>
	<atom:link href="http://www.karmaengine.com/tag/tracking/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.karmaengine.com</link>
	<description>Scrums, agile development, analytics, SEO, and general commentary from a product owner</description>
	<lastBuildDate>Thu, 22 Apr 2010 08:13:59 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Redirect tracking versus client-side tracking</title>
		<link>http://www.karmaengine.com/general/redirect-tracking-versus-client-side-tracking/</link>
		<comments>http://www.karmaengine.com/general/redirect-tracking-versus-client-side-tracking/#comments</comments>
		<pubDate>Tue, 27 Jan 2009 14:06:24 +0000</pubDate>
		<dc:creator>Jacob</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[77Tool]]></category>
		<category><![CDATA[tracking]]></category>

		<guid isPermaLink="false">http://www.karmaengine.com/?p=31</guid>
		<description><![CDATA[I am writing this hopefully to educate some of the people I work with, who seem to be astonished by the fact that sometimes usually there&#8217;&#8217;s discrepancies between these two entirely different methods of tracking traffic.
The main point is this. One tracks before the visitor lands on the website, and the other tracks during page [...]]]></description>
			<content:encoded><![CDATA[<p>I am writing this hopefully to educate some of the people I work with, who seem to be astonished by the fact that <del>sometimes</del> usually there&#8217;&#8217;s discrepancies between these two entirely different methods of tracking traffic.</p>
<p>The main point is this. One tracks before the visitor lands on the website, and the other tracks during page load.</p>
<p>77Tool is capable of both methods. </p>
<table><Tr><Td><strong>On-click tracking</strong></Td><Td><strong>On-site tracking</strong></Td></Tr><Tr><Td><img src="http://karmaengine.com/_img/click-tracking.png" alt="Redirect or on-click tracking" /></Td><Td><img src="http://karmaengine.com/_img/on-site-tracking.png" alt="On-site tracking" /></Td></Tr></TABLE></p>
<p><strong>Problems with on-site tracking</strong><br />
With on-site tracking, the entry is only recorded after the script has loaded on the page. A number of things can prevent this.</p>
<ul>
<li>Browser has scripts blocked. &#8211; In this case, a &#8221;&#8221;noscript&#8221;&#8221; version of the tracking needs to be in place. This is usually an image tag, and it&#8221;&#8217;&#8217;s highly likely that the browser is not set to ignore images.</li>
<li>Visitor clicks something on the website and moves away from the page before the script has time to load. Nothing can be done about this. Try to get the script placed at the top of the page code, so it loads before anything clickable.</li>
<li>Script is not implemented correctly &#8211; Typos or incorrectly copy+pastes can lead to complete malfunction of the script. Make sure to test after implementation. Luckily, 77Tool has only a 3 minute wait between entry and reporting of entry in the 77Tool interface. This makes testing easy.</li>
<li>Script does not have all required information. Our script generally requires a 77tadunit to be available in the source URL. An alternative is to have this value set on the website itself, but without either of these, the entry will land in natural traffic. Website tag is generally implemented in the site code, but is something else which can be stuffed into the source URL.</li>
<li>Cookies blocked &#8211; if the browser does not accept our cookie, entry will be created, but the visitor might not be linked to the conversion, and the conversion will end up in natural traffic. In general, our cookie is able to write to browsers set to &#8221;&#8221;high&#8221;&#8221; security and anything below (assuming a higher level exists).
</ul>
<p><strong>Problems with on-click or redirect tracking</strong><br />
Mostly, on-click tracking is more effective at reporting entries. User clicks on the advert, entry is registered, and only then do they get to the website. Problems still exist..:</p>
<ul>
<li>If website is down, entry is still reported, even though visitor never got to the website.</li>
<li>If the redirect server fails, user never reaches the website.</li>
<li>Parameters must be correct in the redirect URL, or visitor can end up on the wrong landing page.</li>
<li>A script or pixel must be called during conversion anyway.</li>
<p>The main issue with on-click tracking is the second point. A strong system needs to be in place in the event of redirect server failure. In 77Agency we have a backup system in place, and a five minute TTL on our DNS records, so we can change redirect servers rapidly.<br />
<strong><br />
Why the different methods create discrepancies</strong></p>
<p>Basically, the on-click method will always report higher entries, simply because it has none of the limitations of browser problems loading the on-site script. </p>
<p>This is not just the difference between our own two methods, it should be expected when comparing our on-site tracking with third party on-click systems also.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.karmaengine.com/general/redirect-tracking-versus-client-side-tracking/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
