AI Discovery Engine

14 min readLast updated View as MarkdownAgent setup

The AI Discovery Engine measures whether AI assistants recommend your app. It generates a battery of realistic user prompts, queries five LLM providers in parallel, analyzes every response for mentions and positioning, and computes an AI Discovery Score (0-100) across presence, position, sentiment, intent coverage, and competitive standing.

The ASO Problem: A New Discovery Layer You Cannot See

A growing share of users now ask an AI assistant for app recommendations before they visit the App Store or Google Play. The pattern is straightforward: “What’s the best running app for beginners?” goes into ChatGPT, Gemini, or Perplexity, and the user gets a shortlist with reasoning. By the time they open the store, their decision is mostly made. If your app was not on that shortlist, you lost the install before traditional ASO even had a chance to work.

The challenge for ASO teams is that this discovery layer is invisible to existing tools. No standard ASO dashboard tells you whether ChatGPT mentions your app when a user asks for a recommendation in your category. And no dashboard shows you why it does or does not.

LLM recommendations are also inconsistent. Ask the same question twice and you may get different answers. A single test query tells you almost nothing. What matters is your recommendation frequency across many queries, across multiple LLMs, across the full range of user intents your app serves. That is a measurement problem that manual spot-checking cannot solve.

AI discoverability is a new layer on top of traditional ASO. The apps that get recommended by LLMs tend to have clear problem-solution language in their metadata, verifiable claims, consistent messaging across store listing and website, and strong community signals. These are ASO fundamentals, reframed for a different audience. The AI Discovery Engine measures where you stand and identifies what to fix.

Here is what the AI Discovery Engine found for a fitness app: AI assistants rarely mentioned it, a category leader held most of the share of voice, and several high-value user intents drew no recommendation for the app from any LLM. Every technical section below explains how the engine produces findings like these.

Under the Hood

The AI Discovery Engine runs a multi-step pipeline: generate realistic user prompts, query five LLM providers, parse every response for app mentions and positioning, compute share of voice against competitors, map intent coverage, score across five weighted dimensions, and compare your store listing against your website for consistency. Here is what each stage produces.

Prompt Battery Generation

The problem: To know whether AI recommends your app, you need to ask the right questions. A single generic prompt like “best fitness app” gives you one data point. Users ask LLMs in many different ways: by category (“top budgeting apps”), by problem (“how do I track my spending”), by audience (“best finance app for college students”), by comparison (“Mint vs YNAB”), and by switching intent (“alternative to Mint”). Your measurement needs to cover all of these query patterns.

How the engine handles it: The engine first harvests real search demand in your market, then generates a battery of natural-language prompts with an AI model that takes those search phrases, your app’s category, primary use case, competitors, and user intents (from the Intent Engine if available) as context. Most prompts are grounded in one harvested phrase and record which one; the rest are generated from your listing and fill prompt types no phrase supports. The number of prompts used on your audit appears under Prompts used in the methodology panel. Prompts are distributed across seven types: direct category, problem-solution, audience-specific, comparative, feature-specific, switching, and brand-aware. When intent data is available, prompts are mapped to specific user intents for later coverage analysis. For non-English locales, prompts are wrapped with language instructions so the LLMs respond in the target market’s language. The engine generates locale-specific prompt batteries for each target market, capturing regional differences in how users query AI assistants. A user in Japan asks for app recommendations differently than a user in Germany, both linguistically and in terms of category conventions. If AI generation fails, the engine falls back to a template system with pre-built prompt patterns.

What you get: A diverse battery of realistic user queries that simulate how people actually ask AI assistants for app recommendations in your category, with each prompt’s origin recorded.

Search Demand Harvest

The problem: A prompt battery generated only from your app’s own listing text can miss the language people actually use when they ask an AI assistant for a recommendation, and gives you no way to tell which prompts reflect real demand in your market versus a plausible guess.

How the engine handles it: Before generating prompts, the engine harvests real search-demand phrases for your market from a wide set of sources: Google search features surfaced alongside your category (People Also Ask questions, related searches, videos), Google and YouTube autocomplete suggestions, your app store’s own autocomplete, Google Ads keyword ideas, Reddit requests and recommendation threads, Google Trends related queries, your Play Console search terms when connected, and any search terms you add yourself. Prompts are grounded in real search demand in your market — what people search on Google, the app stores, YouTube and TikTok, and what they ask for on Reddit, with Google Ads search volume where it exists, plus your own Play Console search terms and any terms you add — and each shows the phrase it came from. Harvested phrases measure what people search for, not how they word a question to an AI assistant, so each prompt stays generated and is grounded in a phrase rather than copied from one. When a harvested phrase has no reliable search volume for your specific market — Reddit and YouTube suggestions, for example, carry no country signal — the engine shows no volume for that phrase rather than borrowing one from another market. TikTok phrases are not yet included; that source activates once Apptonomy’s TikTok for Business connection is live. Reddit contributes little outside English-language markets.

What you get: A pool of real search-demand phrases for your market that the prompt battery draws on, with each phrase’s source and, where available, its search volume.

Multi-LLM Query Execution

The problem: Different LLMs recommend different apps. ChatGPT, Gemini, Claude, and Perplexity each draw from different training data and use different retrieval mechanisms. Google AI Overviews are a separate channel entirely, blending web search results with generative summaries. If you only test one LLM, you are seeing a fraction of the picture.

How the engine handles it: The engine queries five targets in parallel: ChatGPT (GPT-4.1-nano), Gemini (2.5 Flash Lite), Claude (Haiku 4.5), Perplexity (Sonar), and Google AI Overviews. These models were selected for cost-efficient batch querying at scale; recommendation patterns are validated against flagship model outputs during engine calibration. Each prompt is sent to all five. Per-LLM rate limiting ensures no single provider’s downtime blocks the full analysis. If one provider goes down, the engine continues with the others. Perplexity and Google AI Overviews also return citations (the URLs they reference in their answers), which are collected for later analysis.

What you get: Raw text responses from up to five AI providers for every prompt in the battery, capturing the full spectrum of how different LLMs handle your category.

Response Analysis

The problem: A raw text response from an LLM is unstructured. You need to know: was your app mentioned? In what position? With what sentiment? Which competitors also appeared? Which user intents were addressed?

How the engine handles it: The engine runs a two-stage analysis. First, a heuristic pre-filter checks whether your app name appears in each response, handling name variations automatically. Responses that clearly do not mention your app are classified without an LLM call. Responses that pass the filter are analyzed by an AI model that extracts: mention position in the recommendation list (1st, 2nd, 3rd, etc.), mention context, sentiment (positive, neutral, negative), recommendation strength (strong, moderate, weak, absent), competitor co-mentions with positions, and intent matches.

What you get: Structured analysis for every query result: mention detection, position ranking, sentiment classification, competitor co-occurrence, and intent matching.

Share of Voice

The problem: Knowing your app was mentioned in some queries tells you something. Knowing how often it was mentioned relative to your competitors tells you much more. If ChatGPT recommends Competitor X in 70% of relevant queries and your app in 15%, that gap is the real finding.

How the engine handles it: The engine counts your app’s mentions across all query results and compares them against each competitor. Share of voice is your mention count divided by total mentions (yours plus all competitors), expressed as a percentage. Each competitor gets their own SoV, average mention position, and dominant sentiment, sorted by share of voice so the biggest threats surface first.

What you get: Your share of voice percentage, per-competitor share of voice with position and sentiment data, total responses analyzed, and a count of unique apps mentioned across all queries.

The engine also reports a demand-weighted share of voice — the same calculation, but weighting every prompt by the search volume of the phrase behind it, so a prompt tied to a heavily searched phrase counts for more than one tied to a rarely searched phrase. A prompt generated from your listing, or a custom prompt with no matching search demand, still counts, at the lowest weight on the scale. This applies to a custom or calibrated set as well as a demand-grounded one: a curated prompt matched against harvested demand carries its matched phrase’s weight. Alongside it, a demand coverage figure shows how much of your harvested search demand the scored battery actually represents. Neither figure changes your AI Discovery Score; they show whether your results weigh toward the search demand that matters most in your market. When too few prompts carry a real search-demand weight to weight reliably, the weighted figure is left off rather than shown on a thin sample.

Intent Coverage Mapping

The problem: Your app might get recommended for “best budgeting app” but never for “track spending across multiple accounts” or “budget app for couples.” Each unmatched intent represents a segment of users who will never find your app through AI recommendations.

How the engine handles it: The engine maps prompts to user intents (from the Intent Engine) and checks which intents result in your app being recommended. For each intent, it calculates a mention rate, average position when mentioned, and which LLMs mentioned your app for that intent. The overall intent coverage rate is the percentage of intents where your app was mentioned at least once.

What you get: A per-intent coverage map showing which user needs AI associates with your app and which it does not, along with an overall coverage rate (0-100%).

AI Discovery Score

The problem: You need a single number that captures your overall AI discoverability health, with enough granularity to know where to focus.

How the engine handles it: The engine computes a composite score (0-100) from five weighted dimensions:

  • Presence (30% weight): What percentage of queries resulted in your app being mentioned?
  • Position (25%): When mentioned, where do you rank? First recommendation scores 100, second scores 80, third 60, and so on.
  • Sentiment (15%): What proportion of mentions frame your app positively versus neutrally or negatively?
  • Intent Coverage (20%): What percentage of your relevant user intents are covered by AI recommendations?
  • Competitive Standing (10%): How does your share of voice compare to the strongest competitor?

Presence carries the highest weight because an app that never appears in recommendations cannot benefit from favorable positioning or sentiment. Intent Coverage ranks second because coverage breadth determines how many user segments can discover the app through AI. Competitive Standing is weighted lowest because it is a relative benchmark derived from the other dimensions. The default weights reflect cross-category analysis of AI recommendation patterns.

When community signal data is available, a sixth dimension (Community Health) is added at 10% weight and the other dimensions are rebalanced. Position scoring uses a fixed map: 1st place = 100 points, 2nd = 80, 3rd = 60, 4th = 40, 5th = 20, 6th or later = 10. Competitive standing is scaled by absolute presence, so low-SoV apps do not get inflated scores just because their competitors are also invisible.

What you get: An overall AI Discovery Score (0-100) with a full breakdown by dimension. Each dimension score identifies exactly where your AI discoverability is strong and where it needs work.

Cross-Channel Consistency Analysis

The problem: LLMs cross-reference multiple sources when deciding whether to recommend an app. If your store listing says one thing and your website says another, the conflicting signals reduce the LLM’s confidence in recommending you. If your store listing leads with AI-powered features but your website emphasizes privacy and simplicity, LLMs see mixed signals about what your app actually does.

How the engine handles it: When a website URL is available, the engine fetches your website content, extracts structured messaging (value proposition, key features, target audience, tone, claims), and does the same for your store listing. An AI model compares the two across five dimensions: value proposition alignment, feature emphasis, audience targeting, tone and voice, and claims and proof points. Each dimension gets a score (0-100). Misalignments are flagged by severity (high, medium, low) with fix recommendations.

What you get: An overall consistency score, a clarity score (how unambiguous your messaging is), and a credibility score (how well your claims are supported), plus per-dimension breakdowns and specific misalignment fixes.

Citation Analysis

The problem: Perplexity and Google AI Overviews cite their sources. Knowing which sources LLMs reference when recommending apps in your category reveals where you need to be present: editorial sites, community forums, your own website, or the store listings themselves.

How the engine handles it: The engine collects all citation URLs from Perplexity and Google AI Overview responses and classifies each by source type: community (Reddit, Stack Overflow, Hacker News), store listing (App Store, Google Play), owned (your website), editorial (TechCrunch, CNET, The Verge, and similar), or other. Citations are aggregated by category, domain, and LLM provider.

What you get: A breakdown by source category with percentages, a ranked list of the most-cited domains, and a per-LLM view of citation sources. If citations are heavily concentrated in one category, the engine flags this as a diversification opportunity.

Demand Phrase Placement

The problem: Knowing that AI assistants recommend a competitor for “budget tracker for couples” instead of your app is a finding, but it doesn’t say what to do about it. Without a specific phrase, a specific field to add it to, and a check that the phrase isn’t already there, “improve your listing” is advice a user cannot act on.

How the engine handles it: The engine selects up to eight demand phrases behind either a user intent your listing doesn’t yet address or a prompt your app is absent from, ranked by the harvest’s demand rank (search volume where available, otherwise source strength). Each phrase is checked against your live subtitle and description — respecting the store’s exact character limits and a running budget so recommended phrases never together overflow a field — against the text of the website pages already fetched for cross-channel analysis, and, for phrases that are themselves real questions people ask, against your listing and brief to draft a verbatim answer or flag it as unanswered. The engine also links every prompt to the specific pages an LLM answer cited or Google showed, and surfaces pages that were cited in AI answers recommending a competitor instead of you, alongside the Reddit threads and videos searchers already see for your category phrases — all places your app could earn a mention.

What you get: A short, ranked list of real search phrases with an exact status for each — already in your listing, fits in a specific field with room to spare, or needs a field that’s already full — plus a website check, an FAQ answer where one is defensible, and a list of pages worth pursuing a mention on.

How to read your result

Look at presence first: the share of queries where your app was mentioned at all. It carries the highest weight in the AI Discovery Score because an app that never appears cannot benefit from good positioning or sentiment. Next, compare your share of voice against the strongest competitor — a wide gap there is usually the headline finding. Then scan intent coverage for the specific user needs where no LLM recommended you; those are the gaps to close in your metadata. The overall AI Discovery Score (0-100) rolls all of this up, but the dimension breakdown tells you where to start.