Issues with international pricing

Why use two or even more currencies? Just give the price in US $. With
the use of creditcards its the same for everybody and rates do not
influence prices.

Best regards, Piet-Jan.

On 30.05.2007, at 17:33, Adam C. Engst wrote:

> 1) Charge $29.99 for US customers and 29.99 euros for EU customers.
> The downside of this is that EU customers could be annoyed at paying
> more than US customers due to the exchange rate, and some percentage
> wouldn't purchase because of that.

I am pretty sure that the percentage would be not small. Chances are
also that European consumer taxes have to be added to that which e.g.
in Germany are 19%. OTOH, as long as you do not add the software to
your tax file, you may not have to pay them :-)

In the case of boxed software etc., shipping/handling has to be counted
in.

> 2) Charge $29.99 for US customers and 22 euros for EU customers, so
> the price is the same, regardless of currency. The downside of this
> is that if sales to EU customers would be roughly the same as if the
> price were 30 euros, that would mean leaving 8 euros ($10.84) on the
> table for each sale to an EU customer.

This is what I would suggest, despite the virtual loss. When there
really
is a market in Europe, then treating EU customers equal at least on the
pricing sounds right. One has to consider that Non-US users may find
multiple small annoyances with the software itself -- e.g. unusable
keyboard shortcuts (command-[) etc.

> 3) Charge 29.99 euros for EU customers and $40.64 for US customers,
> again keeping the price the same, regardless of currency. The
> downside of this is that some percentage of US customers might see
> the $40.64 (either advertised up front or in a currency conversion in
> a cart), think it was too high, and not purchase.

Despite the possible EU market, I suspect that the US market will be
central to the sales, which would forbid this approach.

BTW, I am in the EU (Germany), but fortunate to have the opportunity
to also shop in the US and Japan :-) And I think that this has indeed
affected my answer...

Cheers, Kei.

1) I've got to say, I think that there is something distasteful about
charging different amounts in different comparable markets. (Charging
less in less developed economies/markets is a different issue.) But I
don't think that it is a rational objection, on my part. Currencies
fluctuate against each other far more rapidly than their local
purchasing power changes. I think that the most rationale answer
would be to price them equivalently, in terms of local purchasing
power, rather than in terms of exchange rate. Of course, this would
lead to those of us living in New York City paying more than people
in Tulsa. And that FEELS distasteful.

On the other hand, I have NO problem with charging more for the
other market to adjust for the seller's own cost to convert
currency to to his/her own local currency. That does NOT feel
distasteful to me. So, a difference in price is fine to me, if it is
explained by a difference in cost to the seller.

2) That leaves the question of whether the base price (29.99) should
be in Euros or Dollars.

(I think that Adam's description of these two choices is not quite
right. It's the same advantages and disadvantages for each one.
Higher prices will reduce sales and lower prices will potentially
leaves money on the table.)

I think that there is a rationale answer here, and it doesn't have to
be 29.99 in EITHER market. The software publisher believes that that
profit will be maximized in each market at 29.99. So, there's some
kind of function (however poorly defined and/or researched) of profit
in his/her head that peaks at a price of 29.99. Well, add the two
functions and choose the peak. The ideal point could well be 24.99 in
Europe and 32.99 in the US.

That is, if s/he can't have 29.99 in both (and I am against that),
s/he can compromise. That is, neither get's the ideal price for that
market, but the publisher sets the ideal price overall.

3) Generally, I don't think that Adam's question is answerable
without knowing how much sales might drop off in in the US with a
higher price, how much profit s/he makes on each sales, how much
costs need to be recouped, etc.

That is, there is a moral and/or ethical question about charging two
very different prices in two economically similar markets with
different currencies. And if the answer there is NOT to do that, it
becomes a math/econ problem with projected sales curves for each
market v. price, marginal profit v. sales curves, etc..

4) Moreover, if the publisher wants to constrain the problem by
insisting that one of the prices MUST be 29.99, it's a much easier
calculation, though it still requires more information than Adam gave
us. Which one would lead to the most profit for the publisher?

(That assumes that the publisher's goal is to maximize profit, which
I am inferring from Adam's post. If there is another goal, there
might be a different answer.)

--
=Alex Hoffman
Leadership Policy & Politics
Teachers College, Columbia University

On 30-May-2007, at 09:33, Adam C. Engst wrote:
> What do you think is the best approach, and why? Is there another
> alternative, or something that's not being taken into account? And
> please also state if you're from the EU or the US, and how that
> affects your answer.

I am from the US, and I have no idea how that affects my answer.

There are certain psychological breaks in money. There's one at 99¢,
perhaps the most notable one, in fact, since it populates itself up
the price pyramid (most people when they see a price of 12.99 do, in
fact, think 12, not 13).

There is another one at 9.99, 19.99 and 49.99. All of these price
points represent a different attitude on the part of the buyer. 99¢
is nothing, and is seen as a purely impulse driven purchase. If you
want it, need it, might use it, well, it's only 99¢. This is part of
the reason for the iTunes store's success.

9.99 and 19.99 both represent slightly more thought and slightly less
impulse than the previous level. Between 20.00 and 49.99 there is
not a lot of difference with regards to how much time someone puts
into thinking about the purchase and if it is worth it.<1> There is
a reason that video games have spent 20 years hovering at US$49.99 (I
bought Ultima *mumble* in 1980*mumble* for US$49.99) and have only
recently 'broken' that barrier.

So, on that score, trying to hit a target price of '30' somethings is
probably not the best idea. I would think long and hard about
setting the target price at '19.99' somethings and going from there.

Now, that said, I think what you do is you pick your currency, and
then you go from there. How are you likely to receive the majority
of your payments, in € or US$? are you going to have separate
accounts for the currencies, or are you going to be getting charged
by your bank for each 'conversion'?

If I were going to price something at €19.99 I would not set the US
price at US$26.91, but rather at US$29.99, representing the added
cost of dealing with two currencies and deducing that there is
effectively NO DIFFERENCE between US$26.91 and US$29.99 in the
likelihood of a person purchasing or not. (it's about 10%)

Likewise, if I set my pricepoint at US$19.99, I would not put the
Euro price at €14.85, but would probably put it at €15.99. (again,
about 10% more than the pure conversion).

This gives me a bit of wiggle room when currency rates change, as
they are wont to do, and also gives me a little extra cash to manage
dealing with two currencies.

Now, I can use my credit card (US$) and make a purchase on a € site
and my credit card will handle the conversion for me, so if the
difference in price is too great, and you're not 'authenticating' the
currency choice by, say, shipping a product, then I will use
whichever currency gives me the better deal. For a small purchase
like 20 somethings though, it's not going to be worth the hassle
unless it's a really big difference in price.

But, to answer the specific question, if I really felt that 30-
somethings was the right price point then, for Euros I'd set the US$
purchase at $39.99 (violating everything I said previously because I
feel that going above the $40 mark would likely hurt me more than the
'lost' $1.40-$5 of pricing the US$ at $40.38-$44.99) and if priced at
$29.99 I'd probably got to €19.99 or €24.99. '30' is a problematic
price point with the current exchange rate.

<1> this is not to say that an item priced at 22.00 would sell just
as well at 49.99, of course that's not the case. The point is that
the amount of time evaluating a purchase and making a decision is
proportional to the price, but not DIRECTLY proportional. There's no
difference in the amount of though put into evaluation in these sorts
of ranges. People buying a house for $200,000 spend pretty much
exactly the amount of time on evaluation as people buying a $800,000
house.

Hello Adam,

I'm currently going through a similar issue though with AUD instead of
USD, as I'm trying to set up a small export business to Australia from
my home in France. (Shameless plug for the new biz :
http://alafrog.com, check it out if you have a moment.)

The first issue is one of image, it looks strange if the company or
developer is based in the US and he sets the base price of his product
in a currency other USD. (Or EUR if he's in the EU).

The other issue is that currency valuations are not immutable, by a
long shot - as I can certainly attest having moved to Paris from San
Diego in April 2002, only to see the USD lose roughly 50% of it's
value in reference to the EUR under Bush's stewardship. (One EUR was
worth roughly $0.89 in April 2002 and is now worth $1.34.)

So, probably the wisest course of action is to price the product in
one currency and provide currency conversion calculators so people can
determine, prior to purchase, what the amount equates to in their
currency of reference. As long as the developer is accepting credit
card payments, the banks will handle the rest.

If he does decide for whatever reason that he needs to offer the
product in both currencies, he should be aware that he will lose
plausible deniability with regard to EU VAT tax which should be
charged on electronic purchases by EU residents, but of course, that's
a whole other topic.

If he does decide to offer it in two currencies there's no reason he
can't take a half-measure, such as offering the product at $29.99 and
25€. While not exactly the same absolute price, it's close enough not
to be shockingly more expensive. Ah, that brings up another point,
whereas -.99 pricing is common in the US and in the UK, it's nearly
unhead of in France and Italy, both countries that had 'weak'
currencies in the past, here 1049.98 just looks like a ridiculous
number, just charge 1050 and be done with it. In the EU 'cents'
generally aren't included in prices unless they are something other
than 00 and it looks strange to us when they are included.

Christopher Appell
European Market
SpecialtyJobMarkets.com
JobMart.com

Adam,

I live in Turkey, so I deal with 3 prices!

My suggestion is to price the item for where the developer either lives, or where he expects the most sales and let exchange rates determine the price in other currencies. That means that either Pay Pal or credit cards can be used to pay for the item.

The other suggestion is to set up two web sites, and using the incoming ISP, route the request to the site, where pricing is fixed at the level determined by the developer. This of course has the real potential to make the party paying more very upset.

But the suggestion that the developer is "leaving money on the table" if he charges the same numbers in both dollars and euros, then he may be making a mistake. If he feels that his development costs can be accommodated by charging $29.95, then he should be "happy" getting 22 euros (or visa versa.)

Here, my credit card accepts 3 currencies: local, euro, and dollars. The bank does NOT perform the exchange rate. If my bill for the month contains local currency and dollars, then the bank expects me to either come to the window and pay the bill using both currencies, or, at my option, will calculate the exchange rate at the time that I am paying my bill and then I can pay the entire bill in the local currency.

Lee

Seems to me that the product should have a certain "value" and that the developer should set a price that reflects that... in the currency of each particular market.

R. Reinking

At work we struggle with this problem all the time. We definitely see more
orders when we offer a native currency to our customers than if we only
offer a foreign currency. (e.g. Offering Euros to Germans results in more
sales from Germany than if we only priced things in US$)

Additionally, there are real costs associated with handling multiple
currencies. Assuming that the seller settles out his own account in US
dollars, then he will have to pay a currency conversion fee to transfer his
Euro sales into dollars.

Contrarily, if the seller just lets the credit card companies settle it all
out and prices his product only in his native dollars, then he's passing
this conversion fee on to the buyer -- the credit card companies charge a
small conversion fee for all foreign currency transactions.

Luckily, a number of the available payment processing services such as
PayPal and Google Checkout offer very low conversion fees on either end of
the transaction. So one thing that a seller can do is make use of these
services to reduce fees. That's a good start.

As for what price to set, prices send a message. There's a reason why 29.99
is a more popular price point than, say, 22.28 (the strict conversion from
dollars to euros). Conversion rates also fluctuate, which is another reason
to not just shoot for "the same price in Euros".

Instead, I think the happy medium is to shoot for a comparable price that
takes into account the actual fees involved. If you're passing the
conversion costs on to your customers, you may want to give them a price
break and round down the converted cost. If you're enduring the cost
yourself, that might justify rounding up.

Then you can end up with a price that "feels good" and is also as fair as
you can get it. And, of course, you can always hold sales and otherwise
offer discounts to test lower pricing and see how that affects overall
sales. Pricing is, and always has been, as much of an art as a science.

So given the $29.99 software example, I think I'd probably shoot for €24.99
and shoulder the conversion costs myself. The difference of about €2 is only
going to scare away the most penny-pinching purchaser.

--
Nik :: gerberinik.net
Software picks, serious Mac geekery and productivity tips!
<http://iNik.net/>

--On 5/30/2007 8:33 AM -0700 Adam C. Engst wrote:

> Imagine a developer who anticipates major markets in the EU and the
> US. Let's further posit that, for this developer's product, it's
> important to keep the raw price, regardless of currency, under 30.

I think this assumption is the problem. While there may be psychological
effects of a round number, it's not reasonable to think that the same round
number will mean the same things in different currencies.

The Japanese yen, for example, is over 100 to the dollar--to assume that
there's any meaningful way in which a price of "30 yen" sends the same
signal as a price of "30 dollars" is absurd.

Just because the base values of the Euro and the dollar aren't an order of
magnitude different doesn't mean that the price signals are at the same
place. (I would guess that, psychologically, $30 and 25 Euros "mean" about
the same thing to the potential buyer.)


There are two reasonable solutions I see:

(1) If it's feasible, and if payment/delivery will be electronic over the
Internet, then choose the seller's local currency, state the price in that,
and leave the conversion to the credit card companies.

(2) If it's for physical retail sale, or if payment plans are in place to
take different local currencies, choose relatively round numbers (or
fractions below them) that are roughly comparable.

So in the example, sell the product for:

 $29.99 US dollars
  21.99 Euros
  14.99 British pounds
   3000 Yen
    300 Pesos

each of which is at or near a round price point and for which we can
reasonably guess that the price points have the same approximate "meaning".

(This email would be much prettier if I were typing it on my Mac, where the
currency symbols are easier to find and remember. On Windows, I can't be
bothered with figuring out the four-digit codes necessary to get the
characters.)

Dave


 

reinking wrote:
> Seems to me that the product should have a certain "value" and that the developer should set a price that reflects that... in the currency of each particular market.

Major companies (HP, IBM, etc.) price in US-dollars. Sales in other
countries are translated by order-entry software in the country of the
sale to that country's currency, and in addition, take into account such
issues as "rounding" (rounding up, rounding down, rounding off). To
simplify the entire issue, the price is the price, in the currency of
origin, and either credit processing networks or order-entry software
should (and do) cover pricing differences. In addition, credit
processing also is often timed to take advantage of currency equivalent
differences due to floating changes in exchange rates. Again, this
should have no bearing on setting the price.

A secondary consideration, in actual practice, has to do with the
primary market of sales: many European, Asian, or Australian products in
software and hardware are sold principally in the US, and marketing
material as seen in the US bears US prices.

The short end of this is that a product should have a single price, and
currency differences as presently understood should govern the price in
other countries. All one has to do, in any country, is look at the
various markets.


Bob Perrey

On 31-May-2007, at 09:15, Christophe Appell wrote:
> Ah, that brings up another point,
> whereas -.99 pricing is common in the US and in the UK, it's nearly
> unhead of in France and Italy, both countries that had 'weak'
> currencies in the past, here 1049.98 just looks like a ridiculous
> number, just charge 1050 and be done with it. In the EU 'cents'
> generally aren't included in prices unless they are something other
> than 00 and it looks strange to us when they are included.

Ah, now that is a good point and I have to admit I hadn't noticed
it. However, you're quite right, looking at € based sites the prices
are, by and large, even amounts. Something else to think about.

Don't worry, the .99 will get to you too, eventually :)

On 5/30/07 at 8:33 AM, acetidbits.com (Adam C. Engst) wrote:

>Every so often I end up being asked by a developer about the "best"
>way to price a software product, where "best" involves finding the
>sweet spot between maximum revenues for the developer and fairness
>for customers in both the US and EU.

Really, the only criteria is maximum revenue. Customers who
don't consider the price fair simply won't buy. Or if they do,
very likely will complain on some internet forum. Either way,
unfair pricing will hurt revenue.

>1) Charge $29.99 for US customers and 29.99 euros for EU customers.
>The downside of this is that EU customers could be annoyed at paying
>more than US customers due to the exchange rate, and some percentage
>wouldn't purchase because of that.

>2) Charge $29.99 for US customers and 22 euros for EU customers, so
>the price is the same, regardless of currency. The downside of this
>is that if sales to EU customers would be roughly the same as if the
>price were 30 euros, that would mean leaving 8 euros ($10.84) on the
>table for each sale to an EU customer.

>3) Charge 29.99 euros for EU customers and $40.64 for US customers,
>again keeping the price the same, regardless of currency. The
>downside of this is that some percentage of US customers might see
>the $40.64 (either advertised up front or in a currency conversion
>in a cart), think it was too high, and not purchase.

The downside to all three of your scenarios is some fraction of
potential customers won't buy. So, the rational decision is to
estimate which scenario has the least impact on revenue and
select it. If there is no basis for making an estimate on
revenue impact, then I would choose the simplest approach which
seems to me to be 1).

Google Kreme wrote:
> On 31-May-2007, at 09:15, Christophe Appell wrote:
>> Ah, that brings up another point,
>> whereas -.99 pricing is common in the US and in the UK, it's nearly
>> unhead of in France and Italy, both countries that had 'weak'
>> currencies in the past, here 1049.98 just looks like a ridiculous
>> number, just charge 1050 and be done with it. In the EU 'cents'
>> generally aren't included in prices unless they are something other
>> than 00 and it looks strange to us when they are included.
>
> Ah, now that is a good point and I have to admit I hadn't noticed
> it. However, you're quite right, looking at € based sites the
> pricesare, by and large, even amounts. Something else to think about.
>
> Don't worry, the .99 will get to you too, eventually :)
>
>
And then they can get all those crazy .97 means a sale price, .96 is a clearance price, etc... which clues sales staff into which prices are negotiable and which are not and which items cannot be back ordered and so on. All hold overs from the days prior to decent computerized inventory management systems.

Thanks for all the opinions and data, folks. Next time someone asks
me about this sort of sticky pricing issue, I'll not only have a
more-informed opinion, I'll be able to point them to this thread.

cheers... -Adam