top of page
Writer's pictureRaquell Silva

How frequently should you web scrape?

Updated: Oct 5



Understanding how often a web scraping should be done for a project, can save the project and company money in the long term. We know how useful a web scraping is for obtaining actionable information and how valuable data mining is. Analysing collected data can take hours, and the conclusions – while valuable – done too frequently can pressure a budget. 

However, not scraping often enough can leave gaps in information when some projects need to keep an eye on data that changes more frequently. In order to achieve the appropriate frequency to web scrape for a project, three things need to be taken into consideration:


  • The nature of the data you extract from a web scraping.

  • The time it takes to analyse and process the data.

  • The cost and the circumstances that affect and are affected by the costs.


With these points in mind, here is what can help you determine is the right frequency to implement a web scraping project without breaking the budget, or wasting time.


What is my data telling me?


Before starting any web scraping, understanding the type of data expected to be extracted from a web page in the pre-project phase, can map out the best scraping schedule for any project. There are three factors that affects the frequency needed to web scrape in a project. 


  • Knowing what the end-goal of the project, and why you need this data.

  • The data’s volatility, or how often the data on the website changes.

  • The relevance windows – how long the extracted data is useful within a set timeframe.


These factors come into play when you examine the industries that typically have a web scraping project. 


For example, in the real estate industry, realtors would want to keep an eye on property prices, and to be as up-to-date as possible to allow for quick and reliable action. From a web scraping, they would examine property and consumer data to best follow housing trends and see changes near daily. This also occurs in the financial industry, where information – like stocks – is updated daily and is relevant for such a small window. In these cases, these would be highly complex web scraping projects, and demand a closer examination of the data in a short amount of time.


When broken down, a project’s complexity is determined by considering the specific needs that project has and the data surrounding it. A project’s complexity directly relates to the scraping frequency, because of how much the data needs to be scrutinized.


Different Industries need different approaches


Some industries don’t deal with data as volatile as the real estate or financial industry and require a lighter approach. Businesses in the retail industry can aim to obtain competitor information, and customer data, but would rather scrape during intervals following seasonal changes instead. Performing web scraping for daily data extraction would be rather costly and a poor use of resources.


There are some circumstances where after an initial data scraping can inform a project to recalibrate their approach. One likely example that can happen in the hotel industry: after an initial web scraping, a hotel is looking into hotel price fluctuations in a city. Their scraping project originally thinks daily scraping would best suit their needs, but after the first few scrapes, hotel pricing fluctuated wildly each week – likely from holiday or special promotions, or weekend rates. Rather than exhausting resources paying daily scraping costs, the project changes to a weekly approach, maximizing scraping efficiency.


Understanding the complexity of the data from a web scraping project is a significant indicator of how frequent web scraping should be done. Web scraping itself however, is just the first part of puzzling out a proper frequency to calibrate for each project – analysing that data will also take time.


Data gathering and analysis takes time


The time it takes to gather the data, and the time it takes to compile and analyse that data greatly affects a web scraping project’s frequency. Because web scraping itself can take from minutes to days or sometimes even longer, depending on the amount and type of data being gathered, it can greatly impact a project’s schedule and costs. 


Businesses and projects should take care in considering the gathering and processing time involved with a web scraping, and to adjust if either process takes longer than planned.  Knowing the type of data being gathered can greatly mitigate any lengthy schedule, and allows for scraping projects flexibility to adjust.


Let’s look at an example of an e-commerce consulting firm scraping product data daily. They’re hoping to get data about online marketplaces and identify emerging trends for client strategies, but they found that a full cycle of gathering and analysis took three days. The data scraping, cleaning and then report generation took so long that by the third day, the relevant data became outdated while the data was processing. 


The appropriate strategy would be to switch to a weekly or bi-weekly scraping for more timely reports – significant trends don’t often change daily, allowing for a longer schedule for best results.



Costs and their implications


The last factor to examine, but certainly not the least, is managing and understanding the cost involved with the frequency of a web scraping project. These costs include the number of resources gained and managed, and the overall complexity of the scraping project.

A higher frequency of scraping can result in increased costs to store, process and maintain proxy services – if planning to avoid IP bans from excessive scraping. Additionally, the more complex a project is, the more expensive it will be overall. 


Let’s use an example where a web scraping project is looking into flight ticket prices and data.


  1. A project with “simple” levels of complexity can involve monitoring a travel booking website over the course of a week, while looking for a specific flight or ticket. 


  2. A “standard complexity” project would increase that flight itinerary multiple times a day to gather pricing data as well.


  3. A “complex project” will add searching through the entire website, accumulating data for hundreds of different flight itineraries at an hourly rate.


  4. A “super hard/complex project” takes another step, and investigates many travel sites at once, comparing pricing data for thousands of flight itineraries. This process would take longer, and is limited to the number of websites that allow scraping and on the project’s schedule and budget.

 

According to a Ficstar post by William He, web scraping can be done personally with a little programming experience, or by using a free tool – these often have paid plans to provide more techniques or tools. Projects with larger budgets can invest in paid apps, programs, or freelancers to handle more data and analyses, as well as provide more insights to the data itself. As the project complexity increases, an enterprise-level web scraping service provider is recommended. 


Finding the right frequency for you


Your web scraping project should scrape as often as it can effectively gain, review, and use the data. This is different for each project, and is subject to the needs and resources unique to each project, but ultimately doing any web scraping is better than not doing any at all. 

Deciding on the right frequency that matches your web scraping project is simple to achieve. With careful observation of the type of data you’re looking for, and attention to detail – the costs, resources and processing times – your web scraping project will produce the best results. 


It is important to see expert advice, should a project’s outline or schedule seem difficult to choose the correct frequency of web scraping. Seeking out consulting specialists in the industry such as Ficstar can be beneficial in avoiding or mitigating mistakes. Reaching out with inquiries and questions is the best way to launch a project with a strong start. 



 


0 views0 comments

Recent Posts

See All
bottom of page