You describe the slice you need - the full catalogue from the OCFIGIG PDP sitemap shards, categories such as Kodinkoneet (home appliances), Puhelimet, tabletit ja älykellot (phones, tablets and smartwatches) or TV, ääni ja älykoti (TV, audio and smart home), a brand, or an existing SKU list of Tuotenumero values - and we build the crawler around it. Delivery is CSV, JSON, XLSX, a Google Sheet or a REST API, with the schema agreed before the first full run. Runs are scheduled at whatever cadence the work needs, from a monthly catalogue snapshot to several passes a day over a price-sensitive subset. Every delivery carries a run timestamp and a diff against the previous one, so downstream systems load only what changed. We monitor the crawlers and repair them when the site moves under them.
Identity comes first, because the rest of the record hangs off it. Every PDP carries schema.org Product JSON-LD, so the machine-readable identifiers are present before any HTML parsing starts.
Store records form a second table: 27 pages under /store/, each with street address, postcode, an eight-day opening-hours grid and the services on offer - Varaa ja Nouda (reserve and collect), Nouto myymälästä (collect from store), Outlet, Kierrätyspiste (recycling point) and the Epoq-keittiöpiste (Epoq kitchen point).
A single crawl is a snapshot of a catalogue that keeps moving. Gigantti states that online and store availability refreshes every 15 minutes, and price and stock are fetched per SKU after the page renders, so the useful object is the series rather than the reading. Scheduled runs record the date a product first appeared in a category, the date it stopped appearing, and every step between the two.
Discount tracking is where the repetition pays. The Omnibus line "Alin 30 pv hinta ennen kampanjaa" only means something next to a price history you collected yourself: with a series you can see whether the reference figure moves before a Kampanja starts, how long a SÄÄSTÄ offer runs, and whether a limited batch note such as "500 kpl kokonaiserä" is followed by a return to the old level.
Stock behaviour is the second signal. onlineStock, storesWithStockCount and availableForCollectAtStoreCount move independently, so repeat runs expose restocks, regional shortages and the point where a line turns isDiscontinued rather than simply selling out. Products that drop out of the PDP sitemap between runs are marked as delisted instead of disappearing quietly, which keeps a long-running feed honest about what left the range.
Gigantti is the Finnish operation of Elkjøp Nordic, the group that trades as Elgiganten in Sweden and Denmark and as Elkjøp in Norway, and that sits under Currys plc. For data work the identifier is what matters. Every product URL ends in a six or seven digit article number, as in /product/{category}/{subcategory}/{slug}/825090, and the same value is printed on the page as "Tuotenumero: 825090" (product number: 825090). The slug ahead of it can be rewritten without breaking the record, so the article number is the only part worth keying on. It is also shared across the group: 825090 on gigantti.fi and 825090 on elgiganten.se describe the same unit, which turns Nordic price comparison into a join on SKU rather than a fuzzy title match.
The storefront is Next.js App Router on Vercel. There is no __NEXT_DATA__ blob to read: page state streams as React Server Component flight payloads pushed into self.__next_f, and client navigation prefetches through ?_rsc= URLs that robots.txt disallows. Category and search listings are Algolia-backed, with a signed key issued at runtime and facets encoded as numeric attribute ids in the query string. Price, stock and scarcity text are re-fetched per SKU after the page renders, so a plain HTML grab can carry a figure the shop no longer shows. The locale is fixed: fi-FI, EUR, no hreflang, no language switcher.
Get a Quote
Developers
Customers worldwide
Pages extracted
Hours saved for our clients
€199 / one-time
setup fee - included
€169 / mo
setup fee €499
€229 / mo
setup fee €499
€349 / mo
setup fee €499
€549 / mo
setup fee €799
Finnish electronics retail is a narrow field, and Gigantti sets a large part of the reference price in it. Retailers and marketplace sellers watch category listings daily to see where they sit against the Kampanja (campaign) and Tarjoukset (offers) lines, and to catch the moment a Norm. hinta is restated. Because the Business Price (Excl. VAT) node is published next to the consumer price, a B2B reseller compares like for like without stripping ALV out of a gross figure by hand.
Brands and distributors use the same feed in the other direction. GTIN and manufacturerPartNumber let a supplier confirm that its range is listed, that descriptions and energialuokka values match the label it supplied, and that the images served from next-media.elkjop.com are current. Gigantti Marketplace listings are separated through the isMarketplaceProduct and isDropship flags, so third-party assortment never gets mistaken for Gigantti's own stock.
Cross-border teams get the most out of the shared article number. One SKU list joined across Gigantti, Elgiganten and Elkjøp turns four national storefronts into a single comparable table, which is the shape Nordic pricing committees ask for. Outlet and B-grade counts feed clearance and refurbished buying.
Scraping supplement products from iHerb.com with full details, including descriptions and packaging variations.
Learn More
Daily scraping of lowest prices for 150K products on Allegro.pl to support marketplace pricing and margin optimization.
Learn More
Regular monitoring of Ralph Lauren clothing, footwear, and accessories sold across Amazon subdomains: AE, DE, ES, FR, IT, NL, PL, UK.
Learn MoreLearn how to use web scraping to solve data problems for your organization
If you sell online, run a marketplace, or advise e-commerce clients, you already know why eBay matters: it’s one of the few places where big retailers compete side by side with thousands of small merchants and private sellers.
E-commerce teams do not just need “some” competitor data anymore. They need a continuous stream of real prices, discounts, stock levels, reviews, and seller behavior from the platforms that actually shape their markets.
Amazon provides valuable information gathered in one place: products, reviews, ratings, exclusive offers, news, etc. So scraping data from Amazon will help solve the problems of the time-consuming process of extracting data from e-commerce.
ScrapeIt is a managed service, not a tool you install and not a Python scraper you inherit. We write the crawler, run it on our infrastructure, watch it, and repair it when a layout or an API route shifts - which on a storefront that ships continuously from Vercel happens without notice. You receive data, not a repository. A site like gigantti.fi needs a real browser engine, per-SKU price handling and sitemap-based coverage, and that engineering stays on our side.
We collect publicly visible pages only - product, category, brand and store pages that any visitor can open without signing in. We honour the disallow list in robots.txt on gigantti.fi, which covers /api/, /search/, /cart/, /checkout/, /login/, account areas and any URL containing ?_rsc=, and we crawl at a rate that does not burden the site. No personal data is collected, and prices behind a sign-in, meaning Klubihinta for Gigantti-klubi members and the yritysmyynti ALV 0 % context, are out of scope. How you then use factual product data is a matter for your own legal advice, and we will describe precisely what a run touches.
The PDP sitemap index at /sitemaps/OCFIGIG.pdp.index.sitemap.xml fans out to 31 shards, and on a recent count those shards listed 369,830 product URLs. That is the figure to plan against, because site search will not give it to you: /search?q= reports the full osumaa count, but pagination is capped at 48 products per page across 32 pages, which is exactly 1,500 products, and page 33 quietly falls back to editorial articles. Coverage therefore comes from the sitemap shards and from category paths, with search and facets reserved for targeted slices. On the same crawl the service sitemaps added 716 category, 1,482 virtual-category, 5,399 brand, 98 Marketplace-partneri and 28 store URLs; those totals drift, so we re-read the index on every run rather than hard-coding them.
gigantti.fi sits behind Vercel bot mitigation, sometimes shown as a Vercel Security Checkpoint. A plain HTTP client receives HTTP 429 with X-Vercel-Mitigated: challenge and a challenge token header, and that happens even for /robots.txt, because clearing the checkpoint means executing a WebAssembly proof-of-work and posting the result back. We do not sell a way around protections. We run a real browser engine, so the same client-side code any visitor's browser executes runs for us too, including the per-SKU price and stock calls the page makes for itself, and we read the result from the rendered page. Request rates stay modest and the robots.txt disallow list is respected.
Gigantti states that online and store availability refreshes every 15 minutes, and the storefront re-fetches price and stock per SKU after the page loads instead of baking them into the HTML. In practice a daily run covers assortment and pricing analysis, while a watchlist of Tuotenumero values can be re-checked several times a day. Store-level detail comes from the availability and sellability payload: storesWithStockCount, availableForCollectAtStoreCount and the Varaa ja Nouda store count printed on the PDP, alongside the 27 store pages with their addresses, opening hours and services such as Nouto myymälästä and Outlet.
CSV, JSON, XLSX, Google Sheets or a REST endpoint your systems poll - whichever suits the pipeline that receives the data. A scoping conversation settles the field list, the slice of the catalogue and the schedule, then a sample extract follows so you can check the schema before the first full run. Cost depends on volume and frequency rather than a fixed price list, so send the fields and the cadence and you get a quote. Discontinued and sold-out items stay in the feed with isDiscontinued and onlineStock carried through, rather than vanishing without explanation.
Step 1 - Make a Request
You share your needs, expectations, and desired timeframe. We’ll suggest the best solution based on your request and budget.
Step 2 - Configuring Custom Web Crawlers
Our specialists configure the crawlers and extract a sample dataset for your review before proceeding with the full-scale extraction.
Step 3 - Collect and Deliver
Once you approve the sample, we launch the project and start full data collection. We gather, filter, and structure the data for easy use, delivering it on time in your preferred format.
Step 4 - Maintain and Support
Our team manages ongoing processes, monitors website changes, and supports all data extraction cycles. We can also help integrate data into your systems or create dashboards to simplify analysis.
Scrapeit Sp. z o.o.
10/208 Legionowa str., 15-099, Bialystok, Poland
NIP: 5423457175
REGON: 523384582
