Nope.

InitialEarningsPerSale for example "takes into account refunds, chargebacks, and sales tax." Calculating a price based on InitialEarningsPerSale might work on a product that never gets refunded. There are similar problems with using AverageEarningsPerSale.

And then there's another problem with using those values:

The problem here is that the values in the marketplace feed are vendor specific and not product specific. If the average earnings per sale is $10 and the percent commission is 50, we might conclude that the product price is $20. But what is not considered here is that the vendor might sell 3 different products ranging in price from $5 to $40 and he sells a certain amount of each product at 50% commission so that his AverageEarningsPerSale works out to be $10.

Those are just a couple of reasons why the product price can't be determined algebraically like that.

Probably the most reliable way of determining the price of Clickbank products without making any arrangements with Clickbank is to scrape the order form. Programmatically doing this for every vendor of Clickbank's marketplace will probably make Clickbank angry enough to block your IP and I wouldn't advise it.

But if a person were to do such a thing, all that would be needed was the list of Clickbank vendor's (which is in the thousands BTW) and you'd scrape URL's in the following format:

http://x.vendorid.pay.clickbank.net/

... where 'x' is an integer representing a product number and "vendorid" is of course the vendor id which comes from the XML feed from Clickbank.

And all you'd do is scrape that starting with x = 1, then increment x and do it again and again.

That would get all of the product prices in a sort of "get yourself banned by Clickbank" sort of way. I'd discuss it with Clickbank before I'd do anything that.

Steve,

Thanks for that, so what is the right answer then? And surely there must be some additional calculations in regards to figuring recurring billing products.

If you feel better PMing please feel free