

Expedia on how one extra data field can cost $12m  - robin_reala
http://www.silicon.com/management/sales-and-marketing/2010/11/01/expedia-on-how-one-extra-data-field-can-cost-12m-39746554/

======
gaius
To be fair there's _absolutely no frickin' way_ that you could predict that
people would enter their bank in place of their employer.

~~~
staktrace
On the other hand if they weren't trying to gather as much information about
users as they possibly could this wouldn't even have been a problem in the
first place. What possible benefit does an optional "Company" field provide?

~~~
patio11
"It would be great if we knew what percentage of our customers were business
travelers. It would really improve marcomm.". "The web guys say they can ask,
it won't take five minutes.". "Brilliant! Do it. Next order of business..."

Six years later, nobody has checked the form since. After all, that isn't
their job.

------
dmlorenzetti
That $12m/yr might be added revenue, but it's hard to see how it could
represent added profit (as claimed in the article).

Say Expedia earns $200 profit per transaction (total WAG, but intended to
sound high). Then $12e6 means 60,000 people a year - or 165 people a day -
were failing to complete their transactions because they thought "company"
meant "bank name". Similarly, $500 profit per transaction means 66 people a
day were thrown off by an input field that's actually pretty common on the
web. Neither of those seems even vaguely plausible to me.

Take another tack. According to this article
(<http://www.reuters.com/article/idUSTRE69R56X20101028>), Expedia had $177m
net income this past quarter. That's framed as a big jump from the past, but
say they make 4 x $175m or $700m a year. Before this change, they would have
made $688m per year. So 12/688, or 1.7%, of their customers were being thrown
off by the "company" field? I find that hard to believe.

If, on the other hand, that $12m is added revenue, then (taking the article's
$6.89b revenue per quarter figure) we have 0.044% of their customers failing
to complete due to this problem. That sounds a bit more plausible.

------
samd
I don't know what's more surprising, that one small change is worth millions
or that A/B testing is still news to some companies.

~~~
njharman
This wasn't A/B testing. This was fixing UI mistakes based on UX analysis.
There was no 'B'. They weren't comparing A and B.

~~~
CapitalistCartr
In this case, the A/B testing would have been with that field and without.

~~~
pavel_lishin
How would you know which fields to use?

------
wccrawford
It occurs to me that instead of removing the field (which I'm sure people who
used Company credits cards are looking for) they could simply have made it
clear that it was the user's billing address they were looking for, instead of
the bank's.

It might have resulted in more revenue if they had done it my way, since there
may be people on business trips that now think they can't use a company credit
card.

Or not. That's the thing with dealing with the public... Without paying really
close attention to what's really happening and people are saying, you are just
guessing.

~~~
niekmaas
What they should do is a randomized control trial in which they either keep
the field and make its meaning more explicit or get rid of the field at all.

Then they should look at the differences in sales by comparing the two groups.

Nothing wrong with being a bit academic..

~~~
dfox
Problem is, that this field is question is actually useful for some subset of
clients. Making the intent of both "Company" and "billing address" fields is
probably most meaningful way to go, possibly hiding the "Company" field behind
checkbox like "Bill my employer".

------
dcnstrct
For those curious Expedia actually captures a stupendous amount of information
down to session level activity. They can play back failed sessions to discover
areas of opportunity. This was discussed at an analytics conference I attended
on how they implement testing across a range of systems to find possible areas
of friction and improve the business.

------
qjz
Convenience is king and this is an excellent example of how easy it is to go
too far when collecting data from users. I already expect to jump through a
few hoops when using a credit card online, so asking me for my life story will
only encourage me to bail out and never return.

~~~
corin_
You've clearly not comprehended the subject article - I'd suggest reading it
again.

~~~
qjz
I did read the article, and the title says it all. They _lost_ money because
they got greedy for data that was unnecessary to complete the transaction. As
a result, another point of failure was added and frustrated users bailed. The
body of the article may try to spin it as a case where analytics boosted the
bottom line, but the truth is that it was a bad design choice that _cost_ them
money from the start, because they ignored the KISS principle.

~~~
corin_
According to the article the sales they lose were due to customers who didn't
understand the form and therefore filled in the wrong information, not because
people couldn't be bother to provide the data.

------
afterburner
I wonder what the percentage was of customers who made that mistake and then
corrected it in a second try. The increase in sales after correcting the
problem implies there were plenty who didn't, but how many were stubborn
enough to try again after making the bank mistake?

------
aresant
Don't forget Amazon's $300,000,000 button:

<http://www.uie.com/articles/three_hund_million_button/>

------
al_james
Now, if only they fix all the other issues on their site. I tried twice at the
weekend to make a booking and the whole convoluted process simply did not work
(saying there is errors on the form even if there was not etc...).

------
jwcacces
Confusing customers costs money: news at 11

------
known
While designing the database, it is better to have a _notes_ column in every
table so that we can use it in future without changing the schema and breaking
the application.

~~~
kprobst
Wow... seriously?

~~~
epochwolf
Why not? I'm a big proponent of the SQL K-X model. You have two text fields in
each table: key and xml. The flexibility of this model is incredible.

