A used car has no fixed price. Its value is set by what similar cars are listed for nearby this week, and that changes every day as stock sells and dealers cut prices. Dealers who price their stock, marketplaces that show a “fair price” badge and analysts who follow the market all need the same thing: a steady record of listings across portals and regions. This is price intelligence for a market where every item is unique, and it needs a different setup from tracking a product that sells the same everywhere.
This guide covers what to collect, how to handle location and duplicates, and how to set up the proxies.
What makes car listings different
Three things set automotive monitoring apart from ordinary retail price tracking.
Every car is unique. A phone model has one price per shop. Two cars of the same make, model and year can differ by thousands because of mileage, trim, options, colour and history. You compare like with like, so you need the attributes, not just the price.
The market is local. Buyers rarely travel far for a car, so portals rank and filter by distance from a location, and prices differ between regions. A model can sell faster and for more in one metro area than in another a few hundred kilometres away.
The same car is listed many times. A dealer often lists one car on its own website, on two or three marketplaces and on a classifieds site at once. Without matching, your data counts it three or four times.
What to collect
Per listing:
- VIN, when shown, and the listing’s own ID on each portal.
- Make, model, year, trim, mileage, fuel type and transmission.
- Asking price and currency, plus any price shown “before” a reduction.
- Seller type (dealer or private) and the dealer name and location.
- The date you first saw the listing and the date it disappeared.
Derived metrics:
- Days on market: from first seen to gone. The most useful single signal of demand for a model in a region.
- Price drops: how often and by how much a listing is reduced before it sells.
- Supply: how many comparable cars are listed in an area at one time.
When a listing disappears, you usually do not know whether it sold or was withdrawn. Treat “gone” as a likely sale only after several checks in a row, and keep the last asking price, not a sale price.
Location: search from where the buyer is
Most car portals ask for a location and a search radius, or set one from the visitor’s IP. If you collect from one data centre, you see one area, or the portal decides for you.
Two approaches work together:
- Set the location in the search itself wherever the portal lets you enter a city or postal area and a radius.
- Send the request from an IP in that area, so the portal’s own defaults, currency and regional listings match a local buyer. City targeting covers the cities you study; we look at when that level of detail pays off in when city-level proxy targeting matters.
For cross-border work, such as comparing a model’s price in Germany, France and Poland, country targeting is usually enough, and each country’s main portals are the source.
Matching the same car across portals
Duplicate listings are the biggest source of error in car data.
- Match on VIN when it is published. It is exact.
- Fall back to a composite key when it is not: make, model, year, mileage within a small range, dealer and location. Mileage rarely matches to the kilometre across portals, since dealers round it.
- Keep one record per car with a list of the portals it appears on and the price on each. A car priced differently on two portals at the same time is itself a useful signal.
The same problem appears in property data, and the methods carry over: our guide to aggregating listings across portals goes into the matching rules in detail.
Proxy setup
| Job | Rotation | Targeting |
|---|---|---|
| Search result pages per area | Per request | City or region of the area |
| Listing detail pages | Per request | Same area as the search |
| Multi-step pages (finance quote, options) | Sticky session | Same area |
| Manufacturer configurator prices | Per request, sticky if multi-step | Country |
Car portals are large, well-protected sites, and they see a lot of automated traffic. A few habits keep the collection stable:
- Use residential proxies and rotate the IP on every request, so no single address makes thousands of visits.
- Keep a low request rate per portal and spread the work over the day. Car stock does not change by the minute; one or two passes a day per area is enough for most uses.
- Prefer the listing data the page loads as JSON, when the portal exposes it, over rendering full pages with photo galleries. It is lighter and more stable.
- Check that every response is a real results page before storing it, and retry later rather than faster when a portal challenges you.
Who uses this data
- Dealers price new arrivals against nearby comparable stock and see when a competitor cuts prices on similar cars.
- Marketplaces and valuation services build price guides and “good deal” labels from the spread of asking prices.
- Lenders and insurers follow used car values for loans and claims.
- Manufacturers and analysts track supply and days on market by model and region to read demand.
The bottom line
Car price monitoring is local, attribute-heavy and full of duplicates. Collect the attributes that make each car comparable, search from the area a real buyer would search from, match listings across portals before counting them, and track days on market and price drops over time. Residential proxies with city targeting and per-request rotation keep the collection steady across the portals and regions that matter to you.