Inside the Audit (10/12): Predicting What Users Actually Type

Apptonomy is an ASO intelligence and execution platform. Paste an App Store or Google Play URL, and the platform runs a full audit across multiple specialized engines, delivering scored findings and prioritized recommendations in minutes. For the full picture of how an audit works, read What You Get From an Apptonomy Audit.

The Orchestrator

Behind every audit is the Audit Engine, an orchestrator that runs 11 specialized subengines in parallel and synthesizes their findings into a single unified report with an ASO Readiness Score (0-100). See the full list in What You Get From an Apptonomy Audit. This post covers the Search Term Engine and what happens when it models how real users search for apps like yours.

The ASO Problem: Keywords and Search Terms Are Two Different Things

The Keyword Engine (covered in its own post) answers a specific question: which indexable keywords should your listing target, based on volume, difficulty, and competitive gaps? That analysis starts from store data and competitor intelligence. It produces a ranked list of keyword opportunities scored against market metrics.

The Search Term Engine answers a different question entirely: what real people actually type into the search bar when they need an app like yours.

These two questions sound similar. In practice, they produce very different outputs. Keyword research operates in the language of the store algorithm. Search term prediction operates in the language of the user. A keyword tool might tell you “budget tracker” has strong volume and moderate difficulty. A search term prediction tells you people are typing “where does my money go” and “stop overspending app” and “track daily expenses.”

The gap between keyword data and user search behavior is one of the most under-explored areas in ASO. Most ASO workflows underinvest in it because existing tools do not systematically surface it. Keyword tools report on terms that already exist in their index. They show you what apps already rank for. They cannot model what a person who has never heard of your app would type when they first feel the need your app solves.

That first search query is often messy, natural-language, and action-oriented. It describes a problem or a desired action, not a product category. “Phone storage full.” “Delete old photos fast.” “Track my runs without GPS watch.” These are the terms that capture users at the moment of highest intent. And they are the terms that keyword databases struggle to surface because they live in the long tail of search behavior, often with low individual volume but high collective conversion rates. Apple Search Ads campaigns reveal some real queries, but only for terms you are already bidding on. The Search Term Engine predicts terms you have not yet discovered.

Combining keyword optimization with search term prediction closes a visibility gap that affects both organic install volume and conversion rates. Keywords get your app indexed. Search terms get your listing speaking the language of users who have never heard of your brand. A complete ASO strategy needs both.

Under the Hood

The Search Term Engine takes your app’s listing text and uses AI to model real user search behavior for your app’s category and storefront. Here is what each stage of the pipeline produces.

User-Perspective Search Modeling

The problem: Your listing is written from your perspective. Users search from theirs. A fitness app’s listing might say “comprehensive workout tracking with personalized plans.” A user looking for that app types “lose weight at home” or “beginner gym routine.” The mental model gap between how you describe your product and how users search for it is where visibility gets lost.

How the engine handles it: The engine feeds your full listing text (title, subtitle, description, and category) into an AI model with a specific instruction: think like a real mobile app user, not a marketer. The model generates exactly 5 search terms, each 2-4 words, that a real person would type into the App Store or Google Play search bar when looking for an app that does what yours does. The prompt enforces strict constraints to keep the output grounded. Terms must use natural lowercase language. The app’s own name and branded terms are excluded. Generic filler (“best app,” “free app”) is filtered out.

What you get: Five predicted search terms, each representing a distinct way a real user would search for your app’s functionality.

Action and Problem Framing

The problem: The highest-intent app store searches tend to follow two patterns: action queries (“delete old photos,” “track my spending”) and problem queries (“phone storage full,” “messy camera roll”). These are the searches where a user is actively looking for a solution and is most likely to install. Standard keyword databases rarely capture these natural-language patterns because they focus on category terms and feature labels, not user language.

How the engine handles it: The prompt requires at least one action-verb search term (a query starting with a verb describing what the user wants to do) and at least one problem-description term (a query describing the situation the user is trying to resolve). This ensures the output covers both search intent patterns rather than producing five variations of the same category label. For a fitness app, this might produce “lose weight at home” (action) alongside “can’t stick to workout” (problem). For a photo management app, “delete old photos” (action) alongside “phone storage full” (problem).

What you get: A mix of action-oriented and problem-oriented search terms that map to distinct user mindsets at the moment of search.

Volume Estimation and Rationale

The problem: A predicted search term is more useful when you know its likely search volume and why it was selected. Without context, a list of five terms gives you no way to prioritize which ones to incorporate into your metadata or screenshot messaging first.

How the engine handles it: Each predicted term includes an estimated volume classification (high, medium, or low). The AI estimates relative volume based on category patterns and general search behavior knowledge, not from a proprietary search volume database. Long-tail volume estimation is inherently approximate since these are the queries that keyword indexes rarely track. Each term also includes a written rationale explaining why a user would type that specific query, connecting the search behavior back to a real user need.

What you get: Five search terms, each with a volume estimate and a rationale. In plain terms: high volume means many people search this way (broad reach), while low volume means fewer searchers but often a strong match for your specific app (high relevance). The output is structured so you can immediately see which terms represent the broadest audience and which capture niche user segments. These estimates can be cross-referenced against Apple Search Ads popularity scores or Play Console benchmarks to validate against real market data.

Platform-Aware Prediction

The problem: App Store users and Google Play users search differently. The App Store’s autocomplete encourages shorter, more keyword-like queries. Google Play search, influenced by users’ familiarity with Google web search, trends toward longer natural-language queries. A prediction model that ignores the platform context produces terms that may not match actual search patterns on the target store.

How the engine handles it: The engine receives the storefront context (App Store or Google Play) as an input parameter and adjusts the AI prompt accordingly, generating terms calibrated to each platform’s search behavior patterns.

What you get: Platform-specific search term predictions that reflect how users actually search on the store where your app lives. An iOS audit produces predictions tuned to App Store search behavior; an Android audit produces predictions tuned to Play Store patterns.

Integration with the Broader Audit

The problem: Search term predictions in isolation are interesting but incomplete. Their real value comes when cross-referenced against what other engines find.

How the engine handles it: Consider a concrete example: the Keyword Engine flags “photo cleanup” as a high-opportunity keyword gap. The Search Term Engine predicts users are typing “delete old photos fast.” That convergence tells you to work “delete old photos” language into your subtitle and first description line, where it serves both the ranking algorithm and the user scanning search results. The Search Term Engine produces its output as prioritized recommendations in the same unified format as every other subengine. Each predicted search term becomes a recommendation with priority classification (Priority 1 for high-volume terms, Priority 2 for medium, Priority 3 for low), effort rating, and source attribution. These recommendations flow into the Audit Engine’s master recommendation list alongside findings from all other subengines, where they can be cross-referenced and prioritized together.

What you get: Search term predictions that are part of the unified audit output, not a separate report. They appear alongside keyword gaps, store text issues, screenshot recommendations, and everything else the audit surfaces, enabling cross-engine prioritization in a single view. In practice, a high-priority search term tells you to work that language into your subtitle, keyword field, or screenshot copy. The audit shows you where to place it based on what the other engines found.

Bringing It Together

The gap between how ASO teams think about keywords and how users think about searching is real, persistent, and largely unaddressed by traditional ASO tools. The Search Term Engine fills that gap by modeling user search behavior directly, producing natural-language predictions that complement the data-driven keyword intelligence from the Keyword Engine.

To make this concrete, here is what the engine’s output looks like for a habit tracker app:

“build daily habits” (high volume) — users looking for a system to establish routines, broad category search

“stop procrastinating app” (medium volume) — problem-oriented search from users seeking behavior change

“morning routine tracker” (medium volume) — action-oriented query targeting a specific use case

“can’t stay consistent” (low volume) — high-intent problem query from users at a frustration point, strong conversion potential

Each term comes with a rationale connecting it back to a real user need, plus a volume classification to help you prioritize.

Running this as part of every audit means each app analysis includes both sides of the discovery equation: what the store algorithm needs to see (keywords) and what users actually type (search terms). The combination of AI-powered user behavior modeling, platform-specific prompt calibration, action-and-problem framing, and integration into the unified audit output creates a search term intelligence layer that would require user research, search query data access, and significant manual analysis to replicate independently. The engine delivers it automatically alongside every audit.

Search behavior varies across markets. German users, Japanese users, and Brazilian users search with different patterns and intent structures. Multi-locale search term prediction is on our roadmap, extending this engine’s approach to every storefront where your app is live.

Run a free Quick Audit now Paste your App Store or Google Play URL at apptonomy.ai and see what the Search Term Engine finds. You will get predicted search terms showing how real users would search for an app like yours, in under a minute.