Capital One Made Me Different Loan Offers Depending On Which Browser I Used | Hacker News Reader

Capital One Made Me Different Loan Offers Depending On Which Browser I Used

consumerist.com

85 pointsbensummers54 comments

It's either:

  - A random number each time
  - Normal split testing using a cookie
  - Split testing using the user agent rather than a cookie

The last one would, I suppose, be more consistent than using a cookie- after all, most people wouldn't switch browsers, but they might clear their cookies.

That being said, a few companies have gotten in hot water for doing this.

Amazon in 2000: http://news.cnet.com/2100-1017-245631.html

Automattic: http://brianbreslin.com/automattic-caught-ab-testing-pricing... (although they admitted up front they were doing this)

[Edited for readability]

I think it's normal split testing using a normal cookie. Here are the rates I get in Opera (with flash disabled) while clearing cookies between reloads:

    new   used  refinance
    3.10  4.49  4.34
    3.50  5.09  4.84
    2.70  4.09  3.94
    2.30  3.59  3.54

And here's Firefox (with flash enabled) and clearing session cookies between reloads:

    new   used  refinance
    2.70  4.09  3.94
    3.10  4.49  4.34
    2.30  3.59  3.54
    3.50  5.09  4.84

ANOVA agrees with you:

  Source      Sum Sq.   d.f.   Mean Sq.     F      Prob>F 
  -------------------------------------------------------   
  Loan Type    9.6665     2    4.8333     16.47    0.001
  Browser      0          1    0           0       1
  Error        5.8700    20    0.2935
  Total       15.5365    23

I can almost guarantee it's simply a split test using a cookie, as that's the standard way to experiment (using Google Website Optimizer and others). It's a common bracketing experiment.

Edit: To be clear, if it's flash cookies it could persist after browser installs but still be different per browser.

Capital One is famous for experimentation and segmentation based on messaging, response rate, demographic factors, and many other variables. It's how they came out of nowhere in the early 1990s (the founders were consultants who had zero banking or credit card experience) to disrupt the industry, most of which operated on one-size-fits all APRs and risk profiles.

Good point ilamont, I wonder if they have a'users vs risk' load balancer built into the search for the rate. For instance if 100k people tried for the same rate at the same time, would it randomly change the rate to balance the risk?

You also get different loans if you walk into a bank wearing a suit vs. a hoodie.

So which browser is the equivalent of a tuxedo? A suit? A hoodie?

I'm not so sure browser choice is an accurate signal of a person's worth (In this sense, worth could mean anything).

I'd say Safari = black turtleneck.... firefox = hoodie....

actually the chrome figure makes sorta sense. chrome is super early adopters, so likely wealthier purchasers of high-end electronics... dunno completely pulling this outta my A$$ :-)

You can say ass here. We're all adults.

That's an artifact from a past era. Likely from BBSes, gaming or IRC. I think it should come off as the equivalent to a dialect that just provides some insight to the poster. I know when I use it it's usually unintentional and subconscious. And, of course, there is the implication that if you don't like swear words then read it as such and don't be offended.

I remember it being used often in moderated fidonet[1] though that may have been limited to local and regional forums. Also to avoid the swear word filters on BBS chat in the 80s and very early 90s. And in some MMORPGs for the same reason circa 2000 to present.

[1] http://en.wikipedia.org/wiki/FidoNet

Good to know. Didn't want to get down voted purely for saying ass.

Internet Explorer: Commoners.

Firefox: Geeks, Biological relatives of geeks, IT people.

Chrome: Programmers, basement dwellers, hipsters.

I'm not sure either, but wouldn't it be interesting to see the data. Come to think of it, I don't recall seeing articles about conversion rates, customer value, etc based on browser. Could be interesting.

Safari is a hoodie

If anything Safari is the only browser that _could_ be _at all_ indicative of one's financial bracket...

Most browsers send the OS as part of the user agent though, which I'd assume would be a more reliable metric.

It runs on windows too, so it wouldn't be a very good indicator (assuming that you're saying the people who buy macs are more affluent than those who buy pcs).

Still checks out, Safari sends the OS in the UA string;

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.18.1 (KHTML, like Gecko) Version/5.0.2 Safari/533.18.5

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_5; en-US) AppleWebKit/533.18.1 (KHTML, like Gecko) Version/5.0.2 Safari/533.18.5

Which isn't the same as the browser being indicative of it, eh? Especially as other browsers send the OS as well.

IE6 from a non-government email address and/or not during normal corporate business hours = dirty overalls + straw hat

or grandma

s/_/ *

[replace _ with * ]

What is the world coming to, that you have to explain vi commands on HN?

That's technically just a regular expression (perl syntax). The vi equivalent would be

    :%s/_/*/g

Which is, replace all occurrences on all lines of '_' with ' *'

EDIT: Talk about formatting fail...

Isn't that actually ed/sed syntax?

What is the world coming to when a correction has to get 3 levels deep before it's actually correct on HN?

(And you have less points than either of the ones above you? Seriously?)

Indeed, quick memory recall failure on my part. It's ed syntax which bled into everything else via POSIX basic. However, given the limited number of symbols present, identification can be considered ambiguous :).

I actually couldn't get the asterisk to appear without adding text below it, and I didn't have anything else to add. So I just added an explanation.

Don't worry! I didn't feel like I needed to explain. But the formatting on HN is odd, and the rule on how to use asterisks is obscure and bizarre.

  s|s/_/*|  s/_/*|

And since I haven't debugged that regex even if it was legible, add two spaces to the beginning of a line to reproduce text verbatim. (Even if it's on one line.)

I wasn't aware HN actually had formatting, I was just trying to use plaintext for emphasis... Or does it?

Text between asterisks will be in italics.

Can you tell if an iPhone is locked or not from the UA string? Because I'd expect that locked iPhones are exactly the customer you want most: has money and signs long term contracts (whereas an unlocked or jailbroken product might indicate that they'll do extra work to save money -- exactly the customer you don't usually want).

Well.. you could but you would need the IP address also.

You just need to check if the request is coming from a T-Mobile IP, or any other GSM carrier in the USA (http://en.wikipedia.org/wiki/List_of_United_States_wireless_...).

This wouldn't work outside the USA (unless you want to research the carriers) and most people would be connected to wifi.

So, this wouldn't really work. It would be much easier with a BlackBerry as they transmit the vendorID (a type of carrierID) in the UA. You could easily check this with the IP.

Even if it's not "reliable", it could still be a usable heuristic. If there data shows a correlation between Chrome use and dependable loan repayment, who to say they should ignore it?

i can certainly attest to this. thanks for the laugh, best comment i've seen in days.

Unless your name is Mark Zuckerberg, in which case the APR is 0 and the payment plan is in Facebook stock, every single time!

Method behind the madness?

-= ComScore study suggests that FireFox users, while more affluent, also tend to skew considerably younger than your average Internet Explorer user

-= Pair that data with the fact that younger people have lower credit scores, and the lower your credit score, the higher your APR.

-= By showing a prospect a loan rate near to what they will qualify for, Capital One is going to close more business, and not waste resources on non-qualified leads.

VIA - http://conversionvoodoo.com/blog/2010/11/do-different-web-br...

About a year ago I got a quote from Geico.com for car insurance. When I got to the purchase screen, I decided to leave and check prices from other companies. Then I went back to Geico the second time because it turned out they had the best price. To my surprise Geico offered a 15% lower rate the second time! I guess they figured they better wow me to get a conversion the second time around. Pretty great.

I wonder if they're doing browser history sniffing? If I were an evil-finance-company-web-developer, I'd certainly consider attempting to find out which of my competitors websites you've visited recently. Or whether you'd visited any of their (or my) adwords landing pages. Or (with a fair bit more work) whether you'd done any of a selection of specific google searches.

I've been playing with it a bit lately, it works pretty reliably in most of the Firefox 3.6.* browsers, as well as iPhones running 3.1.3 and 4.1, and IE 7 and 8... (Chrome, Safari, and iPads are immune to both the css and javascript sniffing techniques I've tried, but that's not to say there aren't other tricks that work for them...)

http://bigiain.com/csshistorysniffing.html

(apologies in advance if my cheapo hosting and naive and unoptimised perl/cgi proof of concept doesn't stand up to hackernews traffic volumes...)

Just out of curiosity, is there any proof out there that airline companies discriminate based on browser choice?

My thoughts are that since airline companies are the quintessential example of price discrimination they would most likely have such a system in place.

I worked at ITA software for a few years, in the team that wrote the software that searches for airfares.

The prices of seats and their restrictions are published, and the data format predates the web (by a large margin). There's no field for "browser type."

Each seat has about a dozen prices, and the only other way the user sees a price change is by turning a given price on or off. But the protocol that asks whether a given seat is available doesn't have a "browser type" field either.

When you go to an airline's web site, they could presumably use whatever info they want. But if they used the browser while travel agents didn't, they'd either be presenting a lower price than you could get through the agent, or a higher one. It seems unlikely they'd do that, but I suppose it's possible.

so more importantly: how do WE get better prices?

http://matrix.itasoftware.com

That and the flyer talk forums.

This! It's especially good when you have flexible dates, or you want to taylor your search (eg, connect through Dallas rather than Chicago). I've also used other multi-airline search sites (kayak, hipmunk, orbitz etc), but they never have the best price available. It's best to narrow it down to a few of the best options, then go price them directly on the airline's website. It usually works out significantly cheaper.

Not browser choice, but I have personally experienced one country's national airline charging a significantly higher rate when viewing the site in English, compared to the native language.

I would expect this has something to do with the browser and where it indexes the results (pull this rate from) from to start with. As Firefox can deliver results from many search engines, I would love to know if Devin knew what Firefox was searching with at the time, Yahoo/ Bing or Google. If set to Google this could be a fantastic bench test to see what results are actually delivered from both browsers connected to Google.

Same goes for Netflix's streaming only rate - it's either $7.99/month or $8.99/month depending on your browser.

I built something a while back which used several data sources to build a scoring profile of the applicant.

The emergent behaviours were rather interesting, anyone with a .pl tld in their email was several penalised.

The rejection rates for .pl applicants was 100% so the system worked albeit somewhat racistly.

What is the right way to gather this info? Our expectation is that the prices advertised are firm. Is there a way to perform the test without violating expectations?

Using something like an geographic IP lookup would mitigate but not solve.

split testing different offers?

Right, she needs to go back and check the pages again with fresh installs a few times. It may be more or less random.

caponeaf_split=exp1%3DD_exp2%3DD_exp3%3DD_exp4%3DD_exp5%3DD_exp6%3DD_exp7%3DD

Split test cookie

chrome ftw?

Reply on news.ycombinator.com