Why You Should Use APIs To Build Your Own Price Tracking Engine
How much does any given eCommerce item cost? The answer now might be quite different from the answer in a few minutes, particularly at this time of year (with seasonal traffic overwhelming stores and spurring further competition). Online pricing oscillates at a much faster pace than it ever could (or needed to) when brick-and-mortar retail was the norm.
Back in those prices, price labels had to be updated manually (and slowly) — and since a middling price payable immediately was often preferable to a cheap price offered following a further journey, retailers weren’t under a lot of pressure to make minor tweaks to their prices. Today, seller demands are very different, and a flash sale can change the game.
To keep up with all the fluctuations (something that’s important for understanding demand and keeping profit margins optimized), many eCommerce businesses now use price tracking engines that regularly poll stores and data aggregators across the web. If you want to do the same, you could use one such engine — or you could create one.
Using well-established APIs (like Amazon’s), you can develop a price tracking engine to meet your unique criteria. Why should you go to that effort? Allow me to offer some key reasons:
You can achieve supreme customization
Let’s say you decided to use an existing solution to track product prices: it would get you a lot of useful information, but it would be limited by the provided parameters (more on that later) and it wouldn’t offer any exclusivity. By developing your own unique solution, you can protect your methods and yield results that others can’t easily mirror.
I don’t mean that it’s possible to gain access to fields that others can’t see — instead, I’m talking about your process. How often do you scan the sites? What times of the day are best? Do you bring in any data about trends? What do you do with the data once it’s done? It may well be possible to export the data from a ready-made solution and do something interesting in post-processing, but it wouldn’t be ideal.
When you build your own engine, you can configure it however you like, turning it into something notably different from anything else on the market. A good point of comparison would be the financial world in which being slightly faster than your competition can make all the difference. If you design a solution that’s faster than those your rivals use, it will really help.
It can be expanded into a dynamic pricing system
The main use of a price tacking engine is tweaking pricing to keep up with the competition, and (as noted earlier) it’s a frustrating thing to do manually — so why not automate it? If you have an eCommerce store, you can use a dynamic pricing system to draw from the tracked data to update your prices automatically.
Just as there are APIs for tracking prices, there are APIs for changing them: provided your store runs on a modern CMS, you should be able to find something to work with. Again, the advantage concerns integration. Instead of tacking something to someone else’s solution, you can extend yours at the source, which should result in superior turnaround time.
Imagine almost all of the stores in your industry updating their prices around the same time, only for your price to update almost instantly and undercut theirs very slightly. That advantage alone could boost your rankings in the shopping searches, and significantly improve your conversions.
You might be able to sell the end result
One of the biggest reasons to commit a lot of time and effort to a development project is that there’s a lot of value in the resulting work, and you can redeem that value by selling it (or, in principle, licensing it). I’ve mentioned how an eCommerce seller can benefit from having a strong price tracking, and benefit further still from a dynamic pricing system (though there are some downsides), so you could certainly convince some ambitious retailers to invest in.
You would need to achieve an outstanding level of quality, of course, but you’d get it up and running before shopping it around, so you could simply view it as a useful experiment if it didn’t pan out. If you did manage to sell it, you could then pick up some additional work (potentially with multiple brands) providing ongoing support and configuration. It could be quite lucrative.
It’s a practical and educational project
For the reasons we’ve already looked at, building a price tracking engine is very practical. Whether you’re just looking for insight into the online marketplace, actively participating in it, or even just trying to save yourself money on Amazon orders, you can use the data gleaned from your engine to great effect. In the end, if you make it great, you can sell it and make a tidy profit.
In addition to that, though, it’s very educational (particularly if you’re a self-taught programmer). Not only will it improve your skills using the appropriate APIs (and using APIs in general), but it will also bolster your understanding of how online business works and how retailers use elements of psychology when setting their prices. Even if your focus is mostly on coding, there’s still value in broadening your horizons.
How to build a tracking engine
Having been through various reasons to build a price tracking engine, it’s worth running through the steps you need to take to achieve it — so let’s do just that:
- Develop the data scraper. This part will constitute the bulk of the work. You’ll need to decide which brands, websites and prices you want to track, then write the code (or use existing library code) to formally define them. You can likely use existing APIs for most of them, but if you want to scrape data from places that don’t have any — and you’re comfortable with the project — you can create your own.
- Allocate the storage space. If you’re going to collect the data, you should store it for quite a while, allowing you to infer trends. The type of storage is up to you, though you should obviously use a cloud solution to ensure you can access it from anywhere.
- Create the monitoring routine. Now that you have your price tracking routines, you need to decide when to deploy them. How often should they activate? Do you want to check pricing daily, weekly, or monthly? Are certain products more important than others? Keep system limitations in mind when you do this, because you don’t want to make requests too often and start seeing them rejected.
- Build a front-end UI (optional). If you have a very specific purpose in mind, or you’re just most comfortable using command lines, then you needn’t bother with this — but if you want general ease of use (and particularly if you might want to sell your engine) then you should build a front-end UI allowing options like frequency to be set.
Wrapping up, then, we’ve looked at the following reasons for building a price tracking engine using APIs: you can go in a unique direction, easily flesh it out into a dynamic pricing system, potentially sell the result, and learn a lot in the process. Alongside all of that, it should be quite a fun project. There’s plenty of room to try different things, but the fundamentals are all well-documented by now. Why not give it a try?
Kayleigh Alexandra is a writer from Micro Startups, your online destination for everything startup. Micro Startups is dedicated to spreading the word about hard-working solopreneurs and SMEs making waves in the business world. Visit the blog for your latest dose of startup, entrepreneur, and charity insights from top experts around the globe @getmicrostarted.
By purchasing some ready made API, like Amazon’s, don’t I get a huge database of products that would include old prices too? Is this possible with self made API?