Apify Store Analytics Scraper

See the niche before you build into it. Search any corner of the Apify Store and get real 30-day usage, honest ratings, failure rates and saturation signals for every matching Actor — in one run, from one unauthenticated public endpoint.

Built for Actor developers deciding what to build next, and for anyone who wants to know who actually dominates a category.

How do I use Apify Store Analytics Scraper?

Ten seconds, and you need no account beyond this one.

Paste this as the input, or press Start with the defaults — every field has a working one.

{
  "search": "instagram",
  "limit": 50,
  "minReviewsForRating": 3,
  "onlyWeak": false
}

You get one row per relevant Actor. Here is a real one, from a real run:

{
  "name": "apify/instagram-scraper",
  "title": "Instagram Scraper",
  "url": "https://apify.com/apify/instagram-scraper",
  "users30d": 39971,
  "runs30d": 15864030,
  "failureRate": 0.0001621277821587579,
  "rating": 4.715251824679979,
  "reviewCount": 558,
  "ratingState": "value",
  "pricingModel": "PAY_PER_EVENT",
  "notice": "NONE",
  "weak": false,
  "weakReasons": []
}

That is the market leader. This is what a weakness signal looks like, from the same run:

{
  "name": "apify/instagram-reel-scraper",
  "users30d": 10060,
  "rating": 3.846152302424789,
  "reviewCount": 99,
  "ratingState": "value",
  "weak": true,
  "weakReasons": ["rating 3.85 over 99 reviews"]
}

Ten thousand people a month use it and it is rated 3.85 across ninety-nine reviews. That is a real audience being served badly — which is the only kind of gap worth building into.

Three questions it answers

"Is this niche taken?" Sort the output by users30d. If one Actor holds most of the usage and is rated above 4.5, the niche has a leader and you are picking a fight. If the usage is spread across many mid-rated listings, nobody has won it yet.

"Is the leader actually good?" weak and weakReasons answer this and nothing else in the Store does. A leader with a 3.8 rating over a hundred reviews is a leader by inertia.

"Am I about to build something nobody wants?" A search that returns almost nothing is not automatically an opening. Read examined on the exhaustion row: if fifty listings were read and none matched, that is a thin market, and thin markets are usually thin for a reason.

The unrated trap

The Store API returns actorReviewRating = 0 for Actors that have never been reviewed — and 28% of the 1,617-listing catalogue has no reviews. A naive rating < 4.2 filter flags 46% of listings as weak incumbents. Reading the field correctly flags 13%.

So this Actor reports ratingState explicitly: value, unrated, too_few_reviews or missing. An Actor nobody has reviewed is reported as unrated — never as a bad one.

Input

Field	Default	Meaning
search	instagram	Free-text query
limit	50	Listings to fetch before relevance filtering
minReviewsForRating	3	Below this many reviews, rating is reported as null
onlyWeak	false	Return only listings with a genuine weakness signal
weakRatingBelow	4.2	A rating under this counts as a weakness signal
minRunsForHealth	100	Below this many runs, the failure rate is too thin to judge
weakFailureRateAbove	0.167	A failure rate above this counts as a weakness signal

Every field has a working default, so a run with no input succeeds.

Output

Two row shapes share the dataset. Check result to tell them apart.

A listing row — one per relevant Actor found:

Field	Meaning
name	username/actor-name
title	display title
url	Store page
users30d	distinct users in the last 30 days
runs30d	total runs in the last 30 days, or null
failureRate	failed ÷ total, or null when the total is zero
rating	only when backed by enough reviews, else null
reviewCount	number of reviews, or null
ratingState	value · unrated · too_few_reviews · missing
pricingModel	e.g. PAY_PER_EVENT
notice	e.g. UNDER_MAINTENANCE
weak	whether any weakness signal fired
weakReasons	which ones, in words
searchTerm	the query that produced this row
examined	how many listings were fetched before relevance filtering
relevant	how many of them matched every query token
discarded	examined minus relevant
capped	true if the fetch stopped at your limit, so more may exist
retrievedAt	when these numbers were read — Store figures change daily

An exhaustion row — when nothing relevant was found, you get a record that says so instead of an empty dataset that could mean anything:

Field	Meaning
result	NO_RELEVANT_LISTINGS, or STOPPED_EARLY if the charge limit cut the run short
searchTerm	the query that was run
examined	how many listings were read before concluding none matched
relevant	always 0
why	why nothing matched
interpretation	how to read a zero result
charged	false — meaning no listing-analysed events. The apify-actor-start event still applies; see Pricing.
pushed	on a STOPPED_EARLY row, how many listings were already analysed and saved before the limit was reached

{
  "result": "NO_RELEVANT_LISTINGS",
  "searchTerm": "quantum ferret grooming",
  "examined": 50,
  "relevant": 0,
  "why": "no listing text contained every query token",
  "interpretation": "a zero here means nothing matched your wording, not that the market is empty - try a broader term before concluding anything",
  "charged": false
}

Absent data is reported as absent (null), never disguised as a zero — that rule governs rating, runs30d, failureRate and reviewCount.

Honest limits

• Relevance is verified here, not by the API. The Store search parameter does not filter by relevance — github and goodreads both return Instagram Scraper as the top result. Every query token must appear in the listing text; typically 27–49 of 50 returned listings are discarded.
• There is no last-modified field in the Store API. lastRunStartedAt measures usage, not maintenance, so weakness is judged from run statistics instead.
• No proxy required. One unauthenticated request to a documented public endpoint.
• No personal data is collected.

Pricing

Pay per event. There are exactly two, and these are the prices the platform charges:

Event	Price	When
listing-analysed	$0.005	once per record, and only after that record is durably in your dataset
apify-actor-start	$0.00005	once per gigabyte of memory, when the run starts

So a run that analyses 40 listings costs about $0.20 — 40 x $0.005, plus a single start event at $0.00005.

A run that finds nothing relevant charges no listing-analysed events at all. You pay the start event and nothing else.

You can cap what a run may spend. Apify has a per-run Limit total charge setting (maxTotalChargeUsd) in the run options — this Actor does not define it, the platform does, and it applies to any pay-per-event Actor. Set it and the run stops when it is reached.

When that happens you do not silently get a short dataset. The run writes a STOPPED_EARLY row naming how many listings it had already saved and how many relevant ones it had found, so a run that was cut short can never be mistaken for a market that was small. Raise the limit and re-run to see the rest.

apify-actor-start is Apify's own platform event, charged on every pay-per-event Actor rather than added by this one. It buys your run five free seconds of compute, so it usually saves more than it costs. Memory is capped at 1 GB in actor.json, and the start event is priced per gigabyte allocated, so the cap holds it to a single event.

How to read the numbers

You see	It means	It does not mean
rating: null, ratingState: "unrated"	nobody has reviewed it	it is bad
rating: null, ratingState: "too_few_reviews"	fewer than minReviewsForRating reviews	it is bad
failureRate: null	no runs in the window, so the ratio has no denominator	it never fails
runs30d: 0 with users30d > 0	people installed it and did not run it	it is broken
weak: false	no signal fired on the data available	it is good

weak: false is the one worth dwelling on. It means nothing tripped a threshold, not that the Actor is well made. The signals are what the Store publishes; a well-marketed Actor with a bad output has no field that says so.

Questions

How current is this? Live at the moment you run it. The Store API is queried directly; nothing is cached between runs.

Why does the count change between runs? The catalogue changes, and the Store's own ordering is not stable across pages. Two runs minutes apart can return the same listings in a different order and occasionally a different count.

Can I get every Actor in the Store? Not in one run. limit caps how many listings are fetched before relevance filtering, and the filter typically discards most of them. Run several narrower searches rather than one wide one.

Does it need a proxy or an account? Neither. One unauthenticated request to a documented public endpoint.

What if my search returns nothing? You get an exhaustion row rather than an empty dataset, and it costs you no listing-analysed events — you pay only the start event, as every run does. See the shape above.

Where this fits with other Actors

It reads the Store; it does not read the web. Tools that pair with it:

• Amazon Review Defect Finder — the same approach applied to product reviews: it tells you which complaints are corroborated rather than which are loudest.
• Apify Store Scraper — if you want the raw Store catalogue rather than an adoption-and-quality reading of it.
• Website Content Crawler — for reading the pages behind the listings once you know which ones matter.

Integrations

This is an ordinary Apify Actor, so everything the platform offers works with it: schedule it, call it from the Apify API or the JavaScript and Python clients, wire it into Zapier, Make, n8n, Slack or a webhook, or reach it from an AI agent over MCP. Output goes to a dataset you can export as JSON, CSV or Excel.

A weekly schedule is the shape most people want: markets move slowly, and every row is stamped with retrievedAt so two runs can be compared honestly.

Found a problem?

Report it on the Issues tab. A bug report with the search term you used and the row that looked wrong is enough — the run id helps and is not required.

Two things worth reporting that people usually do not: a listing this scored weak that you know is good, and a listing it scored fine that you know is not. Both are threshold problems rather than bugs, and thresholds only move when somebody says so.

Unofficial

Not affiliated with or endorsed by Apify. It reads the same public catalogue endpoint any visitor can.