“ZiXXo™ provides a web-based coupon creation, management and syndication network that enables businesses to reward favorable behavior by local consumers. In plain English, that means that businesses can create and manage their coupons with us and we syndicate them out to local consumers through partner websites.”

The Affiliate Program and the API
I have been in touch with Mike Hogan and have took a moment to briefly go through Zixxo’s recently released API, which is integrated in their Affiliate Program. Here are my initial thoughts, with more to come later…

.NET, nice! Both SOAP and REST support, also nice. They give plenty of code examples to get you started programming in .NET. Looks like it shouldn’t be too much trouble to implement for an MS Developer. Unfortunately, no revenue share will come for at least six months.

As of now, the entire service is free, but in the future they will charge advertisers and share revenue with affiliates. A couple conerns I had with the coupon results returned from the API were:

1. Phone numbers with a reference code, eg. call 1800-xxx-xxxx and use reference code ZIXXO. Hmm, as an affiliate how do I get credit?
2. There are a lot of “Printable Coupons” for online stores. How does this get tracked from an affiliate perspective?

Who should get the lions share of revenue?
This is relates directly to ZiXXo’s Affiliate Compensation Plan. It is obvious here that referring an advertiser (called an Ad Rep) is more important at the forefront. However, without the Coupon Distributor you aren’t reaching nearly as large a consumer audience. The affiliate traffic and exposure gained through affiliate marketing is substantial. Especially for mashup developers utilizing their API.

Initially their revenue share was 40% and 10%, but it seems they have revised it to be a 40/15 split between the Ad Rep and the Coupon Distributor. I’m inclined to suggest higher revenue for the Coupon Distributor or at least some type of tiering, but am not certain how it could work. One thought is of a sub-tier as well depending on how much traffic is being sent to an advertiser. Eg. If I’m running a pizza coupon website and I’m sending 50 prints a day to Bob’s hardware, and only 1 a day to Joe’s Hardware, it might make sense that I receive more revenue with Bob’s pizza… Hmmm?

With out a doubt the Ad Rep will win out on receiving the bulk of the revenue split as it is much harder to acquire new merchants for Zixxo than it is to give consumers the coupon to use. I would say try to be both an Ad Rep and a Coupon Distributor if you can work it into your site!

Finally, the Zixxo system itself has a large potential to change the current process of local coupon creation and redemption for the better.

[tags]Zixxo, coupons, local coupons, syndication, developer, .NET, C#, mashup[/tags]

My previous post of The Next Generation of Deal Sites shared my vision for a model for future deal sites as a shopping comparison hybrid. This follow-up is another interesting concept. A deal aggregator. The one that first comes to my mind is ClipFire, which launched the beginning of this year. It essentially works by aggregating RSS feeds from a variety of different deal sites, and pushing the information into a searchable database. The social part comes into play as users are allowed to vote (or “clip”) their favorite deals and tag them.

Kevin Carey is the creator of this ClipFire service, but some are curious of how he can swing a profit from it. On a TechCrunch post from earlier this year Michael Arrington reviewed the service, and several readers posted some interesting comments regarding the issue of the site generating revenues. One that caught my attention was an idea to manipulate the RSS changing the affiliate IDs 50% of the time. Aside from being an issue of morals, and the pains involved in doing that, it that basically throws the whole point of the community site out the window. Pete Cashmore, of the Mashable.com blog, believes a better approach would have been to split revenue with users and let them post the deals. His review of the ClipFire service, which calls it Digg for Deals, is a skeptical one. Pete I agree with you on the point of perhaps filling up with spam in the future, but only if the site becomes very popular! And what isn’t filling with spam these days?

At this point the site itself seems to be doing fairly well, but I haven’t really heard much buzz about it recently. It has seemed to follow the inevitable trend of “mashups” to have a large traffic spike and then seem to bottom-out after the initial buzz has passed. Check out the Alexa graph below:

As far as the service itself goes, a suggestion I would have Kevin consider is perhaps trying to utilize regular expressions to draw out the expiration date. I’ve used ClipFire myself several times, but on more than one occasion expired information shows up at the top. Stowe Boyd picked up on another problem that didn’t really cross my mind… The issue of different currencies. Stowe states:

“I already noticed one problem: costs of various products are not normalized to the end users currency. I saw deals for London hotel stays provided in pounds, for example. And the cost of goods are embedded in the text associated with the deal, not pulled out as a primary attribute. There is as a result no way to sort by price, which seems an obvious thing to do.”

While making the results sortable by price is definitely not as easy as it sounds, it might be a good idea to determine prior to aggregation what country the feed is coming from. The problem lies within the fact that the deal information is not in a structured format, thus you can’t easily determine the price, just as you can’t easily determine the expiration date. Perhaps it is time for a “deals” microformat!

[tags]deals, clipfire, social search, social shopping, community commerce, digg, microformats[/tags]

To begin I would suggest looking at the merchant rate cards. The merchant rate cards can help give you an idea of who pays out more on a category basis. So if you are thinking of creating a niche site, lets say Flowers, it might be a better option to consider Yahoo! as they offer a higher rate.

Yahoo! Shopping vs Shopping.com Merchant Rates
Yahoo! Shopping Merchant Rate Card
Shopping.com Merchant Rate Card*

* It is important to note that Shopping.com has a bidding engine, meaning the rates you see on the rate card are a minimum, allowing you to potentially generate a significant amount more. Yahoo! Shopping rates are static for all merchants.

While some Yahoo! rates are higher than Shopping.com the average Shopping.com rate is higher. So from a partner / affiliate perspective you have the potential to generate more revenue from partnering with Shopping.com. Of course, that depends on the amount revenue share percentage you agree upon. For starters it is 50% for Shopping.com, and Yahoo! is currently variable as it is in beta.

For further reading, see my previous post about the different shopping comparison engine partner/affiliate offerings.

[tags]Yahoo!, Shopping.com, web services, shopping, e-commerce, shopping comparison, revenue share[/tags]

Jeff Barr over at Amazon had a blog post about a price comparison web service that I had never heard of.  It is called Price-Compare.net.  It seems very geared toward PHP / Amazon AWS developers.  Here is an example  of Mr. and Mrs. Smith comparison information from their custom PHP section. 

Anyway it offers a revenue share option that is Pay-Per-Sale % based rather than Pay-Per-Click (PPC).  Works with LinkShare, Commission Junction (CJ), eBay and Amazon. Interesting idea… I’ll be sure to look into it.

Revenue Sharing Fine Print

“Price-Compare.Net is allowed to withhold a percentage of any commissions earned or randomly substitute your network/affiliate id with one of its own.  The withholding amount and method of substitution can be changed after providing you with a 30 day notice via email or by posting a notice of change here.  The current rates are:
Date: Oct 1, 2005.  Withholding Rate: 20%.  Click Substitution Method: Each of your user clicks will generate a random number between 1 and 5.  If the number generated is 1 then a substitution will occur.”

The Price-Compare.net website itself didn’t look to appealing to me, and the number of stores returning information was not that many, but it is good to see some price comparison options for current affiliate marketers. 

It actually reminds me a lot of GoldenCan which is a service that allows affiliate websites to easily implement Merchant datafeeds and coupon data via a small JavaScript code.  GoldenCan is run by Asif Malik, who I met at Affiliate Summit 2006 (West).

[tags]Price Comparison, Affiliate, Amazon, Amazon Web Service, LinkShare, Commission Junction, GoldenCan[/tags]

“Yahoo! is now accepting applications for a commercial version of our Shopping APIs featuring product search, price comparison, ratings & reviews, and shopping browse. The program, which is now in limited beta, is similar to an affiliate model in that it enables websites to share in income generated from providing shopping search and other services powered by Yahoo! Shopping on their sites. Whether you are building a local shopping mash-up, a next generation social commerce destination, or you simply want to integrate shopping comparison features into your content site, this program is a first major step in providing you with tools to help you generate revenue.”

Also, note that it is in beta and currently it is only “accepting a small number of applicants with special consideration given to sites with high traffic volume and fresh, unique content”.

Currently, our site SecretPrices.com utilizes the Shopping.com API as a backend. But close tabs will be kept on the Yahoo! Shopping program as it continues to evolve. The API is not only fairly well documented, but has an open developer community to back it. Shopping.com really needs to start paying attention…

[tags]Yahoo!, revenue share, comparison shopping, API, mashups[/tags]