How ASOTrendHQ turns public store data into research signals.

Scrapers collect public app-store listing data for both supported stores. Scheduled jobs refresh ratings, rankings, categories, keyword metrics, ranking histories, and derived analyses at different points in the daily processing chain. A record's displayed timestamp describes that record; it does not guarantee every upstream field changed.

Published store observations carry their own source, market, date and collection coverage. Ranking difficulty is unsupported without a validated assessment. Search demand is unavailable without an authorized source. Relative source popularity is displayed in its native scale and is never relabeled as monthly searches.

Earlier API fields and saved snapshots may retain listing-derived model values for compatibility. They are labeled as legacy models and cannot qualify an opportunity or a ranking forecast. Retrieval time does not replace a missing source observation date.

The keyword catalog is built from public app-listing metadata, not private store search logs. Extraction version 3 selects bounded English listing phrases, records listing sources, and rejects generic and legal boilerplate. Older records remain until reconciled. Seed searches keep an exact term when it exists; broader matches require evidence across at least two app listings.

The SEO cohort scores lexical quality, evidence, app coverage, ranking coverage, freshness, and enrichment. Normalized equivalent phrases are clustered, with one representative selected as canonical. The primary cohort is deliberately capped and can be expanded in measured batches after webmaster data supports doing so.

• Store interfaces, availability, and ranking results vary by country and time.
• Scraping or scheduled jobs can be delayed, incomplete, or temporarily unavailable.
• Models can over- or under-estimate demand and competitive difficulty.
• App-store data belongs to its respective publishers and platform providers.
• Important decisions should be cross-checked against store consoles and first-party analytics.

Observed positions come from the named Apple Search API or Google Play collection, for a country and date. They are not a guarantee of the results every device or user sees. Listing fit and same-category peers are relevance clues, not verified intent.

Popularity uses listing prevalence, phrase length and category breadth. Demand scales those model inputs; it does not measure monthly queries. Difficulty combines listing prevalence and available ranking metadata with fixed weights. Traffic and conversion potential are further heuristics, not forecasts. None of these models has been calibrated to predict ranking success or installs.

Model trends can move when catalog coverage changes. Boilerplate filtering improves candidate hygiene, but a surviving term is not automatically useful for your app. The current English extractor has limited evaluation and should not be assumed accurate for other languages.

1. Confirm the phrase describes a real feature and inspect its dated results in the target store and country.
2. Record existing metadata, search visibility, acquisitions and conversion from your store console, including the baseline dates.
3. For iOS, review the title, subtitle and keyword field; for Google Play, review the title and descriptions. Avoid irrelevant or repetitive terms.
4. Record the exact change and publication date. Compare subsequent performance over a chosen observation period, accounting for releases, paid campaigns and seasonality.
5. Use supported listing experiments to test conversion. Track search visibility separately; a conversion result does not prove a keyword caused a ranking change. Record inconclusive and negative results too.

We have not established that these recommendations increase rankings or installs. See Apple search guidance and Google listing experiments for platform guidance.