/apify-app-store-intelligence

name: apify-app-store-intelligence
description: Pull structured Apple App Store and Google Play data — app metadata, price, rating, the 1–5★ ratings histogram, version, developer, and reviews — and watch it for changes over time. Use when the user asks to look up an iOS or Android app by App ID, bundle ID, package name or app name, compare a set of competitor apps across both stores, monitor a competitor's price or rating for changes, track when an app ships a new version, scrape App Store or Google Play reviews, resolve a bundle ID to a full app record, check an app's rating across multiple country storefronts, build an ASO or app-market dataset, or set up a recurring app-store watch on an app's price, rating and version. One routed Actor, praise-most-high/app-store-intelligence, is built by this skill's author; every other row is unaffiliated (see Disclosure).
author: Donny
author_url: https://github.com/donnywin85
metadata:
  category: data-extraction
  keywords: "app-store, google-play, ios, android, apple, aso, app-store-optimization, app-metadata, app-reviews, ratings, ratings-histogram, price-monitoring, version-tracking, bundle-id, package-name, storefronts, competitor-monitoring, change-detection, itunes"

App Store Intelligence (Apple App Store · Google Play)

Two different questions live under "get me app store data", and picking the wrong Actor for yours is the main way this task goes wrong:

• **What does this app look like right now?** — price, rating, ratings count, ratings

histogram, version, developer, category, screenshots, release notes. This is *metadata*, it is one row per app, and it is cheap.

• **What are users saying?** — the review corpus. This is *reviews*, it is thousands of rows per

app, and it costs roughly three orders of magnitude more per app.

Most Actors in this category do reviews. If the user asked "did our competitor drop their price", routing them to a reviews scraper burns their budget on data they did not ask for.

The second trap is the store: Apple and Google Play need different identifiers, different Actors, and they do not carry the same fields (Google Play publishes a per-star histogram, Apple does not publish one on the app page; Play metadata often has no `version`). Answer each store from a run on that store — never infer one from the other.

Example prompts

Prompts this skill handles:

• "What's the current price and rating of App Store id 284882215?"
• "Resolve `com.spotify.client` to a full app record."
• "Watch these six competitor apps daily and tell me when any of them changes price or ships a new version."
• "Pull the last 500 reviews of Duolingo on the US store."
• "Compare our app's rating in the US, UK and Japan storefronts."
• "Give me the 1–5 star breakdown for `com.calm.android` on Google Play."
• "What are Android users complaining about in the last 30 days?"

Out of scope (the boundary):

• "How does my app rank for the keyword 'habit tracker'?" — that is **keyword rank tracking**,

which needs a rank tracker, not a metadata or review Actor. Hand off to `slothtechlabs/aso-keyword-rank-tracker` or `petersutarik/aso-keyword-intel` ([`references/actor-index.md`](references/actor-index.md)); this skill does not run them.

• "Which Shopify apps compete with mine?" — a different marketplace. This skill covers the

Apple App Store and Google Play only.

Prerequisites

• Apify account ([sign up](https://apify.com))
• Authentication via one of:
• `apify login` (OAuth, if using the Apify CLI)
• `APIFY_TOKEN` environment variable
• Token from [Apify Console → Settings → Integrations](https://console.apify.com/settings/integrations)

Workflow

1. **Classify the request as metadata or reviews.** Ask if it is genuinely ambiguous — the cost difference is large enough to be worth one clarifying question. "Rating" is metadata (a single number); "what do reviewers complain about" is reviews. 2. **Resolve the app identity before scraping, per store.** Users supply store URLs, numeric track IDs, bundle IDs, Play package names or plain app names, and the Actors want different ones — Apple takes `284882215` or `com.spotify.client`, Google Play takes `com.spotify.music`. The identifiers are **not interchangeable**; passing the wrong kind returns nothing. A search term is the loosest input and can return the wrong app. Cheat-sheet: [`references/gotchas.md`](references/gotchas.md). 3. **Pick the Actor from the routing table below**, then fetch its input schema rather than guessing at field names:

apify actors info "ACTOR_ID" --input \ --user-agent apify-awesome-skills/apify-app-store-intelligence \ 2>/dev/null

Pass `--input` **without** `--json`: on Apify CLI 1.10.0 `--input --json` prints the whole Actor object and buries the schema. 4. **Set the storefront explicitly** whenever price or availability is involved. Price is per-country and the default is not always the user's country; a price answer without a named storefront is not an answer. 5. **Cap every reviews run with that Actor's own cap field** — the names differ (`maxItems`, `maxReviewsPerApp`, `maxReviews`) and several defaults are fail-open. The per-Actor cap and price are in [`references/actor-index.md`](references/actor-index.md). 6. **Run, then report the row count and the dataset link** so the user can see what they paid for. Say which store and which storefront each number came from. 7. **For recurring watches, use change detection rather than diffing yourself.** Re-scraping a full snapshot daily and comparing it in the agent is slower and more expensive than an Actor that keeps the previous snapshot and emits only changed fields. Read the `changesOnly` section of [`references/gotchas.md`](references/gotchas.md) first: the **first** run in that mode emits every app (it is the baseline and says so in the log), and the snapshot is shared across the whole Apify acco