Macy's carries hundreds of brands across apparel, beauty, home and jewellery, and prices them with a vocabulary all of its own. This service turns product pages into a table - seventeen columns per item, with the price kept twice: once exactly as displayed, and once stripped down to something you can compute with.
Almost every serious mistake made with department-store price data comes from reading the number and discarding the word next to it.
Macy's publishes its own pricing policy, and it is unusually explicit. Regular and Original prices are described as offering prices - the merchandise was offered at that price in stores or on macys.com - and Macy's states plainly that an item may not actually have been sold at it, so a saving calculated against them is not evidence that anyone ever paid the higher figure. If you build a discount-depth metric out of a struck-through number, that is what you are measuring: how Macy's presents a price, not how a market moved.
The vocabulary carries meaning beyond that too. Original, Closeout, Clearance, Now, Permanent Markdown and Just Reduced all signal a permanent reduction - an item marked that way is not going back to its old price. Everyday Value means a standing low price that promotions and coupons are excluded from, which is a very different animal from a sale. Two items at the same number can be telling you opposite things about what happens next.
This is exactly why the export keeps the price twice. price is the string as displayed, currency symbol, separators and all; parsed_price is the same figure with the formatting stripped out so it sorts and sums correctly. Compute on parsed_price, and keep price so that the presentation survives into your data instead of being thrown away at parse time.
You point it at Macy's pages and it gives you back a table. There is no search syntax to learn.
Billing follows rows, so narrow the list on Macy's before you export it rather than after.
These are the columns this scraper's export declares, in order. Each description explains what the column is for. Which of the optional ones a given retailer actually fills varies - brand, rating, reviews, description and availability are all present in the schema and none of them is guaranteed to be populated on every page.
url; where our retail exports have returned rows the two have matched, so treat them as one value until you find a page where they do not.InStock and OutOfStock are the values our retail exports have returned. Not every retailer publishes it, in which case the column is empty rather than false.; to get the list back.sku_code. On some retailers the two are the same number; on others they are completely different, so do not treat them as interchangeable.product_url.images. Convenient when you want one thumbnail per row and not a list.Three of these pairs look redundant and only one of them is. product_url and url have matched wherever our retail exports returned rows. images and image are a list and its first entry, which is a convenience rather than a duplicate. But sku_code and sku are genuinely two different identifiers - the retailer's number and the manufacturer's - and on retailers that use both they do not match. Deduplicate on the retailer's own number, not on whichever of the two your first ten rows happened to agree on.
Department-store data has a particular shape, and these four properties decide what the export can honestly support.
The two price columns exist because a displayed price and a numeric price are different objects. price arrives the way a shopper sees it - currency symbol, thousands separator - which is useless to a spreadsheet and essential to a reader. parsed_price is the same amount with all of that removed, so it sorts and averages correctly. Keep both. Discarding the formatted one at parse time is how a price series ends up unable to say what it was actually looking at.
Macy's own pricing policy states that Regular and Original prices are offering prices, and that an item may not have been sold at them - so savings shown against them may not be based on actual sales of that item. That is the retailer telling you, in writing, not to read a struck-through number as market evidence. A discount metric built on it is a measure of merchandising language. Perfectly legitimate to track, as long as you label it as what it is.
brand, rating, reviews, description and availability are all part of this schema, and whether they arrive populated depends on what the pages themselves publish. Across our retail exports one site has filled brand on every row while another filled it on none, and availability has come back both as a proper schema.org value and as nothing at all. Sample a small run before you design a table around a column being present.
Every product image arrives in a single images field with a semicolon and a space between the URLs, and image repeats the first of them for convenience. That is fine once you know it and a nuisance if you do not - a naive import treats the whole thing as one very long URL and every image silently breaks. Split on ; at ingest. The count you get back is also a rough signal in itself: a product with one photograph and a product with a dozen are usually at different points in a merchandising cycle.
Where a department-store catalogue is more useful as a table than as an infinite scroll.
One export is a price list; the same export repeated is a price history. Pull a category on a schedule, match rows on sku_code, and the diff tells you what moved, what went to clearance and what quietly disappeared. Because price keeps the wording alongside the figure, you can also separate the genuine markdowns from the items that only look reduced.
For a brand selling through Macy's, the interesting question is not the recommended price but the shelf: how many of your lines are listed, at what prices, with how many photographs, and which ones are sitting in clearance. Group by brand, sort by parsed_price, and you have the answer in one screen - including the products your own retail team may not know are discounted.
Marketplaces, comparison sites and affiliate catalogues all need the same things: a title, a description, a price, an image and an identifier. This export carries all five, plus the Web ID that maps a listing back to Macy's own system. Split images, keep parsed_price for the feed and price for the display, and the transformation is a few lines rather than a project.
No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that it is pay-as-you-go.
For every new account, one time. No credit card. All scrapers unlocked. Five hundred products is a substantial slice of a single department, which is enough to see the shape of the data before you commit to anything.
Roughly $2 per 1,000 products. Billing follows rows, so the cheapest way to monitor a category is to narrow it on Macy's first and then repeat the same narrow pull - a weekly export of the lines you care about costs a fraction of a monthly export of everything.
Volume pricing, SLAs, dedicated workers and tailored onboarding for teams tracking large catalogues across many retailers on a repeating schedule. Tell us your numbers and we will quote.
LIVESCRAPER10 at checkout.The same item is usually listed in several places at several prices, and a single catalogue cannot tell you which of them is the outlier. These two use the same export shape.
The same product fields from the catalogue most price comparisons are anchored to - useful the moment you need to know whether a Macy's price is competitive.
Apparel from a pure-play retailer with a very different markdown rhythm - a useful control when you are trying to tell a category trend from a single store's promotion calendar.
Short answer: yes. A product page is an advertisement, published so that as many people as possible read it.
Macy's product pages are public. Anyone can read them without an account, and collecting publicly visible product information for research and price comparison is long-settled practice. As long as the data is publicly available and the process does not disrupt the site, there are no federal laws against it.
The subject matter here is about as uncontroversial as scraping gets. Every one of these seventeen columns describes an item for sale - its name, its price, its pictures, its identifiers. There is no personal data anywhere in the export: no customer, no reviewer, not even a review body. Nothing in the file identifies a person.
Macy's terms restrict automated access, so this remains a question of terms. We touch nothing behind a login, place no orders, run no third-party trackers on the data layer, and your exports self-delete after 30 days.
The questions we hear most. Something else? Talk to us - humans write the answers, not bots.
query, sku_code, product_url, name, description, parsed_price, price, currency, availability, rating, reviews, images, brand, sku, url, image and status. One row per product. It is the shared shape our retail product endpoints use, so a Macy's export lines up column-for-column with the others.price is the string as displayed, with the currency symbol and thousands separators left in. parsed_price is the same amount with that formatting removed so it sorts and sums correctly. Compute on parsed_price and keep price - at Macy's especially, how a figure is presented carries meaning the bare number does not.sku_code is the retailer's own item number - on Macy's, the slot for the Web ID, the reference number printed on tags in store and in the catalogue that pulls an item up in the site's search. sku is the manufacturer's identifier, a style or part number. On some retailers the two carry the same value and on others they are completely different, so pick one deliberately as your key rather than assuming they agree.; and you have the list. image already holds the first of them if all you need is one thumbnail per row.brand, rating, reviews, description and availability depend on what the pages themselves publish - across our retail exports one site has filled brand on every row and another on none. Run a small sample first and see which columns arrive populated before you design around one.sku_code is the column it comes back in. For submitting work, product URLs are the unambiguous input - a URL always resolves to exactly one page. Note too that not every item in a Macy's store or catalogue has a Web ID, because not everything Macy's sells is sold online.Paste the products, pick your format, and take the catalogue away as rows - name, description, both prices, brand, images and the identifiers that tie it all back together. Your first 500 rows are free.
Macy's is one of the largest department store chains in the United States, carrying hundreds of brands across apparel, beauty, home and jewellery, and its website is the catalogue that most of those brands are judged by. Browsing it works well for one purchase and badly for any question about the assortment: how a brand is priced across its lines, what fraction of a category is sitting in clearance this week, which items gained or lost photographs, what moved since the last time you looked. The Macys Products Scraper answers those by turning product pages into a table - seventeen columns per item, exported as CSV, JSON or Excel, in the same shape as our other retail product endpoints so that a multi-retailer comparison lines up column for column.
The design decision worth understanding before you use it is that the price is stored twice. Retail prices are displayed for humans, with a currency symbol and thousands separators, and that string is useless to a spreadsheet - but stripping it is destructive, because at Macy's the presentation carries meaning. So the export keeps both: parsed_price with the formatting removed, for sorting and arithmetic, and price exactly as displayed, for everything else. The same principle explains the pair of image columns, where images holds every photograph joined into one semicolon-separated string and image repeats the first for convenience, and the pair of identifier columns, where sku_code is the retailer's own number and sku is the manufacturer's - those two are genuinely different values on retailers that use both, and choosing the wrong one as a key produces duplicates that look like new products.
Macy's pricing vocabulary deserves particular care, and Macy's itself supplies the reason. Its published policy describes Regular and Original prices as offering prices - the merchandise was offered at that price - and says that an item may not have been sold at them, so savings shown against them may not be based on actual sales. The same policy distinguishes a set of terms that signal a permanent reduction, including Original, Closeout, Clearance, Now, Permanent Markdown and Just Reduced, from Everyday Value, which is a standing low price that promotions and coupons are excluded from. Two products showing the same number can therefore be on opposite trajectories. A discount metric computed from a struck-through figure is measuring merchandising language rather than market movement, which is a perfectly good thing to track as long as it is labelled honestly.
One honest note about the evidence behind this page. Every claim above is either the export's declared schema - the seventeen column names, identical on both of our runs - or a documented property of Macy's itself, taken from Macy's own pricing policy and its Web ID convention. There are no Macy's scrape results here, because we have none: both runs were made against a placeholder URL rather than a real Macy's page and returned nothing but a 404, and the service is recorded internally as needing a residential proxy. The column semantics described above were established from sibling retail endpoints on the identical schema that did return populated rows, which is why the page can say what a column is for without claiming what Macy's put in it. No product count, price, rating or stock figure appears anywhere on this page, and none will be added unless a real Macy's export backs it. Start free: your first 500 rows cost nothing and need no credit card.