- 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.
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
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?
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$$ :-)
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.
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.
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).
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 :).
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.)
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).
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?
-= 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.
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...)
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.
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.
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.
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]