Estimate how ParseShelf Data Units fit Amazon search, category, ASIN and product page workflows.
| Plan | Price | Included | Best for |
|---|---|---|---|
| Free | $0 | 2,500 units once | first sample and evaluation |
| Starter | $49/mo | 100k listing rows or 20k full products | small teams |
| Pro | $99/mo | 500k listing rows or 100k full products | agencies and repeat workflows |
| Growth | $249/mo | 2M listing rows or 400k full products | larger recurring pipelines |
| Business | Custom | higher concurrency, retention and support | teams with SLA needs |
Listing rows cost 1 Data Unit. Full product rows cost 5 Data Units. Only delivered rows spend units, and unused reserved units are returned after the job closes.
ParseShelf uses Data Units to make job cost easier to understand. Listing-only rows are lightweight and work well for discovery. Full-product rows use more units because they enrich product pages with details, stock, media, review signals and exports.
Unused reserved units are returned when a job completes with fewer delivered records than requested. That matters for Amazon pages where the real number of useful results can be lower than the requested target count.
Start by estimating how often you need fresh Amazon data, how many delivered rows matter and whether each row needs full product enrichment. Product research teams often begin with listing discovery, then enrich selected ASINs.
Catalog teams and price monitoring workflows usually need full-product mode more often because they care about price, stock, bullets, images and stable product fields.
Use listing_only for broad scans and reserve full_product for products that pass a filter. Deduplicate ASINs before enrichment and split large projects into jobs by category, competitor or campaign.
The free calculator and ASIN validator pages help buyers understand this model before they create a paid workflow.
A useful Amazon data page should help a buyer decide what to do next, not only define a keyword. When evaluating this workflow, start from the business question: discover products, enrich ASINs, monitor competitors, audit a catalog, prepare a spreadsheet or feed an internal data pipeline. The right ParseShelf mode and export format depend on that question.
For early research, keep the first run small and easy to inspect. Use one keyword, one category, one competitor set or one ASIN list, then compare delivered rows against the fields your team actually needs. Price, currency, rating, review count, stock status, source URL and product URL are usually the minimum useful fields. Product details, bullets, variants, images and seller signals become important when the workflow moves from discovery to enrichment.
For production, treat every Amazon job as an auditable dataset. Store the job ID, input source, mode, run date and export format next to the downstream report. This makes it possible for developers and operators to debug the same result from the dashboard, the API status endpoint and the downloaded files.
When a page links to docs, examples, samples and pricing, the visitor can move from research to implementation without guessing which product surface to use. That path is important for both conversion and search intent satisfaction.
This is also how the page supports organic search quality. The content is tied to a concrete product workflow, includes examples, links to related resources and exposes the same schema that users see after signup. That creates a stronger page than a generic scraper keyword page with no data shape, no implementation detail and no clear next action.