Skip to main content

Amazon v Amazon

I was reading up a while back about how Amazon (and others) do differential pricing depending on who you are (or who they think you are) including factors such as the type of computer you use. As a very quick test I decided to do two searches...

One (let's call it "open") from my own laptop via my default browser used for everyday activity, logged in to Amazon, full of tracking cookies and history etc....

The other ("closed") from a TOR'ified Linux VM running a clean browser, privoxy and appearing (for now) to be surfacing out of Liberia.

Both searches were for "macbook air" (not that I intend on buying one but they're common and relatively expensive).

Results were pretty much the same, but not quite and the example below shows a difference...

From "open":Open

 

From "closed":Closed

£686 v £669...

So, if proof were needed.... you can't get Amazon Prime in Liberia! (at least not from amazon.co.uk)... Because that's really the only difference. You can still buy the device (new) for £669 on the "open" version, it's just not the "obvious" option.

However, the first item in the "closed" search did suggest purchase via Prime as it did on the "open" version...

Liberia Prime

So there is a difference, but how significant is debatable. It may be a classic diversionary sales tactic - the top item via Prime is more expensive than another via Prime lower in the list but this one (which they want you to buy) is still more expensive than you could have got it for... If they can make you buy that one because you think it's a bargain over the top item then it's a good sale!

Who knows... I'm likely reading too much into this after too many beers... In any case it's largely up to us to be conscious that such behaviour goes on and that we; as human beings, are susceptible to all sorts of strange and suspect sales tactics.

Go search elsewhere, multiple times, from other devices, in Liberia... then save the money instead.

Comments

Popular posts from this blog

An Observation

Much has changed in the past few years, hell, much has changed in the past few weeks, but that’s another story... and I’ve found a little time on my hands in which to tidy things up. The world of non-functionals has never been so important and yet remains irritatingly ignored by so many - in particular by product owners who seem to think NFRs are nothing more than a tech concern. So if your fancy new product collapses when you get get too many users, is that ok? It’s fair that the engineering team should be asking “how many users are we going to get?”,   or “how many failures can we tolerate?” but the only person who can really answer those questions is the product owner.   The dumb answer to these sort of question is “lots!”, or “none!” because at that point you’ve given carte-blanche to the engineering team to over engineer... and that most likely means it’ll take a hell of a lot longer to deliver and/or cost a hell of a lot more to run. The dumb answer is also “only a couple” and “

Inter-microservice Integrity

A central issue in a microservices environment is how to maintain transactional integrity between services. The scenario is fairly simple. Service A performs some operation which persists data and at the same time raises an event or notifies service B of this action. There's a couple of failure scenarios that raise a problem. Firstly, service B could be unavailable. Does service A rollback or unpick the transaction? What if it's already been committed in A? Do you notify the service consumer of a failure and trigger what could be a cascading failure across the entire service network? Or do you accept long term inconsistency between A & B? Secondly, if service B is available but you don't commit in service A before raising the event then you've told B about something that's not committed... What happens if you then try to commit in A and find you can't? Do you now need to have compensating transactions to tell service B "oops, ignore that previous messag

Equifax Data Breach Due to Failure to Install Patches

"the Equifax data compromise was due to their failure to install the security updates provided in a timely manner." Source: MEDIA ALERT: The Apache Software Foundation Confirms Equifax Data Breach Due to Failure to Install Patches Provided for Apache® Struts™ Exploit : The Apache Software Foundation Blog As simple as that apparently. Keep up to date with patching.