Overview
The AppSumo Product Reviews Scraper is an AppSumo reviews scraper: a standalone desktop bot that takes a list of AppSumo product URLs, normalizes each one to the review tab, walks every paginated review page through to the last, and extracts thirty-three fields per review into the reviews dataset. Where the sibling catalog bot reads deal cards, this one goes into the review stream itself - the full review body, the star rating, the displayed and ISO-normalised dates, the reviewer’s username and verification badges, the AppSumo Plus membership flag, any founder reply, and the helpful and share counts - across many products in a single run.
This listing is not affiliated with or endorsed by AppSumo. The selectors target AppSumo’s current public review-card markup and will need updating when that markup changes - when it does, a run ends with empty fields or zero rows rather than invented ones.
What does the AppSumo Product Reviews Scraper do?
The run is built for scale across products and depth within each. You supply product_urls - a required list variable, one AppSumo product URL per entry. The configuration ships with a single example product URL as its default; replace it with your own list before a real run. The engine fans the list out into its URL queue, one worker task per product, so a dozen products become a dozen independent collection passes. Each pass is self-normalising: it accepts any AppSumo product URL shape - with or without the reviews path, with or without a trailing slash or query string - and rewrites it to the canonical review tab at page one before collecting.
Within a product the bot paginates. It first reads AppSumo’s own pagination controls to discover the last page number, then loops from page one up to that last page - bounded by the optional max_pages_per_product safety cap - extracting the reviews dataset on every page. Because review pages can overlap and re-render, the dataset deduplicates on the combination of review_id, review_text and reviewer_username, and declares review_id and review_text as required fields, so a card that never rendered its body is logged rather than silently trusted.
Because everything runs on your own machine, your research footprint stays yours: which products you audit, which competitors you benchmark, which complaint themes you mine never passes through a third-party service’s dashboard or logs.
Who uses an AppSumo reviews scraper?
The voice-of-customer researcher asks “what do AppSumo buyers actually praise and complain about across this category?” and needs the full review_text plus review_rating for every review, not a sample. The SaaS founder launching on AppSumo asks “which recurring defects show up in one-star reviews of comparable products, and did those founders respond?” and needs review_rating, review_text and has_founder_reply side by side. The competitive analyst asks “how responsive is the competition to negative reviews, and how fast do they reply?” and needs founder_reply_date_iso measured against review_date_iso. The agency building deal-market datasets for clients asks “can I hand over a dated, deduplicated, structured review file per product?” and needs exactly the reviews export. Each of them needs a defensible artifact they produced themselves rather than a screenshot.
How does an AppSumo review run work, step by step?
Every command in the run links to its reference page. The pass opens on the queued product URL. First, execute_script reads the live location into source_url, and a second execute_script parses the product slug out of the path into product_slug. Third, goto navigates to the canonical AppSumo review tab for that slug at page one. Fourth, wait_for_selector blocks - up to 45 seconds - until either the page heading or the first review card renders, so extraction never races the page. Fifth, a third execute_script scans the pagination links - any whose accessible label reads “Go to page” followed by a number - and returns the highest into last_page. Sixth, set_variable seeds page at one and extract_data pulls page one’s reviews. Finally a while loop continues while the current page is below both last_page and the max_pages_per_product cap: each iteration increments page, re-navigates to that numbered review page, waits for a review card, and extracts again. This release sets no fixed export filename, so rows land in the launcher’s local results store and you export them from the results view; nothing is uploaded anywhere except the configuration fetch and download telemetry listed on this page.
What does the output look like?
The table mirrors the published sample row (fourteen of the thirty-three fields - the dataset carries the rest). Sample values are illustrative placeholders that show the shape of a real row:
| product_slug | review_id | review_title | review_text | review_rating | review_date_iso | reviewer_username | is_verified_buyer | is_plus_member | has_founder_reply | founder_reply_text | helpful_count | scraped_page_number | review_position_on_page |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| flowdesk-pro | 184207 | Exactly what my calendar workflow needed | Set it up in an afternoon and it replaced three manual steps. | 5 | 2026-03-04 | dana.k | 1 | 0 | 1 | Thank you Dana - glad it saved you time! | 12 | 1 | 1 |
product_slug and source_url tie every row back to its AppSumo product - the slug parsed from the path and the original queued URL captured before normalisation. scraped_page_url is the exact review page the row was read from, scraped_page_number is the pagination number parsed out of it (defaulting to 1), and review_position_on_page is the 1-based position of the card within that page.
review_id is the numeric identifier extracted from the review’s own permalink and a required field; review_url and review_slug keep the full permalink and its slug. review_title is the headline and review_text is the full body, whitespace-collapsed and trimmed, also a required field. review_text_length is the character count of that body, computed by a small script transform - handy for filtering thin or empty reviews.
review_rating_raw keeps AppSumo’s star accessibility label verbatim (the text ending in ” stars”) and review_rating is the numeric value cast to a float with a null fallback. review_date is the displayed date string, review_date_iso is that date normalised to yyyy-mm-dd by a parser with a month-name fallback (empty when unparseable), and review_meta_row_text is the whole collapsed meta line for auditing.
reviewer_username, reviewer_profile_url and reviewer_avatar_url identify who wrote the review - personal data, handled accordingly. is_verified_buyer and is_plus_member are count fields (0 when absent) for the verified-purchase check icon and the AppSumo Plus membership badge; reviewer_verified_label captures the verified wording, reviewer_member_since the “Member since” month and year, and reviewer_badges_text the collapsed badge row.
has_founder_reply is a count flag for a creator response; when one is present, founder_reply_label, founder_username, founder_avatar_url, founder_reply_date and founder_reply_date_iso describe it and founder_reply_text carries the response body.
helpful_count and review_share_count are the engagement numbers parsed from the card, both cast to integers defaulting to 0.
Can an AppSumo review scraper capture founder replies?
Yes - and it is one of the more useful columns here. A creator response is captured as a flag plus its full detail: has_founder_reply tells you a reply exists, and founder_username, founder_reply_text, founder_reply_date and founder_reply_date_iso tell you who replied, what they said and when. The analytical payoff is latency: subtract review_date_iso from founder_reply_date_iso and you have a reply-time per review, which becomes a responsiveness benchmark when you compare how quickly AppSumo vendors answer their one-star reviews against their five-star ones - directly useful if you are planning your own launch’s review strategy. What the bot does not do is interpret any of it - there is no sentiment score, no topic tag, no translation. It hands you the raw text and the dates; the analysis is your step.
How does reviewer identity and verification data work?
Each review row carries who wrote it and how AppSumo labels them. reviewer_username, reviewer_profile_url and reviewer_avatar_url are the identity fields; is_verified_buyer counts the verified-purchase check icon and is_plus_member counts the AppSumo Plus badge, so both read 0 when absent and 1 or more when present. reviewer_verified_label keeps the verified wording, reviewer_member_since parses the “Member since” month and year, and reviewer_badges_text collapses the whole badge row for auditing. Because these fields identify real people, this listing is flagged piiHandled true - treat them as personal data, with the lawful-basis and takedown duties that follow.
How does it compare to hosted AppSumo review services?
Reading reviews by hand produces a handful of rows an hour, no consistency, and nothing you can diff next month. Hosted robot and actor marketplaces do list AppSumo review collectors, but the structure is the opposite of this bot: they charge per result or per month, the review text and reviewer identities land in their cloud under their retention terms, and your audit history - which products, which competitors - lives on their servers. Here the marginal cost of a deeper back-catalog is your own time and bandwidth, the personal data stays on your disk under your control, and the workflow configuration is yours to keep, modify and re-run. The trade is real: no dashboards, no built-in sentiment analysis, no scheduling, no cloud-side retry. You get an artifact and a workflow you own outright.
How do you set it up on Windows, macOS and Linux?
Download the launcher for your operating system from this page. On Windows, run the downloaded .exe directly - there is no installation step; SmartScreen may ask for confirmation on first launch, so verify the published checksum, then choose More info and Run anyway. On macOS, two launchers are published - pick the one matching your machine’s chip (Apple menu, About This Mac: Apple Silicon or Intel) - then make it executable with chmod +x, clear the Gatekeeper quarantine with xattr -d com.apple.quarantine /path/to/BOT_appsumo-product-reviews-scraper.sh and launch. On Linux, chmod +x ./BOT_appsumo-product-reviews-scraper.sh then ./BOT_appsumo-product-reviews-scraper.sh. At first run the launcher asks for the product_urls list - one AppSumo product URL per line, replacing the shipped example - and the optional max_pages_per_product cap, then starts the run. Keep product_urls a list: a single string collapses the fan-out. To repeat an audit on a cadence, schedule the launcher with your OS scheduler (Task Scheduler, cron or launchd).
What do I check when a run returns zero rows?
Work in order. Zero rows: did the review page render in an ordinary browser, or did a consent wall, region lock or challenge greet the fresh session - the run waits up to 45 seconds for a heading or a review card, and neither appearing means the page never loaded. Only page one collected for every product: the pagination-label scan most likely stopped at 1, so last_page read 1 and the while loop never advanced - check one product by hand against its real page count on appsumo.com. A single product collected when you queued many: product_urls was passed as a string instead of an array, collapsing the fan-out. Rows present but a column empty across every row: that field’s selector most likely changed in an AppSumo redesign; check one review card by hand. Empty rating or ISO date on scattered rows: completely normal - the casts and date parser fall back to null or empty rather than failing the row. The contract is that failure is loud - empty values and zero rows, never fabricated data.
What are the bot’s limits?
It reads AppSumo review pages only: no product specifications, prices, plan tiers or vendor data (the sibling AppSumo Product Catalog Scraper covers the deal-card side), and no photos beyond reviewer and founder avatars. It ships without sentiment scoring, topic tagging or translation - the review text is raw and the analysis is yours. It has no proxy rotation or CAPTCHA solving enabled, so if a challenge stops the run, the run stops; nothing bypasses it. Pagination is bounded by the labels it recognises and by max_pages_per_product, so an AppSumo redesign of the pagination controls can truncate depth silently - which is why the page-count check above matters. It is a snapshotter, not a monitor - nothing re-runs, diffs or alerts on its own. Deduplication applies within a run on the review id, text and username triple; merging across runs is your step.
What is responsible AppSumo review collection?
This bot crosses into personal data by design: review bodies, usernames, profile links and avatars identify people, so establish a lawful basis under GDPR, UK GDPR or your local equivalent before storing or analysing the output, and honour takedown and opt-out requests immediately and permanently. Never republish reviewer identities, and never use the output for spam or for profiling that harms individuals. Review AppSumo’s terms of service with open eyes - automated collection may conflict with them, and the decision to run is yours to own. Keep request volume at what a patient human could sustain; the per-page waits and the max_pages_per_product cap already pace the run that way. Date every snapshot, and if you republish derived analysis, do so in aggregate and in ways AppSumo permits. This bot is an independent tool, not affiliated with or endorsed by AppSumo.
