<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: The Shopping Comparison Engines Have A Long Way To Go</title>
	<atom:link href="http://comparisonengines.com/2006/12/05/the-shopping-comparison-engines-have-a-long-way-to-go/feed/" rel="self" type="application/rss+xml" />
	<link>http://comparisonengines.com/2006/12/05/the-shopping-comparison-engines-have-a-long-way-to-go/</link>
	<description>Just another WordPress.com weblog</description>
	<lastBuildDate>Fri, 09 Dec 2011 18:27:04 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: fg</title>
		<link>http://comparisonengines.com/2006/12/05/the-shopping-comparison-engines-have-a-long-way-to-go/#comment-844</link>
		<dc:creator><![CDATA[fg]]></dc:creator>
		<pubDate>Thu, 07 Dec 2006 22:17:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.comparisonengines.com/?p=629#comment-844</guid>
		<description><![CDATA[At the very least, they should give us API access to at least pull reports.

SKU-level reporting would be nice, but I&#039;d settle for an overall spend at the engine level at this point.

I&#039;d probably spend more money with the engines if I was able to at least pull spend reports at the engine level.  Pulling spend reports isn&#039;t that much of a headache if you&#039;re only managing 1 merchant, but when you&#039;re managing 40+ feeds, it becomes a real burden.

Hiring someone to pull reports isn&#039;t exactly cost effective, either.]]></description>
		<content:encoded><![CDATA[<p>At the very least, they should give us API access to at least pull reports.</p>
<p>SKU-level reporting would be nice, but I&#8217;d settle for an overall spend at the engine level at this point.</p>
<p>I&#8217;d probably spend more money with the engines if I was able to at least pull spend reports at the engine level.  Pulling spend reports isn&#8217;t that much of a headache if you&#8217;re only managing 1 merchant, but when you&#8217;re managing 40+ feeds, it becomes a real burden.</p>
<p>Hiring someone to pull reports isn&#8217;t exactly cost effective, either.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: EarlyMiser</title>
		<link>http://comparisonengines.com/2006/12/05/the-shopping-comparison-engines-have-a-long-way-to-go/#comment-843</link>
		<dc:creator><![CDATA[EarlyMiser]]></dc:creator>
		<pubDate>Thu, 07 Dec 2006 15:49:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.comparisonengines.com/?p=629#comment-843</guid>
		<description><![CDATA[That&#039;s a good point - for some reason the tools for merchants seem as bad as the tools for distribution partners. I would imagine part of the problem has to do with the fact that information is passed among multiple partners and no one has the complete informational picture. Another problem is that there is a lot of legacy thinking and legacy code in many of the current shopping comparison engines - they aren&#039;t flexible enough to accomodate this sort of tracking and never thought about it. Additionally most if not all of their distribution partners aren&#039;t going to be willing to share or are unable to share this information. It makes it difficult to gather comprehensive data - we might see Google actually achive this with a combination of Google Analytics, Froogle, Adsense and Google checkout. But it almost requires you to own all the pieces of the pie.]]></description>
		<content:encoded><![CDATA[<p>That&#8217;s a good point &#8211; for some reason the tools for merchants seem as bad as the tools for distribution partners. I would imagine part of the problem has to do with the fact that information is passed among multiple partners and no one has the complete informational picture. Another problem is that there is a lot of legacy thinking and legacy code in many of the current shopping comparison engines &#8211; they aren&#8217;t flexible enough to accomodate this sort of tracking and never thought about it. Additionally most if not all of their distribution partners aren&#8217;t going to be willing to share or are unable to share this information. It makes it difficult to gather comprehensive data &#8211; we might see Google actually achive this with a combination of Google Analytics, Froogle, Adsense and Google checkout. But it almost requires you to own all the pieces of the pie.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: vb</title>
		<link>http://comparisonengines.com/2006/12/05/the-shopping-comparison-engines-have-a-long-way-to-go/#comment-842</link>
		<dc:creator><![CDATA[vb]]></dc:creator>
		<pubDate>Wed, 06 Dec 2006 20:46:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.comparisonengines.com/?p=629#comment-842</guid>
		<description><![CDATA[That api needs to have a way for Merchants to report order disposition.

As merchants were asked to participate in the ROI Program, and certainly ROI figures can be factored into click rate increases and that&#039;s OK.

However, the SCE has no idea when some of these orders are canceled and it&#039;s only fair to the Merchant that this information be considered right alongside of the ROI Conversion Data. Basically, touting conversion stats w/o know the canellation rate is bogus.]]></description>
		<content:encoded><![CDATA[<p>That api needs to have a way for Merchants to report order disposition.</p>
<p>As merchants were asked to participate in the ROI Program, and certainly ROI figures can be factored into click rate increases and that&#8217;s OK.</p>
<p>However, the SCE has no idea when some of these orders are canceled and it&#8217;s only fair to the Merchant that this information be considered right alongside of the ROI Conversion Data. Basically, touting conversion stats w/o know the canellation rate is bogus.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

