Users hate out-of-date prices. Why should you compromise?
An increasing share of e-commerce is being funneled through affiliate portals. This basically means that you’re more likely to buy a product after viewing it on a different site rather than on the original retailer’s portal.
Why? This is because of the evolving nature of e-commerce, and a focus on product discovery and curation, rather than just offering a plethora of choice and lowest price.
We wrote an article recently about the changing shopping habits of millennials — who don’t demand more choices, but demand choices that fit their unique profiles
In this increasingly larger niche, competitive advantage goes not to the retail channel that offers the lowest price or the widest selection, but to the retailer that best anticipates what its target demographic would be attracted by and curates its store selection accordingly.
This offers tremendous advantages to affiliate sales start-ups that offer product and content curation layering on top of product feeds, affiliate networks and product APIs.
There is, however, a caveat to all of this — price freshness.
Users hate nothing more than seeing a great deal on something that has piqued their interest, only to see that the actual price is different from the one that they eyeballed. This can be frustrating, infuriating, and even worse, destroys confidence in the retailer that powered this deal.
Product databases have an inherent flaw — there will always be a time lag between when a product’s price changes, when that price is updated in the database, and when the customer application loads the updated data. It’s not a perfect system, but it works fantastically well on a broad statistical level.
Unfortunately, in spot instances when a user checks for price, this system might not do so well, and can occasionally show price lag.
At Semantics3, we have deployed massive engineering resources in building more highly advanced crawlers, and intelligent optimizations on price refreshes — we even work one-on-one with our customers to define, optimize and target price refreshes on products based on categories, sites, or site pages.
But sometimes that just doesn’t cut it.
When you’ve tackled 99% of the issue, sometimes, you need a fine brush to paint over the final1%. This is where the RealTime price API comes in.
The Semantics RealTime is designed to get you as live a price as possible:
Here’s an example:
As you can see, the RealTime API focusses on the fields that are most likely to change frequently — price, availability and all the current offers
There are trade-offs to consider when using RealTime:
- RealTime works by performing a live crawl of the product page while fetching prices. This means that on our backend, a browser window is opened, the product page is loaded, crawled, normalized and sent back to you as structured data.
- This means that this process is much slower than if you’re using the Product API — this is because the data is not cached on our database before being sent to you. This is the price of having live prices (pun intended).
- Having a RealTime price API running constantly means that your app is likely to be slower than if you’re just using our Product API.
There are a couple of ways to optimally use RealTime:
- Put the power back in your users’ hands: Instead of showing them live prices, show a timestamp next to your product’s price. This lets the user know that the price is not live.
- Have a button to “check live prices” — this is a similar strategy adopted by flight comparison sites like Kayak and Skyscanner, that allows them to have a relatively quick page load time, without sacrificing too much price freshness.
- Work with us to optimize product refresh times — our database is so large that its hard to choose which products to refresh first. Helping us identify niches, categories or groups of products to prioritize for price updates help us to help you keep your prices fresh.
Don’t lose your users’ trust by showing old prices. Keep up to date with the RealTime API.